From syan at openjdk.org Mon Dec 1 02:33:02 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 1 Dec 2025 02:33:02 GMT Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails with java.nio.file.AccessDeniedException [v2] In-Reply-To: References: <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com> Message-ID: On Fri, 28 Nov 2025 10:44:47 GMT, Severin Gehwolf wrote: >> SendaoYan 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 'openjdk:master' into jbs8371769 >> - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException > > FYI: Updated the summary on the bug. Please change the PR title accordingly before integrating. Thanks for the reviews @jerboaa @shipilev. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28286#issuecomment-3594266127 From syan at openjdk.org Mon Dec 1 02:33:03 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 1 Dec 2025 02:33:03 GMT Subject: Integrated: 8371769: TestMemoryInvisibleParent.java fails with java.nio.file.AccessDeniedException In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 09:28:27 GMT, SendaoYan wrote: > Hi all, > > Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root. > > This PR also add prefix indent for a try block, but do not touch the original logic. > > Change has been verified locally on linux-aarch64 with non-root user. This pull request has now been integrated. Changeset: 3fd551f9 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/3fd551f9926601b05a13a22b556d55425a37ee4d Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod 8371769: TestMemoryInvisibleParent.java fails with java.nio.file.AccessDeniedException Reviewed-by: sgehwolf, shade ------------- PR: https://git.openjdk.org/jdk/pull/28286 From dholmes at openjdk.org Mon Dec 1 04:03:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Dec 2025 04:03:49 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Fri, 28 Nov 2025 15:54:24 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports @JonasNorlinder this PR isn't fixing two issue. I think [JDK-8372584](https://bugs.openjdk.org/browse/JDK-8372584) should just be closed as a duplicate of [JDK-8210452](https://bugs.openjdk.org/browse/JDK-8210452) (which I had forgotten about and which @larry-cable did not get further with). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28556#issuecomment-3594431428 From dholmes at openjdk.org Mon Dec 1 04:13:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Dec 2025 04:13:50 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Fri, 28 Nov 2025 15:54:24 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Overall looks good. I'd forgotten that I found about this in 2018. A few minor nits. Can't really comment on the benchmark. src/hotspot/os/linux/os_linux.cpp line 4961: > 4959: } > 4960: > 4961: // Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types Suggestion: // Since kernel v2.6.12 the Linux ABI has had support for encoding the clock types src/hotspot/os/linux/os_linux.cpp line 4968: > 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. > 4967: static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) { > 4968: constexpr clockid_t CLOCK_TYPE_MASK = 3; Shouldn't the mask be covering 3-bits? src/hotspot/os/linux/os_linux.cpp line 4979: > 4977: // to detach itself from the VM - which should result in ESRCH. > 4978: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); > 4979: *success = false; The normal way I've seen this pattern used is to set it to true rather than assuming it was true to begin with. ------------- PR Review: https://git.openjdk.org/jdk/pull/28556#pullrequestreview-3523063061 PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2575538639 PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2575548230 PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2575553017 From aboldtch at openjdk.org Mon Dec 1 06:55:58 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Dec 2025 06:55:58 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v3] In-Reply-To: References: Message-ID: > [JDK-8313882](https://bugs.openjdk.org/browse/JDK-8313882) introduced a `checked_cast` when to silence the Wconversion warnings when we store an `int` in a `char`. The problem is that the assumption that the value in the `int` we get from `getc` is compatible with `char` is incorrect. > > The specification for `getc` is that it returns either `EOF` or the next read `unsigned char` converted to an `int`. This means we have the possible values of `{EOF, 0-255}`, we always check for `EOF` first, so we end up only having `{0-255}` as the possible values. (While a char has the possible values of `{-128-127}`.) > > So first the problem with `checked_cast` (which ensures that the type roundtrip is lossless) will end up converting any value in `{128-255}` to `{-128, -1}` which when converted back to an `int` is `{-128, -1}` and not `{128-255}`. > > The thing is that this is not a problem except for the assert as we do not care if the conversion roundtrip is lossless. We only want to reinterpret the value as a `char`, and never try to regain the unsigned representation converted to an `int` that `getc` uses. > > Another issue with keeping the value inside an `int` which could lead to bugs in the future is that when we use it in equality comparison agains a `char` we will encounter an integer promotion of the `char` which will lead to surprising incorrect results if the character is non-ascii. > > Currently we have no such comparisons of this `int` vs a non-ascii character. So the only issue is the assert inside `checked_cast` which will trigger if the settings file contains a non-ascii character. > > I suggest we convert the return value from `getc` to a `char` after we have check for `EOF` and before we use it as a character. > > It is worth noting that the `(unsigned char)` casts for the calls into `isspace` (introduced by [JDK-8332400](https://bugs.openjdk.org/browse/JDK-8332400)) is very important to get the correct value for its `int` input parameter. (So we get the correct non-sign extended cast `char -> unsigned char -> int`.) That issue mentions the possibility of introducing our own `isspace` (suggestion was `os::isspace`) which we could overload the different types and do the correct thing with bound checks. This might be something we want to revisit. > > _`isspace` specification:_ >>The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to [EOF](https://en.cppreference.com/w/c/io.html). > > * Testing > * GHA > * Running tier 1-3 on Oracl... Axel Boldt-Christmas 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 tag 'jdk-26+26' into JDK-8371762 Added tag jdk-26+26 for changeset 847fbab7 - Update src/hotspot/share/runtime/arguments.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - 8371762: Incorrect use of checked_cast in Arguments::process_settings_file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28283/files - new: https://git.openjdk.org/jdk/pull/28283/files/8d9337d4..77e0abdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=01-02 Stats: 242396 lines in 1970 files changed: 163762 ins; 42364 del; 36270 mod Patch: https://git.openjdk.org/jdk/pull/28283.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28283/head:pull/28283 PR: https://git.openjdk.org/jdk/pull/28283 From mbaesken at openjdk.org Mon Dec 1 07:52:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 1 Dec 2025 07:52:55 GMT Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to Events::log In-Reply-To: References: Message-ID: On Fri, 28 Nov 2025 17:37:24 GMT, Lutz Schmidt wrote: > Looks good as far as new code is concerned. Thanks the reviews ! > > Is it by intention that on windows the action is logged twice (log_info and Events::log_dll_message)? One call is for UL , one is for hserr/hsinfo files event log. So not really the same 'target' . Btw. on the non-Windows OS platforms you find the UL log_info call too, e.g. see os_linux.cpp `os::dll_load` . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28452#issuecomment-3595087164 From nbenalla at openjdk.org Mon Dec 1 08:53:37 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 1 Dec 2025 08:53:37 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - revert MAX_COLUMNS to 80 - Update LATEST_MAJOR_VERSION in Versions.java - Merge branch 'master' into start-of-release-27 - Merge branch 'master' into start-of-release-27 - ... and 7 more: https://git.openjdk.org/jdk/compare/41b7823d...e5214614 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/78895b2b..e5214614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05-06 Stats: 11187 lines in 367 files changed: 7430 ins; 1793 del; 1964 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From aartemov at openjdk.org Mon Dec 1 10:35:49 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 1 Dec 2025 10:35:49 GMT Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension request [v18] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible: > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in two places where the successor could be suspended: > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again. The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events. > > Tests are added for both scenarios. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed whitespace error. - 8366659: Refactoring. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed tests. - 8366659: Fixed tests. - 8366659: Refactored tests. - 8366659: Added bool arg to notify_contended_enter - 8366659: Refactored the big test into 3 smaller tests. - 8366659: Addressed reviewer's comments. - ... and 24 more: https://git.openjdk.org/jdk/compare/ef5e744a...8283d9c0 ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=17 Stats: 1277 lines in 9 files changed: 828 ins; 427 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From jnorlinder at openjdk.org Mon Dec 1 11:45:49 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 1 Dec 2025 11:45:49 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 04:04:19 GMT, David Holmes wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused imports > > src/hotspot/os/linux/os_linux.cpp line 4968: > >> 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. >> 4967: static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) { >> 4968: constexpr clockid_t CLOCK_TYPE_MASK = 3; > > Shouldn't the mask be covering 3-bits? No we should not touch bit 3 which encodes if the clock is for a thread of process. See here https://elixir.bootlin.com/linux/v6.17.9/source/include/linux/posix-timers_types.h#L9-L19. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2576734534 From jnorlinder at openjdk.org Mon Dec 1 11:53:54 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 1 Dec 2025 11:53:54 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v4] In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: <9Yx-NbaCfboU7u4tifXbMaK_Vvz9mrASr9g_svKKBr8=.a330bbf4-5208-4208-8e20-b259fe41f278@github.com> > Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. > > This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). > > Before patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > CPUTime.execute:p0.00 sample 0.008 ms/op > CPUTime.execute:p0.50 sample 0.008 ms/op > CPUTime.execute:p0.90 sample 0.008 ms/op > CPUTime.execute:p0.95 sample 0.008 ms/op > CPUTime.execute:p0.99 sample 0.012 ms/op > CPUTime.execute:p0.999 sample 0.015 ms/op > CPUTime.execute:p0.9999 sample 0.021 ms/op > CPUTime.execute:p1.00 sample 1.030 ms/op > > > After patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 8984189 ? 10?? ms/op > CPUTime.execute:p0.00 sample ? 10?? ms/op > CPUTime.execute:p0.50 sample ? 10?? ms/op > CPUTime.execute:p0.90 sample ? 10?? ms/op > CPUTime.execute:p0.95 sample ? 10?? ms/op > CPUTime.execute:p0.99 sample 0.001 ms/op > CPUTime.execute:p0.999 sample 0.001 ms/op > CPUTime.execute:p0.9999 sample 0.006 ms/op > CPUTime.execute:p1.00 sample 0.054 ms/op > > > Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix grammar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28556/files - new: https://git.openjdk.org/jdk/pull/28556/files/c022266d..a9628846 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556 PR: https://git.openjdk.org/jdk/pull/28556 From jnorlinder at openjdk.org Mon Dec 1 11:53:57 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 1 Dec 2025 11:53:57 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 04:08:23 GMT, David Holmes wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused imports > > src/hotspot/os/linux/os_linux.cpp line 4979: > >> 4977: // to detach itself from the VM - which should result in ESRCH. >> 4978: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >> 4979: *success = false; > > The normal way I've seen this pattern used is to set it to true rather than assuming it was true to begin with. Using a positive outcome like success to encode the outcome make it possible to return like so `return success ? os::Linux::thread_cpu_time(clockid) : -1;`. I prefer having the `-1` at the end as I find this reads easier. If we encode a failure we would need to write `return !failure ? os::Linux::thread_cpu_time(clockid) : -1;`. Hence, I would prefer keeping this as is as double-negatives may be harder to parse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2576747078 From mgronlun at openjdk.org Mon Dec 1 12:17:21 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Dec 2025 12:17:21 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v7] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/c0e1124e..ba54d2af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=05-06 Stats: 11 lines in 4 files changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From coleenp at openjdk.org Mon Dec 1 13:11:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 13:11:12 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 11:21:52 GMT, Fredrik Bredberg wrote: > The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 > > By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. > > Passes tier1-7 without any problems that can be traced to this PR. If you're able to hide more of the implementation in the cpp file it'll be less dramatic when you change it. src/hotspot/share/runtime/objectMonitorTable.hpp line 35: > 33: > 34: class ObjectMonitorTable : AllStatic { > 35: struct Config { Can you hide all of this in the .cpp file like symbolTable.cpp hides the CHT implementation instead of having it all in the hpp file? The interface only needs to be the functions at the end. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28565#pullrequestreview-3524909068 PR Review Comment: https://git.openjdk.org/jdk/pull/28565#discussion_r2577009871 From azeller at openjdk.org Mon Dec 1 13:28:52 2025 From: azeller at openjdk.org (Arno Zeller) Date: Mon, 1 Dec 2025 13:28:52 GMT Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to Events::log In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 13:03:23 GMT, Matthias Baesken wrote: > Currently we log only the success or failure of shared lib load operations in HS > (by calling Events::log_dll_message). > Adding log messages for load attempts would help us in a number of cases : > - give timestamps before AND after the load operation > - log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation) LGTM. ------------- Marked as reviewed by azeller (Author). PR Review: https://git.openjdk.org/jdk/pull/28452#pullrequestreview-3524984491 From coleenp at openjdk.org Mon Dec 1 13:31:07 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 13:31:07 GMT Subject: RFR: 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null [v7] In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 13:40:44 GMT, Coleen Phillimore wrote: >> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field. >> >> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable. The key to this table is {ConstantPool, cp-index}. In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed. In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure. In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message. Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields. The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too). >> >> Add a null check before calling ResolutionErrorEntry add entry. Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again. >> >> Tested with submitted reproducer and tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/classfile/systemDictionary.cpp Thanks David, Johan for discussions and reviews, to Tom for the review and reproducer and all his help, and to Ioi for finding another leak. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28438#issuecomment-3596547230 From coleenp at openjdk.org Mon Dec 1 13:31:09 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 13:31:09 GMT Subject: Integrated: 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 17:00:04 GMT, Coleen Phillimore wrote: > The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field. > > There are two uses of ResolutionErrorEntry in the ResolutionErrorTable. The key to this table is {ConstantPool, cp-index}. In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed. In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure. In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message. Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields. The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too). > > Add a null check before calling ResolutionErrorEntry add entry. Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again. > > Tested with submitted reproducer and tier1-4. This pull request has now been integrated. Changeset: b98114f4 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/b98114f4a20bcf3390114b56d05c38b23268979a Stats: 27 lines in 3 files changed: 16 ins; 5 del; 6 mod 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null Reviewed-by: dholmes, never, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/28438 From mbaesken at openjdk.org Mon Dec 1 13:40:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 1 Dec 2025 13:40:00 GMT Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to Events::log In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 13:03:23 GMT, Matthias Baesken wrote: > Currently we log only the success or failure of shared lib load operations in HS > (by calling Events::log_dll_message). > Adding log messages for load attempts would help us in a number of cases : > - give timestamps before AND after the load operation > - log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation) Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28452#issuecomment-3596591210 From mbaesken at openjdk.org Mon Dec 1 13:40:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 1 Dec 2025 13:40:01 GMT Subject: Integrated: 8372272: Hotspot shared lib loading - add load attempts to Events::log In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 13:03:23 GMT, Matthias Baesken wrote: > Currently we log only the success or failure of shared lib load operations in HS > (by calling Events::log_dll_message). > Adding log messages for load attempts would help us in a number of cases : > - give timestamps before AND after the load operation > - log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation) This pull request has now been integrated. Changeset: d328e4e7 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d328e4e7e2f58fbfeb661f3502f95016159d7230 Stats: 8 lines in 4 files changed: 8 ins; 0 del; 0 mod 8372272: Hotspot shared lib loading - add load attempts to Events::log Reviewed-by: lucy, azeller ------------- PR: https://git.openjdk.org/jdk/pull/28452 From cnorrbin at openjdk.org Mon Dec 1 14:07:22 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 14:07:22 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 Message-ID: Hi everyone, Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. Testing: - Oracle tier 1 - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. ------------- Commit messages: - constraint on MinOopMapAllocation Changes: https://git.openjdk.org/jdk/pull/28576/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28576&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358706 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28576.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28576/head:pull/28576 PR: https://git.openjdk.org/jdk/pull/28576 From phubner at openjdk.org Mon Dec 1 14:15:00 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Mon, 1 Dec 2025 14:15:00 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:00:22 GMT, Casper Norrbin wrote: > Hi everyone, > > Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. > > Testing: > - Oracle tier 1 > - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. src/hotspot/share/runtime/globals.hpp line 1674: > 1672: \ > 1673: /* new oopmap storage allocation */ \ > 1674: develop(intx, MinOopMapAllocation, 8, \ Shouldn't we also make this an `int` while we're at it since a `GrowableArray`'s length is kept as an `int`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28576#discussion_r2577252382 From cnorrbin at openjdk.org Mon Dec 1 14:30:58 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 14:30:58 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:35 GMT, Paul H?bner wrote: >> Hi everyone, >> >> Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. >> >> Testing: >> - Oracle tier 1 >> - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. > > src/hotspot/share/runtime/globals.hpp line 1674: > >> 1672: \ >> 1673: /* new oopmap storage allocation */ \ >> 1674: develop(intx, MinOopMapAllocation, 8, \ > > Shouldn't we also make this an `int` while we're at it since a `GrowableArray`'s length is kept as an `int`? Sure, I could change the type as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28576#discussion_r2577310164 From cnorrbin at openjdk.org Mon Dec 1 14:33:19 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 14:33:19 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. > > Testing: > - Oracle tier 1 > - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: change flag type to int ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28576/files - new: https://git.openjdk.org/jdk/pull/28576/files/6ded9479..a1555d99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28576&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28576&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28576.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28576/head:pull/28576 PR: https://git.openjdk.org/jdk/pull/28576 From ayang at openjdk.org Mon Dec 1 14:35:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Dec 2025 14:35:42 GMT Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next [v3] In-Reply-To: References: Message-ID: > A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early. > > The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path. > > > Test: tier1 Albert Mingkun Yang 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 six additional commits since the last revision: - Merge branch 'master' into smap-parser - review - copyright-header - review - Merge branch 'master' into smap-parser - smap-parser ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28225/files - new: https://git.openjdk.org/jdk/pull/28225/files/c179ccd5..cfe12245 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28225&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28225&range=01-02 Stats: 22816 lines in 521 files changed: 12611 ins; 7329 del; 2876 mod Patch: https://git.openjdk.org/jdk/pull/28225.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28225/head:pull/28225 PR: https://git.openjdk.org/jdk/pull/28225 From fandreuzzi at openjdk.org Mon Dec 1 14:35:42 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Dec 2025 14:35:42 GMT Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next [v3] In-Reply-To: References: Message-ID: <5yWuePfzX0lxchsJ7Hg-6d8S0_o3h849tgBvZHZdLDs=.d6bf7151-b565-48cf-8a7d-4fb91d3e01d0@github.com> On Mon, 1 Dec 2025 14:32:53 GMT, Albert Mingkun Yang wrote: >> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early. >> >> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path. >> >> >> Test: tier1 > > Albert Mingkun Yang 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 six additional commits since the last revision: > > - Merge branch 'master' into smap-parser > - review > - copyright-header > - review > - Merge branch 'master' into smap-parser > - smap-parser Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28225#pullrequestreview-3525296627 From jsjolen at openjdk.org Mon Dec 1 14:39:12 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Dec 2025 14:39:12 GMT Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:35:42 GMT, Albert Mingkun Yang wrote: >> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early. >> >> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path. >> >> >> Test: tier1 > > Albert Mingkun Yang 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 six additional commits since the last revision: > > - Merge branch 'master' into smap-parser > - review > - copyright-header > - review > - Merge branch 'master' into smap-parser > - smap-parser Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28225#pullrequestreview-3525319813 From liach at openjdk.org Mon Dec 1 15:40:40 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 15:40:40 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v3] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Doc tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/712dbf1c..7a1cfa4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=01-02 Stats: 25 lines in 1 file changed: 0 ins; 24 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From coleenp at openjdk.org Mon Dec 1 15:57:10 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 15:57:10 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v3] In-Reply-To: References: Message-ID: <379iBIu0uk_Af-5_RZUQBFNkGyFM7iYpe4B_hg93tn8=.95e6e771-31f5-4b89-8172-aa3d0837de25@github.com> On Mon, 1 Dec 2025 15:40:40 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Doc tweaks With one small change, the runtime part of this change looks good. src/hotspot/share/ci/ciField.cpp line 220: > 218: return false; > 219: // Explicit opt-in from system classes > 220: if (holder->trust_final_fields()) This is missing { } so not sure where it ends, especially that it encloses an if statement, and other code. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3525748039 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2577662841 From liach at openjdk.org Mon Dec 1 16:03:38 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 16:03:38 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614 bin/generate-symbol-data.sh line 41: > 39: # - open a terminal program and run these commands: > 40: # cd "${JDK_CHECKOUT}"/src/jdk.compiler/share/data/symbols > 41: # bash ../../../../../bin/generate-symbol-data.sh "${JDK_N_INSTALL}" Same, extract to 26 doc/starting-next-release.md line 68: > 66: update annotation processor extended by `javac` tests to cover the new source version > 67: * `test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out` and `test/langtools/tools/javac/preview/classReaderTest/Client.preview.out`: update expected messages for preview errors and warnings > 68: * `test/langtools/tools/javac/versions/Versions.java`: add new source version to the set of valid sources and add new enum constant for the new class file version. Same remark, extract to 26 src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: > 380: * > 381: * @see 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1: > 1: /* Let's extract this change to 26 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 1: > 1: # Let's extract this for 26. src/jdk.compiler/share/data/symbols/README line 1: > 1: This directory contains history data for -release. Let's extract this for 26. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577666303 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577665823 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577662551 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577673512 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577675100 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577674956 From nbenalla at openjdk.org Mon Dec 1 16:03:40 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 1 Dec 2025 16:03:40 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> On Mon, 1 Dec 2025 15:52:42 GMT, Chen Liang wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614 > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: > >> 380: * >> 381: * @see > 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> > > This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. Great idea Chen, I will open a PR for this today ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577683094 From jnorlinder at openjdk.org Mon Dec 1 16:09:02 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 1 Dec 2025 16:09:02 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v5] In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: > Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. > > This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). > > Before patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > CPUTime.execute:p0.00 sample 0.008 ms/op > CPUTime.execute:p0.50 sample 0.008 ms/op > CPUTime.execute:p0.90 sample 0.008 ms/op > CPUTime.execute:p0.95 sample 0.008 ms/op > CPUTime.execute:p0.99 sample 0.012 ms/op > CPUTime.execute:p0.999 sample 0.015 ms/op > CPUTime.execute:p0.9999 sample 0.021 ms/op > CPUTime.execute:p1.00 sample 1.030 ms/op > > > After patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 8984189 ? 10?? ms/op > CPUTime.execute:p0.00 sample ? 10?? ms/op > CPUTime.execute:p0.50 sample ? 10?? ms/op > CPUTime.execute:p0.90 sample ? 10?? ms/op > CPUTime.execute:p0.95 sample ? 10?? ms/op > CPUTime.execute:p0.99 sample 0.001 ms/op > CPUTime.execute:p0.999 sample 0.001 ms/op > CPUTime.execute:p0.9999 sample 0.006 ms/op > CPUTime.execute:p1.00 sample 0.054 ms/op > > > Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Add fixes from @cl4es review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28556/files - new: https://git.openjdk.org/jdk/pull/28556/files/a9628846..345ba380 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556 PR: https://git.openjdk.org/jdk/pull/28556 From redestad at openjdk.org Mon Dec 1 16:13:38 2025 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 1 Dec 2025 16:13:38 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v5] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 16:09:02 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Add fixes from @cl4es review comments Microbenchmark looks good ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28556#pullrequestreview-3525830663 From coleenp at openjdk.org Mon Dec 1 16:33:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 16:33:40 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads In-Reply-To: References: Message-ID: <5Kyr8K4_4bRh9Ob8QDoItE_gTQqYYy8gig_rAco_Ufo=.0185cd3f-0302-4b69-9292-e807eae2de6e@github.com> On Wed, 29 Oct 2025 18:54:09 GMT, Leonid Mesnik wrote: > The vm.defmeth stress tests should use > `TestThreadFactory.newThread()` > to start virtual threads if test thread factory is used. This seems quite reasonable. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28048#pullrequestreview-3525928981 From pchilanomate at openjdk.org Mon Dec 1 16:47:25 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 1 Dec 2025 16:47:25 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 18:54:09 GMT, Leonid Mesnik wrote: > The vm.defmeth stress tests should use > `TestThreadFactory.newThread()` > to start virtual threads if test thread factory is used. Looks good to me. test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java line 98: > 96: this.rand = new Random(seed); > 97: this.thread = TestThreadFactory.newThread(this, id); > 98: thread.setName(id); Isn't this already set by `TestThreadFactory.newThread(this, id)`? ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28048#pullrequestreview-3525996141 PR Review Comment: https://git.openjdk.org/jdk/pull/28048#discussion_r2577844273 From iris at openjdk.org Mon Dec 1 17:15:11 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 1 Dec 2025 17:15:11 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/3b597a10...e5214614 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3526121001 From liach at openjdk.org Mon Dec 1 18:27:34 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 18:27:34 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: bracket styles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/7a1cfa4a..d353bdbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From heidinga at openjdk.org Mon Dec 1 18:55:09 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 1 Dec 2025 18:55:09 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: <-9yglNAoD81NuGyLSS0ehpkPZmqK66Qyd7h4UFcztGA=.56a84f5e-a29a-4fc0-b0d7-ce20cac37851@github.com> On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles A bit of meta-question about this PR and JEP 500: does this trust need to be rescinded if the user explicitly adds `--enable-final-field-mutation=` for the modules that contain these classes marked with the annotation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598347264 From fthevenet at openjdk.org Mon Dec 1 18:56:39 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Mon, 1 Dec 2025 18:56:39 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags Message-ID: This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. ------------- Commit messages: - Added a jtreg test - JDK-8372802: PrintFlagsFinal should also print locked flags Changes: https://git.openjdk.org/jdk/pull/28579/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372802 Stats: 76 lines in 2 files changed: 75 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28579.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28579/head:pull/28579 PR: https://git.openjdk.org/jdk/pull/28579 From duke at openjdk.org Mon Dec 1 19:00:12 2025 From: duke at openjdk.org (Tres Finocchiaro) Date: Mon, 1 Dec 2025 19:00:12 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 11:22:05 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 possibility 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 t... > > Sergey Chernyshev 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 seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8319589 > - Removed unused native method > - addressed review comment #2 > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > Co-authored-by: Andrey Turbanov > - addressed review comments > - 8319589: Attach from root to a user java process not supported in Mac Someone please bump this. I don't have access to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3598373427 From lmesnik at openjdk.org Mon Dec 1 19:25:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 1 Dec 2025 19:25:19 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads [v2] In-Reply-To: References: Message-ID: > The vm.defmeth stress tests should use > `TestThreadFactory.newThread()` > to start virtual threads if test thread factory is used. Leonid Mesnik 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: - removed setName - Merge branch 'master' of https://github.com/openjdk/jdk into 8370905 - 8370905: Update vm.defmeth tests to use virtual threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28048/files - new: https://git.openjdk.org/jdk/pull/28048/files/4d6d6786..cee025e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28048&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28048&range=00-01 Stats: 319462 lines in 2913 files changed: 206267 ins; 71095 del; 42100 mod Patch: https://git.openjdk.org/jdk/pull/28048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28048/head:pull/28048 PR: https://git.openjdk.org/jdk/pull/28048 From lmesnik at openjdk.org Mon Dec 1 19:25:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 1 Dec 2025 19:25:19 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads [v2] In-Reply-To: References: Message-ID: <0sD6isw1Nacf_Bd_jhCJ47P0zePKtgEC6K79fiAj6jo=.43c8b3ea-e749-4c45-b937-3256d3e4f3cf@github.com> On Mon, 1 Dec 2025 19:22:11 GMT, Leonid Mesnik wrote: >> The vm.defmeth stress tests should use >> `TestThreadFactory.newThread()` >> to start virtual threads if test thread factory is used. > > Leonid Mesnik 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: > > - removed setName > - Merge branch 'master' of https://github.com/openjdk/jdk into 8370905 > - 8370905: Update vm.defmeth tests to use virtual threads Removed setName() ------------- PR Review: https://git.openjdk.org/jdk/pull/28048#pullrequestreview-3526136121 From lmesnik at openjdk.org Mon Dec 1 19:25:20 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 1 Dec 2025 19:25:20 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 16:43:59 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik 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: >> >> - removed setName >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8370905 >> - 8370905: Update vm.defmeth tests to use virtual threads > > test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java line 98: > >> 96: this.rand = new Random(seed); >> 97: this.thread = TestThreadFactory.newThread(this, id); >> 98: thread.setName(id); > > Isn't this already set by `TestThreadFactory.newThread(this, id)`? Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28048#discussion_r2577952494 From lmesnik at openjdk.org Mon Dec 1 19:27:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 1 Dec 2025 19:27:58 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:56:54 GMT, Frederic Thevenet wrote: > This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` > > This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). > > Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. Marked as reviewed by lmesnik (Reviewer). test/hotspot/jtreg/runtime/CommandLine/PrintAllFlags.java line 30: > 28: * +UnlockDiagnosticVMOptions are set than when they aren't. > 29: * @requires vm.flagless > 30: * @modules java.base/jdk.internal.misc Is it needed? I don't see internal API usage. ------------- PR Review: https://git.openjdk.org/jdk/pull/28579#pullrequestreview-3526616134 PR Review Comment: https://git.openjdk.org/jdk/pull/28579#discussion_r2578333944 From darcy at openjdk.org Mon Dec 1 19:48:53 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 19:48:53 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/bec8ec07...e5214614 src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 394: > 392: * > 393: * @see 394: * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html"> Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578389248 From darcy at openjdk.org Mon Dec 1 19:52:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 19:52:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: <9vzVbgAOcM7Svoy5DoqhDVY4Tn2bysq9WAYpMsBcenc=.441a1ba8-3e46-41d2-bf77-afb86fe8515c@github.com> On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/04b667ed...e5214614 src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368: > 1366: } > 1367: > 1368: private static String formatAbbreviatedList(Collection values) { I think changing the policy here is okay, but it should be better documented in comments here. Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578399308 From fthevenet at openjdk.org Mon Dec 1 20:18:48 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Mon, 1 Dec 2025 20:18:48 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:23:52 GMT, Leonid Mesnik wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > test/hotspot/jtreg/runtime/CommandLine/PrintAllFlags.java line 30: > >> 28: * +UnlockDiagnosticVMOptions are set than when they aren't. >> 29: * @requires vm.flagless >> 30: * @modules java.base/jdk.internal.misc > > Is it needed? I don't see internal API usage. You're right of course, it isn't needed. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28579#discussion_r2578496052 From liach at openjdk.org Mon Dec 1 20:23:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:23:49 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles This PR currently does not interact with JEP 500. However, as specified in `Field.set`, the result of setting a final field may be ignored, as Alan [commented](https://github.com/openjdk/jdk/pull/28540#discussion_r2573494589). So I don't think we need to rescind the current trusting even if users enable mutations. In addition, @DanHeidinga I made the same fault as you when I first saw `--enable-final-field-mutation=` - this actually represents the callers, instead of the target, of `Field.set`. The target of mutation is specified via `--add-opens`, if the target field is not public. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598676839 From fthevenet at openjdk.org Mon Dec 1 20:24:06 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Mon, 1 Dec 2025 20:24:06 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v2] In-Reply-To: References: Message-ID: > This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` > > This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). > > Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary jdk.internal.misc module declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28579/files - new: https://git.openjdk.org/jdk/pull/28579/files/96ce8390..6cdac8e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28579.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28579/head:pull/28579 PR: https://git.openjdk.org/jdk/pull/28579 From mgronlun at openjdk.org Mon Dec 1 20:36:37 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Dec 2025 20:36:37 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v8] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: GROUP BY definedClass is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/ba54d2af..9782480e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From mgronlun at openjdk.org Mon Dec 1 22:11:41 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Dec 2025 22:11:41 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v9] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: Remove class definitions view in favor of jdk.ClassDefine event view ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/9782480e..6a3a8c16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=07-08 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From erikj at openjdk.org Mon Dec 1 22:24:07 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Dec 2025 22:24:07 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/193bb114...e5214614 make/conf/version-numbers.conf line 40: > 38: DEFAULT_VERSION_CLASSFILE_MINOR=0 > 39: DEFAULT_VERSION_DOCS_API_SINCE=11 > 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26" Need to add 27 to this line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578923651 From vlivanov at openjdk.org Mon Dec 1 22:30:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 1 Dec 2025 22:30:52 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:25:19 GMT, Leonid Mesnik wrote: >> The vm.defmeth stress tests should use >> `TestThreadFactory.newThread()` >> to start virtual threads if test thread factory is used. > > Leonid Mesnik 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: > > - removed setName > - Merge branch 'master' of https://github.com/openjdk/jdk into 8370905 > - 8370905: Update vm.defmeth tests to use virtual threads Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28048#pullrequestreview-3527313717 From mgronlun at openjdk.org Mon Dec 1 23:12:29 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Dec 2025 23:12:29 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v10] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: correct trunctation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/6a3a8c16..b659a814 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From dlsmith at openjdk.org Mon Dec 1 23:36:54 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Mon, 1 Dec 2025 23:36:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 15:58:38 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: >> >>> 380: * >>> 381: * @see >> 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> >> >> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. > > Great idea Chen, I will open a PR for this today Better to use a relative url now and stop bumping the version with each release: href="../../../../specs/jvms/index.html" (Check my work on the number of dots, may be one or two off.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579082529 From darcy at openjdk.org Mon Dec 1 23:52:47 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 23:52:47 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 23:34:16 GMT, Dan Smith wrote: >> Great idea Chen, I will open a PR for this today > > Better to use a relative url now and stop bumping the version with each release: > > > href="../../../../specs/jvms/index.html" > > > (Check my work on the number of dots, may be one or two off.) I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579106368 From dlsmith at openjdk.org Tue Dec 2 00:35:54 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Tue, 2 Dec 2025 00:35:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 23:50:29 GMT, Joe Darcy wrote: >> Better to use a relative url now and stop bumping the version with each release: >> >> >> href="../../../../specs/jvms/index.html" >> >> >> (Check my work on the number of dots, may be one or two off.) > > I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1). Oh, yes, thanks Joe, I'd missed that context. If the goal is to have a stable URL that will always point to the snapshot for a given version, yes, you want the full URL, and this updated URL looks like the correct one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579166554 From duke at openjdk.org Tue Dec 2 00:55:59 2025 From: duke at openjdk.org (Larry Cable) Date: Tue, 2 Dec 2025 00:55:59 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 11:22:05 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 possibility 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 t... > > Sergey Chernyshev 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 seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8319589 > - Removed unused native method > - addressed review comment #2 > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > Co-authored-by: Andrey Turbanov > - addressed review comments > - 8319589: Attach from root to a user java process not supported in Mac we need someone with reviewer status to approve this for integration ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3599624713 From vlivanov at openjdk.org Tue Dec 2 02:26:46 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:26:46 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:01:08 GMT, Chen Liang wrote: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. @liach Thanks for taking care of the fix. Here's a more polished version: https://github.com/openjdk/jdk/commit/c6c4e9f23a1bdf801d0cc8e36f343543b8bfccda ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3599884931 From liach at openjdk.org Tue Dec 2 02:52:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 02:52:50 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:01:08 GMT, Chen Liang wrote: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. I have one question: would it be safer for us to move the constant detection after generate_virtual_guard in the `is_virtual` if block? I think it may be possible for users to create a `Object::hashCode` site with a constant receiver that is of a specialized class that overrides `hashCode`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3599934103 From thartmann at openjdk.org Tue Dec 2 06:44:49 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 2 Dec 2025 06:44:49 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 02:49:52 GMT, Chen Liang wrote: > I think it may be possible for users to create a Object::hashCode site with a constant receiver that is of a specialized class that overrides hashCode. Yes, I think so too. We need a test for this scenario. Just an observation: This patch will only allow folding during parsing. I would expect that often, opportunities only arise after other optimizations already took place. For example, something like this would not be optimized if we run with `-XX:+AlwaysIncrementalInline`, right? static final Object a = new Object(); @ForceInline public Object getter(Object obj) { return obj; } public long test() { return getter(a).hashCode(); } Another example: Object val = new Object(); int limit = 2; for (; limit < 4; limit *= 2); for (int i = 2; i < limit; i++) { val = a; } return val.hashCode(); // After loop opts, C2 knows that val == a So ideally, we would move this optimization to IGVN. This would also help Valhalla, where we need to (re-)compute the hashcode for a scalarized value object and would therefore like to fold the computation as aggressively as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3600438904 From dholmes at openjdk.org Tue Dec 2 09:18:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 09:18:10 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 11:42:45 GMT, Jonas Norlinder wrote: >> src/hotspot/os/linux/os_linux.cpp line 4968: >> >>> 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. >>> 4967: static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) { >>> 4968: constexpr clockid_t CLOCK_TYPE_MASK = 3; >> >> Shouldn't the mask be covering 3-bits? > > No we should not touch bit 3 which encodes if the clock is for a thread of process. See here https://elixir.bootlin.com/linux/v6.17.9/source/include/linux/posix-timers_types.h#L9-L19. Okay so > encoding the clock types in the last three bits needs a bit more explanation. >> src/hotspot/os/linux/os_linux.cpp line 4979: >> >>> 4977: // to detach itself from the VM - which should result in ESRCH. >>> 4978: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >>> 4979: *success = false; >> >> The normal way I've seen this pattern used is to set it to true rather than assuming it was true to begin with. > > Using a positive outcome like success to encode the outcome make it possible to return like so `return success ? os::Linux::thread_cpu_time(clockid) : -1;`. I prefer having the `-1` at the end as I find this reads easier. If we encode a failure we would need to write `return !failure ? os::Linux::thread_cpu_time(clockid) : -1;`. Hence, I would prefer keeping this as is as double-negatives may be harder to parse. Okay but you are setting up a usage requirement without documenting anywhere that that requirement exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580306175 PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580309226 From dholmes at openjdk.org Tue Dec 2 09:30:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 09:30:03 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v5] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 16:09:02 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Add fixes from @cl4es review comments src/hotspot/os/linux/os_linux.cpp line 4966: > 4964: // for the Linux kernel defaults to construct a clockid with 010 (CPUCLOCK_SCHED) > 4965: // set, which return system+user time, which is what the POSIX standard mandates, see > 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. I think the bit encoding could be made somewhat clearer. // Since kernel v2.6.12 the Linux ABI has had support for encoding the clock types in // the last three bits. Bit 2 indicates whether a cpu clock refers to a thread or a process. // Bits 1 and 0 give the type: PROF=0, VIRT=1, SCHED=2, or FD=3. // The clock CPUCLOCK_VIRT (0b001) reports the thread's consumed user time. // POSIX compliant implementations of pthread_getcpuclockid return the clock CPUCLOCK_SCHED // (0b010) which reports the thread's consumed system+user time (as mandated by the POSIX // standard POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90) src/hotspot/os/linux/os_linux.cpp line 4967: > 4965: // set, which return system+user time, which is what the POSIX standard mandates, see > 4966: // POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. > 4967: static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) { Suggestion: // The out parameter `success` is required to be initialized to `true`. static clockid_t get_thread_clockid(Thread* thread, bool total, bool* success) { assert(success != nullptr && *success, "incorrect initialization"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580342601 PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2580349403 From dholmes at openjdk.org Tue Dec 2 09:39:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 09:39:20 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 20:24:06 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary jdk.internal.misc module declaration I think this seems reasonable. Have you run all of the tests that use this flag to check that the extra output does not cause any problems (e.g. if jtreg elides sections of the log because it is too long now)? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28579#pullrequestreview-3529140282 From dholmes at openjdk.org Tue Dec 2 09:45:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 09:45:52 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: <2Pa32ipOuPa9thyQvPlXQ5AZi34kbxs_SPGlivudyA8=.865ecd6f-891b-49a4-b472-2f663e186e58@github.com> On Wed, 29 Oct 2025 23:29:23 GMT, Serguei Spitsyn wrote: >> @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert. > >> @sspitsyn and @sercher I'll take a look since I familiar with the code and the platform... > > Okay. Thank you, Larry! We need two reviewers. It doesn't look like @sspitsyn got to this and I am unsure what @larry-cable 's view is. The PR also needs to be refreshed as so much time has passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3601126930 From aartemov at openjdk.org Tue Dec 2 10:28:16 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 2 Dec 2025 10:28:16 GMT Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension request [v19] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible: > > The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. > > This can happen in two places where the successor could be suspended: > 1: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 > > 2: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 > > The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. > > The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again. The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events. > > Tests are added for both scenarios. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Fixed semi-broken tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/8283d9c0..d45fc76b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=17-18 Stats: 58 lines in 4 files changed: 49 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From ayang at openjdk.org Tue Dec 2 12:08:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Dec 2025 12:08:52 GMT Subject: RFR: 8372755: Remove local suppression of VS C4146 warnings In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 10:20:50 GMT, Kim Barrett wrote: > Please review this trivial change to remove unnecessary local Visual Studio > warning suppressions for C4146 in HotSpot code. JDK-8254072 intentionally > globally suppressed that warning when building HotSpot, so local suppression > is no longer needed. > > Testing: mach5 tier1 Trivial. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28564#pullrequestreview-3529742316 From aboldtch at openjdk.org Tue Dec 2 13:09:22 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 2 Dec 2025 13:09:22 GMT Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 15:41:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them. > > There is no problematic `ResourceMark` though, so there should be no current impact. > > Testing: gha > > Thanks, > Thomas lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28510#pullrequestreview-3530014324 From ayang at openjdk.org Tue Dec 2 13:09:33 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Dec 2025 13:09:33 GMT Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:35:42 GMT, Albert Mingkun Yang wrote: >> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early. >> >> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path. >> >> >> Test: tier1 > > Albert Mingkun Yang 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 six additional commits since the last revision: > > - Merge branch 'master' into smap-parser > - review > - copyright-header > - review > - Merge branch 'master' into smap-parser > - smap-parser Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28225#issuecomment-3601938896 From ayang at openjdk.org Tue Dec 2 13:09:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Dec 2025 13:09:35 GMT Subject: Integrated: 8371587: Final mapping lost in ProcSmapsParser::parse_next In-Reply-To: References: Message-ID: <6PecK0y7kvW9JX5pOGBT1f1XJhT9MFZKZG-xN5rLBPc=.110c12d0-2a51-4b0f-90bc-14f5cfb73940@github.com> On Mon, 10 Nov 2025 21:18:23 GMT, Albert Mingkun Yang wrote: > A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early. > > The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path. > > > Test: tier1 This pull request has now been integrated. Changeset: eecba58c Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/eecba58c6817dbac129c545604d6286dfdcf951f Stats: 131 lines in 3 files changed: 117 ins; 6 del; 8 mod 8371587: Final mapping lost in ProcSmapsParser::parse_next Reviewed-by: jsjolen, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/28225 From jnorlinder at openjdk.org Tue Dec 2 13:10:35 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 2 Dec 2025 13:10:35 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v6] In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: > Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. > > This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). > > Before patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > CPUTime.execute:p0.00 sample 0.008 ms/op > CPUTime.execute:p0.50 sample 0.008 ms/op > CPUTime.execute:p0.90 sample 0.008 ms/op > CPUTime.execute:p0.95 sample 0.008 ms/op > CPUTime.execute:p0.99 sample 0.012 ms/op > CPUTime.execute:p0.999 sample 0.015 ms/op > CPUTime.execute:p0.9999 sample 0.021 ms/op > CPUTime.execute:p1.00 sample 1.030 ms/op > > > After patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 8984189 ? 10?? ms/op > CPUTime.execute:p0.00 sample ? 10?? ms/op > CPUTime.execute:p0.50 sample ? 10?? ms/op > CPUTime.execute:p0.90 sample ? 10?? ms/op > CPUTime.execute:p0.95 sample ? 10?? ms/op > CPUTime.execute:p0.99 sample 0.001 ms/op > CPUTime.execute:p0.999 sample 0.001 ms/op > CPUTime.execute:p0.9999 sample 0.006 ms/op > CPUTime.execute:p1.00 sample 0.054 ms/op > > > Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Add fixes for @dholmes-ora review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28556/files - new: https://git.openjdk.org/jdk/pull/28556/files/345ba380..902b7787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=04-05 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556 PR: https://git.openjdk.org/jdk/pull/28556 From jsjolen at openjdk.org Tue Dec 2 13:46:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Dec 2025 13:46:02 GMT Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 15:41:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them. > > There is no problematic `ResourceMark` though, so there should be no current impact. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28510#pullrequestreview-3530216802 From kbarrett at openjdk.org Tue Dec 2 13:58:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 2 Dec 2025 13:58:52 GMT Subject: RFR: 8372755: Remove local suppression of VS C4146 warnings In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 12:05:56 GMT, Albert Mingkun Yang wrote: >> Please review this trivial change to remove unnecessary local Visual Studio >> warning suppressions for C4146 in HotSpot code. JDK-8254072 intentionally >> globally suppressed that warning when building HotSpot, so local suppression >> is no longer needed. >> >> Testing: mach5 tier1 > > Trivial. Thanks for reviewing @albertnetymk . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28564#issuecomment-3602193658 From kbarrett at openjdk.org Tue Dec 2 13:58:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 2 Dec 2025 13:58:54 GMT Subject: Integrated: 8372755: Remove local suppression of VS C4146 warnings In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 10:20:50 GMT, Kim Barrett wrote: > Please review this trivial change to remove unnecessary local Visual Studio > warning suppressions for C4146 in HotSpot code. JDK-8254072 intentionally > globally suppressed that warning when building HotSpot, so local suppression > is no longer needed. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 6f2169ff Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/6f2169ff6996e0629ce80455959a21947fd5de2c Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod 8372755: Remove local suppression of VS C4146 warnings Reviewed-by: ayang ------------- PR: https://git.openjdk.org/jdk/pull/28564 From nbenalla at openjdk.org Tue Dec 2 14:57:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 14:57:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v8] In-Reply-To: References: Message-ID: <8Fxjqxz7uHKELjvLEjJg4Zvkbs38Bz52UcbJJYkkN4I=.09b0c42a-4b86-4ba9-9a31-d0a7b60af3fe@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - revert MAX_COLUMNS to 80 - Update LATEST_MAJOR_VERSION in Versions.java - Merge branch 'master' into start-of-release-27 - ... and 8 more: https://git.openjdk.org/jdk/compare/759d7098...b47b9ee9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/e5214614..b47b9ee9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=06-07 Stats: 7726 lines in 83 files changed: 2728 ins; 4423 del; 575 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Dec 2 15:07:11 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 15:07:11 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: References: Message-ID: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - revert changes to avoid conflict - add 27 to the acceptable boot versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/b47b9ee9..1237304b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=07-08 Stats: 49 lines in 4 files changed: 8 ins; 29 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Dec 2 15:07:16 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 15:07:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 22:20:34 GMT, Erik Joelsson wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/8736a894...e5214614 > > make/conf/version-numbers.conf line 40: > >> 38: DEFAULT_VERSION_CLASSFILE_MINOR=0 >> 39: DEFAULT_VERSION_DOCS_API_SINCE=11 >> 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26" > > Need to add 27 to this line. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/061986c2fa56bcf1411f479c5b76602f63dc93c3, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2581577462 From stuefe at openjdk.org Tue Dec 2 15:08:47 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 2 Dec 2025 15:08:47 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: <3N2-47etRsWRrfCcYo_ul4UMhXu4Z9Y_yyx1uUgqcaM=.82d606c7-05b4-4879-8ae5-f8305be8a334@github.com> On Tue, 2 Dec 2025 09:15:31 GMT, David Holmes wrote: >> Using a positive outcome like success to encode the outcome make it possible to return like so `return success ? os::Linux::thread_cpu_time(clockid) : -1;`. I prefer having the `-1` at the end as I find this reads easier. If we encode a failure we would need to write `return !failure ? os::Linux::thread_cpu_time(clockid) : -1;`. Hence, I would prefer keeping this as is as double-negatives may be harder to parse. > > Okay but you are setting up a usage requirement without documenting anywhere that that requirement exists. I would prefer if we kept using the standard. When in Rome... What we often do is this: bool get_thread_clockid(Thread* thread, bool total, clock_id_t* is); or, alternatively, what David wrote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2581600332 From schernyshev at openjdk.org Tue Dec 2 15:46:10 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 15:46:10 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v7] In-Reply-To: References: 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. Previously, JDK-8197387 introduced the same possibility 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... Sergey Chernyshev 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 eight additional commits since the last revision: - Merge branch 'master' into JDK-8319589 - Merge branch 'master' into JDK-8319589 - Removed unused native method - addressed review comment #2 - Apply suggestions from code review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Co-authored-by: Andrey Turbanov - addressed review comments - 8319589: Attach from root to a user java process not supported in Mac ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25824/files - new: https://git.openjdk.org/jdk/pull/25824/files/75dd6fb8..8118017f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=05-06 Stats: 391287 lines in 4297 files changed: 249688 ins; 89814 del; 51785 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 mgronlun at openjdk.org Tue Dec 2 15:59:00 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 2 Dec 2025 15:59:00 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v11] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/b659a814..66e63a40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=09-10 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From mgronlun at openjdk.org Tue Dec 2 16:11:17 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 2 Dec 2025 16:11:17 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v12] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: restore longest-class-loading view ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/66e63a40..3a44c10e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=10-11 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From kvn at openjdk.org Tue Dec 2 16:46:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Dec 2025 16:46:00 GMT Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 15:41:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them. > > There is no problematic `ResourceMark` though, so there should be no current impact. > > Testing: gha > > Thanks, > Thomas Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28510#pullrequestreview-3531141077 From mgronlun at openjdk.org Tue Dec 2 16:50:47 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 2 Dec 2025 16:50:47 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v13] In-Reply-To: References: Message-ID: <4EZHq7TmhEpxqD3WRm4D8LHVXPuJabCRjTXOi0pPtZE=.866ecc1e-b0be-4797-a6f9-2a434a087bda@github.com> > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: use strcmp instead of strncmp for equals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/3a44c10e..c2e36d2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From coleenp at openjdk.org Tue Dec 2 17:05:07 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Dec 2025 17:05:07 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:33:19 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. >> >> Testing: >> - Oracle tier 1 >> - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > change flag type to int Yes, this looks good. Changing to int was a good idea. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28576#pullrequestreview-3531239723 From phubner at openjdk.org Tue Dec 2 17:05:06 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 2 Dec 2025 17:05:06 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:33:19 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. >> >> Testing: >> - Oracle tier 1 >> - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > change flag type to int Thanks for doing this! ------------- Marked as reviewed by phubner (Author). PR Review: https://git.openjdk.org/jdk/pull/28576#pullrequestreview-3531223481 From fthevenet at openjdk.org Tue Dec 2 17:12:32 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 2 Dec 2025 17:12:32 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 09:36:19 GMT, David Holmes wrote: > Have you run all of the tests that use this flag to check that the extra output does not cause any problems (e.g. if jtreg elides sections of the log because it is too long now)? In addition to running tier1 on GHA, I also explicitly ran the tests that matched the following: ``` find ./test -type f -name "*.java" -exec grep -l -e "-XX:+PrintFlagsFinal" -e "-XX:+PrintFlagsInitial" -e "-XX:+PrintFlagsWithComments" -e "PrintVMFlagsDCmd" {} + Hopefully that caught them all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28579#issuecomment-3603117608 From erikj at openjdk.org Tue Dec 2 18:10:00 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 2 Dec 2025 18:10:00 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3531491706 From lmesnik at openjdk.org Tue Dec 2 18:10:23 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 2 Dec 2025 18:10:23 GMT Subject: Integrated: 8370905: Update vm.defmeth tests to use virtual threads In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 18:54:09 GMT, Leonid Mesnik wrote: > The vm.defmeth stress tests should use > `TestThreadFactory.newThread()` > to start virtual threads if test thread factory is used. This pull request has now been integrated. Changeset: 153c567a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/153c567a4d3a537277a8c599142511aa4f4f3ae3 Stats: 13 lines in 1 file changed: 3 ins; 0 del; 10 mod 8370905: Update vm.defmeth tests to use virtual threads Reviewed-by: vlivanov, coleenp, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/28048 From dholmes at openjdk.org Tue Dec 2 19:49:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 19:49:41 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 00:53:15 GMT, Larry Cable wrote: >> Sergey Chernyshev 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8319589 >> - Removed unused native method >> - addressed review comment #2 >> - Apply suggestions from code review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> >> Co-authored-by: Andrey Turbanov >> - addressed review comments >> - 8319589: Attach from root to a user java process not supported in Mac > > we need someone with reviewer status to approve this for integration @larry-cable you can still "review" via the PR, rather than just email. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3603697996 From dholmes at openjdk.org Tue Dec 2 20:38:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 20:38:02 GMT Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests. > > Testing: gha > > Thanks, > Thomas Seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28396#pullrequestreview-3532011398 From vlivanov at openjdk.org Tue Dec 2 20:39:55 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:39:55 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 02:49:52 GMT, Chen Liang wrote: > would it be safer for us to move the constant detection after generate_virtual_guard in the is_virtual if block? Good catch. I missed that the intrinsic is shared between `System::identityHashCode()` and `Object::hashCode`. I'm not sure it makes sense to support `Object::hashCode` unless C2 can eliminate `generate_virtual_guard` for a constant receiver. I'd just limit constant folding to `!is_virtual` case for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3603869560 From vlivanov at openjdk.org Tue Dec 2 20:45:38 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:45:38 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 06:42:32 GMT, Tobias Hartmann wrote: > Just an observation: This patch will only allow folding during parsing. I would expect that often, opportunities only arise after other optimizations already took place. I deliberately omitted post-parse optimization opportunities for now. It would require a gradual lowering of the representation from a high-level macro node to low-level poking at object header. Moreover, final representation has complex control, so either the macro node should be a CFG node or a way to determine a location in CFG for a data-only macro node and expanding it there needs to be supported. (There are other use cases for such functionality, like lowering data nodes into pure calls, but no readily available implementation is there yet.) IMO something to work on in a follow-up enhancement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3603886860 From vlivanov at openjdk.org Tue Dec 2 20:56:18 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:56:18 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:36:50 GMT, Vladimir Ivanov wrote: > I'm not sure it makes sense to support Object::hashCode unless C2 can eliminate generate_virtual_guard for a constant receiver. I'd just limit constant folding to !is_virtual case for now. Or, alternatively, inspect constant object's v-table during compilation and ensure that corresponding slot points at `Object::hashCode`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3603919570 From jnorlinder at openjdk.org Tue Dec 2 20:59:41 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 2 Dec 2025 20:59:41 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> > Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. > > This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). > > Before patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > CPUTime.execute:p0.00 sample 0.008 ms/op > CPUTime.execute:p0.50 sample 0.008 ms/op > CPUTime.execute:p0.90 sample 0.008 ms/op > CPUTime.execute:p0.95 sample 0.008 ms/op > CPUTime.execute:p0.99 sample 0.012 ms/op > CPUTime.execute:p0.999 sample 0.015 ms/op > CPUTime.execute:p0.9999 sample 0.021 ms/op > CPUTime.execute:p1.00 sample 1.030 ms/op > > > After patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 8984189 ? 10?? ms/op > CPUTime.execute:p0.00 sample ? 10?? ms/op > CPUTime.execute:p0.50 sample ? 10?? ms/op > CPUTime.execute:p0.90 sample ? 10?? ms/op > CPUTime.execute:p0.95 sample ? 10?? ms/op > CPUTime.execute:p0.99 sample 0.001 ms/op > CPUTime.execute:p0.999 sample 0.001 ms/op > CPUTime.execute:p0.9999 sample 0.006 ms/op > CPUTime.execute:p1.00 sample 0.054 ms/op > > > Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Align signature to standard ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28556/files - new: https://git.openjdk.org/jdk/pull/28556/files/902b7787..d70c8cae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=05-06 Stats: 21 lines in 1 file changed: 7 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556 PR: https://git.openjdk.org/jdk/pull/28556 From jnorlinder at openjdk.org Tue Dec 2 20:59:43 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 2 Dec 2025 20:59:43 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v3] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: On Mon, 1 Dec 2025 04:00:58 GMT, David Holmes wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused imports > > @JonasNorlinder this PR isn't fixing two issue. I think [JDK-8372584](https://bugs.openjdk.org/browse/JDK-8372584) should just be closed as a duplicate of [JDK-8210452](https://bugs.openjdk.org/browse/JDK-8210452) (which I had forgotten about and which @larry-cable did not get further with). Thanks for the comments @dholmes-ora and @tstuefe. I changed to aligning the signature to the standard. That way we don't have to document any requirements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28556#issuecomment-3603921763 From kvn at openjdk.org Tue Dec 2 21:00:58 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Dec 2025 21:00:58 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:01:08 GMT, Chen Liang wrote: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Good. Yes, we can work on constant folding in IGVN later. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28589#pullrequestreview-3532076661 From kvn at openjdk.org Tue Dec 2 21:01:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Dec 2025 21:01:00 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:53:56 GMT, Vladimir Ivanov wrote: >>> would it be safer for us to move the constant detection after generate_virtual_guard in the is_virtual if block? >> >> Good catch. I missed that the intrinsic is shared between `System::identityHashCode()` and `Object::hashCode`. >> >> I'm not sure it makes sense to support `Object::hashCode` unless C2 can eliminate `generate_virtual_guard` for a constant receiver. I'd just limit constant folding to `!is_virtual` case for now. > >> I'm not sure it makes sense to support Object::hashCode unless C2 can eliminate generate_virtual_guard for a constant receiver. I'd just limit constant folding to !is_virtual case for now. > > Or, alternatively, inspect constant object's v-table during compilation and ensure that corresponding slot points at `Object::hashCode`. @iwanowww please fix title to match JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3603933760 From vlivanov at openjdk.org Tue Dec 2 22:28:01 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 22:28:01 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:58:23 GMT, Vladimir Kozlov wrote: >>> I'm not sure it makes sense to support Object::hashCode unless C2 can eliminate generate_virtual_guard for a constant receiver. I'd just limit constant folding to !is_virtual case for now. >> >> Or, alternatively, inspect constant object's v-table during compilation and ensure that corresponding slot points at `Object::hashCode`. > > @iwanowww please fix title to match JBS. @vnkozlov I can't since I'm not the author of the PR :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3604211003 From liach at openjdk.org Tue Dec 2 23:18:26 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:18:26 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v2] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang 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: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Cleanup - identity hash support in C2 - Move around - Constant fold identity hash ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/4a82f79d..69225241 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=00-01 Stats: 4382 lines in 99 files changed: 2947 ins; 684 del; 751 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From liach at openjdk.org Tue Dec 2 23:18:28 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:18:28 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:01:08 GMT, Chen Liang wrote: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. I tried to come up with an example where the buggy code from Vladimir would inline to identityHashCode when the right call would be virtual - couldn't construct such a case unfortunately :( I think we can deal with IGVN later, as this involves creating new macro node and other infrastructure support. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3604321567 From liach at openjdk.org Tue Dec 2 23:25:29 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:25:29 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/69225241..b1d8be39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From darcy at openjdk.org Wed Dec 3 01:34:19 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 3 Dec 2025 01:34:19 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 483: > 481: */ > 482: RELEASE_26, > 483: At the top of the file where the per-release changes are all listed, please add a "27: tbd" entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2583333814 From dholmes at openjdk.org Wed Dec 3 01:49:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Dec 2025 01:49:02 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] In-Reply-To: <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> Message-ID: On Tue, 2 Dec 2025 20:59:41 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Align signature to standard Looks good. Thanks for the updates. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28556#pullrequestreview-3532826717 From iris at openjdk.org Wed Dec 3 02:12:00 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 3 Dec 2025 02:12:00 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3532863059 From sspitsyn at openjdk.org Wed Dec 3 03:31:09 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 03:31:09 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v7] In-Reply-To: References: Message-ID: <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com> On Tue, 2 Dec 2025 15:46:10 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 possibility 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 t... > > Sergey Chernyshev 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 eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8319589 > - Merge branch 'master' into JDK-8319589 > - Removed unused native method > - addressed review comment #2 > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > Co-authored-by: Andrey Turbanov > - addressed review comments > - 8319589: Attach from root to a user java process not supported in Mac src/hotspot/os/bsd/os_bsd.cpp line 881: > 879: uid_t uid = get_process_uid(pid); > 880: return (uid != (uid_t)-1) ? os::Posix::is_root(uid) : false; > 881: } Nit: - missed dot at the end of comments at lines 864, 877 - indent above has to be 2, not 4 src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 78: > 76: // Then we attempt to find the socket file again. > 77: // In macOS the socket file is located in per-user temp directory. > 78: String tempDir = getTempDirFromPid(pid); Nit: I'd suggest to rename it to `tempdir` to follow the local naming convention which prevails. src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 223: > 221: } > 222: > 223: private File createAttachFile(String dir, int pid) throws IOException { Nit: I'd suggest to rename `dir` to `tmpdir` to keep it unified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583476499 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583485123 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583487596 From sspitsyn at openjdk.org Wed Dec 3 03:31:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 03:31:12 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v2] In-Reply-To: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com> References: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com> <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com> Message-ID: On Tue, 23 Sep 2025 02:40:48 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/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 31: > >> 29: import com.sun.tools.attach.spi.AttachProvider; >> 30: >> 31: import sun.jvmstat.PlatformSupport; > > This is convenient but I'm not sure it is appropriate. Need the serviceability folk to comment. This looks like an unexpected and undesired dependency. I'll consult with other serviceability guys to find out what is better here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583491666 From dholmes at openjdk.org Wed Dec 3 04:12:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Dec 2025 04:12:59 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Hotspot changes trivially fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3533103238 From schernyshev at openjdk.org Wed Dec 3 07:22:51 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 3 Dec 2025 07:22:51 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: References: Message-ID: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@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 possibility 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... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25824/files - new: https://git.openjdk.org/jdk/pull/25824/files/8118017f..fd1645b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=06-07 Stats: 18 lines in 2 files changed: 1 ins; 1 del; 16 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 Dec 3 07:23:00 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 3 Dec 2025 07:23:00 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v7] In-Reply-To: <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com> References: <82tyZ0Xz61HFwpcBRI8AabsxtM_wy3Z4WHWI-jmPkHA=.d34b5c8a-53fb-4e43-9c32-e04d5a510cad@github.com> Message-ID: On Wed, 3 Dec 2025 03:10:19 GMT, Serguei Spitsyn wrote: >> Sergey Chernyshev 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 eight additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8319589 >> - Merge branch 'master' into JDK-8319589 >> - Removed unused native method >> - addressed review comment #2 >> - Apply suggestions from code review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> >> Co-authored-by: Andrey Turbanov >> - addressed review comments >> - 8319589: Attach from root to a user java process not supported in Mac > > src/hotspot/os/bsd/os_bsd.cpp line 881: > >> 879: uid_t uid = get_process_uid(pid); >> 880: return (uid != (uid_t)-1) ? os::Posix::is_root(uid) : false; >> 881: } > > Nit: > - missed dot at the end of comments at lines 864, 877 > - indent above has to be 2, not 4 Thanks @sspitsyn , fixed. > src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 78: > >> 76: // Then we attempt to find the socket file again. >> 77: // In macOS the socket file is located in per-user temp directory. >> 78: String tempDir = getTempDirFromPid(pid); > > Nit: I'd suggest to rename it to `tempdir` to follow the local naming convention which prevails. Thanks! Fixed. > src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 223: > >> 221: } >> 222: >> 223: private File createAttachFile(String dir, int pid) throws IOException { > > Nit: I'd suggest to rename `dir` to `tmpdir` to keep it unified. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583859087 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583860448 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583860781 From schernyshev at openjdk.org Wed Dec 3 07:22:52 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 3 Dec 2025 07:22:52 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac In-Reply-To: <7fc0631a-ae51-4df2-bc7c-39369b5d6593@oracle.com> References: <7fc0631a-ae51-4df2-bc7c-39369b5d6593@oracle.com> Message-ID: On Tue, 2 Dec 2025 15:50:14 GMT, Laurence Cable wrote: > I approve but I am not a reviewer :( Thanks you @larry-cable for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3605428925 From sspitsyn at openjdk.org Wed Dec 3 07:31:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 07:31:12 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: <63PmCR3UqPLsAldxHCS78MZ7hViJqdvOg891j28uhww=.b571ab58-4b7f-413b-814e-e42ab8e7b010@github.com> On Wed, 3 Dec 2025 07:22:51 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 possibility 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 t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > addressed review comments This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? src/hotspot/os/bsd/os_bsd.cpp line 956: > 954: } > 955: #endif > 956: Nit: I'd suggest to get rid of empty lines which do not improve readability: 890, 903, 908, 917, 923, 930, 933, 941, 944 Also, the comment at line 931 is better to start with a capital letter: `// If the ..` . ------------- PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3533557192 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2583937603 From tschatzl at openjdk.org Wed Dec 3 08:11:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Dec 2025 08:11:08 GMT Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 13:06:38 GMT, Axel Boldt-Christmas wrote: >> Hi all, >> >> please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them. >> >> There is no problematic `ResourceMark` though, so there should be no current impact. >> >> Testing: gha >> >> Thanks, >> Thomas > > lgtm. Thanks @xmas92 @vnkozlov @jdksjolen for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28510#issuecomment-3605570031 From tschatzl at openjdk.org Wed Dec 3 08:11:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Dec 2025 08:11:09 GMT Subject: Integrated: 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 15:41:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them. > > There is no problematic `ResourceMark` though, so there should be no current impact. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 2139c8c6 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/2139c8c6e6e5c5f2c64ed3ad9ad8bd148a86efae Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8372571: ResourceHashTable for some AOT data structures miss placement operator when allocating Reviewed-by: aboldtch, jsjolen, kvn ------------- PR: https://git.openjdk.org/jdk/pull/28510 From duke at openjdk.org Wed Dec 3 09:17:42 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Dec 2025 09:17:42 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] In-Reply-To: <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> Message-ID: On Tue, 2 Dec 2025 20:59:41 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Align signature to standard @JonasNorlinder Your change (at version d70c8cae32269ab94e82c643aa9ba54bc7512f2e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28556#issuecomment-3605829292 From iwalulya at openjdk.org Wed Dec 3 09:24:55 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 3 Dec 2025 09:24:55 GMT Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle In-Reply-To: References: Message-ID: <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com> On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28396#pullrequestreview-3534013654 From kevinw at openjdk.org Wed Dec 3 09:35:32 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Dec 2025 09:35:32 GMT Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] In-Reply-To: <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> Message-ID: On Tue, 2 Dec 2025 20:59:41 GMT, Jonas Norlinder wrote: >> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. >> >> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). >> >> Before patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op >> CPUTime.execute:p0.00 sample 0.008 ms/op >> CPUTime.execute:p0.50 sample 0.008 ms/op >> CPUTime.execute:p0.90 sample 0.008 ms/op >> CPUTime.execute:p0.95 sample 0.008 ms/op >> CPUTime.execute:p0.99 sample 0.012 ms/op >> CPUTime.execute:p0.999 sample 0.015 ms/op >> CPUTime.execute:p0.9999 sample 0.021 ms/op >> CPUTime.execute:p1.00 sample 1.030 ms/op >> >> >> After patch: >> >> Benchmark Mode Cnt Score Error Units >> CPUTime.execute sample 8984189 ? 10?? ms/op >> CPUTime.execute:p0.00 sample ? 10?? ms/op >> CPUTime.execute:p0.50 sample ? 10?? ms/op >> CPUTime.execute:p0.90 sample ? 10?? ms/op >> CPUTime.execute:p0.95 sample ? 10?? ms/op >> CPUTime.execute:p0.99 sample 0.001 ms/op >> CPUTime.execute:p0.999 sample 0.001 ms/op >> CPUTime.execute:p0.9999 sample 0.006 ms/op >> CPUTime.execute:p1.00 sample 0.054 ms/op >> >> >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Align signature to standard Looks good - I remember that fix for parsing the program binary name containing brackets, good to have it gone. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28556#pullrequestreview-3534064399 From jnorlinder at openjdk.org Wed Dec 3 09:38:48 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 3 Dec 2025 09:38:48 GMT Subject: Integrated: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> Message-ID: <5D6oOnP7w8IRNg_1EjKqgca5gHiO5jlsAZqln4I8Ff0=.cefffdb9-5a40-4fd6-957b-da1dcbb65f7f@github.com> On Fri, 28 Nov 2025 12:00:28 GMT, Jonas Norlinder wrote: > Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc. that utilities this bit pattern. > > This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max). > > Before patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > CPUTime.execute:p0.00 sample 0.008 ms/op > CPUTime.execute:p0.50 sample 0.008 ms/op > CPUTime.execute:p0.90 sample 0.008 ms/op > CPUTime.execute:p0.95 sample 0.008 ms/op > CPUTime.execute:p0.99 sample 0.012 ms/op > CPUTime.execute:p0.999 sample 0.015 ms/op > CPUTime.execute:p0.9999 sample 0.021 ms/op > CPUTime.execute:p1.00 sample 1.030 ms/op > > > After patch: > > Benchmark Mode Cnt Score Error Units > CPUTime.execute sample 8984189 ? 10?? ms/op > CPUTime.execute:p0.00 sample ? 10?? ms/op > CPUTime.execute:p0.50 sample ? 10?? ms/op > CPUTime.execute:p0.90 sample ? 10?? ms/op > CPUTime.execute:p0.95 sample ? 10?? ms/op > CPUTime.execute:p0.99 sample 0.001 ms/op > CPUTime.execute:p0.999 sample 0.001 ms/op > CPUTime.execute:p0.9999 sample 0.006 ms/op > CPUTime.execute:p1.00 sample 0.054 ms/op > > > Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark. This pull request has now been integrated. Changeset: 858d2e43 Author: Jonas Norlinder Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/858d2e434dd4eb8aa94784bb1cd115554eec5dff Stats: 138 lines in 3 files changed: 84 ins; 42 del; 12 mod 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime Reviewed-by: dholmes, kevinw, redestad ------------- PR: https://git.openjdk.org/jdk/pull/28556 From cnorrbin at openjdk.org Wed Dec 3 10:06:35 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 3 Dec 2025 10:06:35 GMT Subject: RFR: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:33:19 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. >> >> Testing: >> - Oracle tier 1 >> - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > change flag type to int Thank you both for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28576#issuecomment-3606030527 From cnorrbin at openjdk.org Wed Dec 3 10:06:36 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 3 Dec 2025 10:06:36 GMT Subject: Integrated: 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:00:22 GMT, Casper Norrbin wrote: > Hi everyone, > > Passing a negative value to `-XX:MinOopMapAllocation` could trigger an integer overflow. This value is used as the initial size for the `OopMap` `GrowableArray` list inside `OopMapSet`. Negative inputs hits an assert when allocating for `GrowableArray`. Restricting this flag to positive values ensures we get a clear error message instead of a crash. > > Testing: > - Oracle tier 1 > - Local tests with `-XX:MinOopMapAllocation=x`, covering both valid and invalid values. This pull request has now been integrated. Changeset: 94977063 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/94977063baafc2e293193d284db408a069f12aca Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8358706: Integer overflow with -XX:MinOopMapAllocation=-1 Reviewed-by: phubner, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/28576 From nbenalla at openjdk.org Wed Dec 3 10:18:16 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:18:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v10] In-Reply-To: References: Message-ID: <1NKVGfCOckDGbbnQKtz0LfvPFhh5SjyUauWyvbsw2yM=.ad2c7571-4ab3-4b1f-b8d7-5ab0814635c7@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - revert changes to avoid conflict - add 27 to the acceptable boot versions - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - ... and 11 more: https://git.openjdk.org/jdk/compare/443e5643...8bbe15f2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/1237304b..8bbe15f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=08-09 Stats: 3514 lines in 111 files changed: 2399 ins; 621 del; 494 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Wed Dec 3 10:31:18 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:18 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v11] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - fix jls 27 link - fix typo and add entry for 27 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/8bbe15f2..4bf97a8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=09-10 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Wed Dec 3 10:31:24 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:24 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:46:37 GMT, Joe Darcy wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/eae9329d...e5214614 > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 394: > >> 392: * >> 393: * @see > 394: * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html"> > > Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4bf97a8ab5a134ab592f7a84b7e1dc130d04a845; Good catch! > src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368: > >> 1366: } >> 1367: >> 1368: private static String formatAbbreviatedList(Collection values) { > > I think changing the policy here is okay, but it should be better documented in comments here. > > Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented. Extracted and fixed in a separate issue https://github.com/openjdk/jdk/commit/8a28a76451b2bbde49c1c051cb66c784f9e3cdd2 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584514802 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584513205 From nbenalla at openjdk.org Wed Dec 3 10:31:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:27 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Wed, 3 Dec 2025 01:32:00 GMT, Joe Darcy wrote: >> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: >> >> - revert changes to avoid conflict >> - add 27 to the acceptable boot versions > > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 483: > >> 481: */ >> 482: RELEASE_26, >> 483: > > At the top of the file where the per-release changes are all listed, please add a > > "27: tbd" > > entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4b14a7593c9cbc6f67d400e823d47d23e304d564 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584507508 From mgronlun at openjdk.org Wed Dec 3 10:45:43 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Dec 2025 10:45:43 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v14] In-Reply-To: References: Message-ID: <2tMUYu-TFZeFFfpE_054SK4rzCZZgs_UMiNudMx440M=.ce00a309-abf1-4325-9781-65dc0b5c6d59@github.com> > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/c2e36d2f..85bf2d25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=12-13 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From egahlin at openjdk.org Wed Dec 3 10:58:54 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 3 Dec 2025 10:58:54 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v14] In-Reply-To: <2tMUYu-TFZeFFfpE_054SK4rzCZZgs_UMiNudMx440M=.ce00a309-abf1-4325-9781-65dc0b5c6d59@github.com> References: <2tMUYu-TFZeFFfpE_054SK4rzCZZgs_UMiNudMx440M=.ce00a309-abf1-4325-9781-65dc0b5c6d59@github.com> Message-ID: On Wed, 3 Dec 2025 10:45:43 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. >> >> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. >> >> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. >> >> Testing: jdk_jfr, manual AOT verification, stress testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > copyright header Nice work! ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28505#pullrequestreview-3534470248 From coleenp at openjdk.org Wed Dec 3 13:08:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Dec 2025 13:08:38 GMT Subject: RFR: 8371409: Wrong lock ordering between FullGCALot_lock and =?UTF-8?B?VGhyZWFkc0xvY2tU4oCm?= d0522e9 =?UTF-8?B?4oCmaHJvdHRsZV9sb2NrL01ldGhvZENvbXBpbGVRdWV1ZV9sb2Nr?= Message-ID: This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. ------------- Commit messages: - Remove the test. FullGCALot times out. - 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock Changes: https://git.openjdk.org/jdk/pull/28633/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28633&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371409 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28633/head:pull/28633 PR: https://git.openjdk.org/jdk/pull/28633 From stuefe at openjdk.org Wed Dec 3 13:11:08 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Dec 2025 13:11:08 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 20:24:06 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary jdk.internal.misc module declaration test/hotspot/jtreg/runtime/CommandLine/PrintAllFlags.java line 71: > 69: } > 70: } > 71: } Possibly shorter code: could you not just collect the Set twice, once for + and once for - UnlockXXX, and then use something Set.equals to assert equality? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28579#discussion_r2585047002 From coleenp at openjdk.org Wed Dec 3 13:30:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Dec 2025 13:30:44 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v14] In-Reply-To: <2tMUYu-TFZeFFfpE_054SK4rzCZZgs_UMiNudMx440M=.ce00a309-abf1-4325-9781-65dc0b5c6d59@github.com> References: <2tMUYu-TFZeFFfpE_054SK4rzCZZgs_UMiNudMx440M=.ce00a309-abf1-4325-9781-65dc0b5c6d59@github.com> Message-ID: On Wed, 3 Dec 2025 10:45:43 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. >> >> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. >> >> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. >> >> Testing: jdk_jfr, manual AOT verification, stress testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > copyright header Runtime changes look fine. Didn't review the new concurrent hash table. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28505#pullrequestreview-3535046644 From tschatzl at openjdk.org Wed Dec 3 13:39:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Dec 2025 13:39:44 GMT Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle In-Reply-To: <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com> References: <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com> Message-ID: <2MJWsNES8rUusWPja_d4AR4xE1yubXpTw3Uwc2806x8=.9b3f4773-b3ca-4835-90f4-98e908257155@github.com> On Wed, 3 Dec 2025 09:21:52 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @dholmes-ora for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28396#issuecomment-3606890424 From tschatzl at openjdk.org Wed Dec 3 13:39:45 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Dec 2025 13:39:45 GMT Subject: Integrated: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle In-Reply-To: References: Message-ID: <2N_mU29qZCP_BWOjh4K5-AGd1L6961F2nz3mQURayWU=.b49047a9-b64c-4052-a24d-c9926e287e4f@github.com> On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 135661b4 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/135661b4389663b8c2e348d9e61e72cc628636bb Stats: 37 lines in 3 files changed: 0 ins; 34 del; 3 mod 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle Reviewed-by: dholmes, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28396 From mgronlun at openjdk.org Wed Dec 3 13:54:07 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Dec 2025 13:54:07 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v15] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: restore AOT modifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/85bf2d25..601fbc0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=13-14 Stats: 23 lines in 3 files changed: 0 ins; 18 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From mgronlun at openjdk.org Wed Dec 3 14:00:34 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Dec 2025 14:00:34 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v16] In-Reply-To: References: Message-ID: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: restore aotClassLocation.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28505/files - new: https://git.openjdk.org/jdk/pull/28505/files/601fbc0b..0d1461f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505 PR: https://git.openjdk.org/jdk/pull/28505 From rehn at openjdk.org Wed Dec 3 14:10:13 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 3 Dec 2025 14:10:13 GMT Subject: RFR: 8371409: Wrong lock ordering between FullGCALot_lock and =?UTF-8?B?VGhyZWFkc0xvY2tU4oCm?= d0522e9 =?UTF-8?B?4oCmaHJvdHRsZV9sb2NrL01ldGhvZENvbXBpbGVRdWV1ZV9sb2Nr?= In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore wrote: > This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. > Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. This makes sense, thanks @coleenp ! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28633#pullrequestreview-3535241250 From egahlin at openjdk.org Wed Dec 3 14:11:24 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 3 Dec 2025 14:11:24 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v16] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:00:34 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. >> >> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. >> >> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. >> >> Testing: jdk_jfr, manual AOT verification, stress testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > restore aotClassLocation.cpp Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28505#pullrequestreview-3535245425 From fthevenet at openjdk.org Wed Dec 3 14:37:26 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 3 Dec 2025 14:37:26 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v3] In-Reply-To: References: Message-ID: <6T4sXvBst-DiSiD7fFdW_cqVVklTUvzxpOPXt2UA6zM=.f3f8c301-8a21-4208-9ab4-c22a395e1e17@github.com> > This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` > > This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). > > Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Reworked the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28579/files - new: https://git.openjdk.org/jdk/pull/28579/files/6cdac8e1..3d22c0a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=01-02 Stats: 42 lines in 1 file changed: 16 ins; 20 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28579.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28579/head:pull/28579 PR: https://git.openjdk.org/jdk/pull/28579 From fthevenet at openjdk.org Wed Dec 3 14:37:28 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 3 Dec 2025 14:37:28 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 20:24:06 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary jdk.internal.misc module declaration @tstuefe I've reworked the test a bit as you suggested. It's not much shorter but it does a better job at conveying the test's logic at a glance, I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28579#issuecomment-3607155888 From coleenp at openjdk.org Wed Dec 3 14:46:25 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Dec 2025 14:46:25 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v16] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:00:34 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. >> >> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. >> >> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. >> >> Testing: jdk_jfr, manual AOT verification, stress testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > restore aotClassLocation.cpp Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28505#pullrequestreview-3535405541 From fthevenet at openjdk.org Wed Dec 3 14:55:06 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 3 Dec 2025 14:55:06 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v4] In-Reply-To: References: Message-ID: > This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` > > This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). > > Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Reworked the test some more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28579/files - new: https://git.openjdk.org/jdk/pull/28579/files/3d22c0a2..975a7243 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28579&range=02-03 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28579.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28579/head:pull/28579 PR: https://git.openjdk.org/jdk/pull/28579 From stuefe at openjdk.org Wed Dec 3 14:55:07 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Dec 2025 14:55:07 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v4] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:51:26 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Reworked the test some more Thanks! ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28579#pullrequestreview-3535436749 From nbenalla at openjdk.org Wed Dec 3 15:48:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 15:48:23 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - fix jls 27 link - fix typo and add entry for 27 - Merge branch 'master' into start-of-release-27 - revert changes to avoid conflict - add 27 to the acceptable boot versions - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - ... and 14 more: https://git.openjdk.org/jdk/compare/0351ed87...444cc1c8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/4bf97a8a..444cc1c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=10-11 Stats: 819 lines in 34 files changed: 424 ins; 271 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From darcy at openjdk.org Wed Dec 3 16:36:16 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 3 Dec 2025 16:36:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: <14VgrwjksW2UO1LtpHGyX6sTjHbaplRnV7ZgmcyiRIQ=.b06ebf9a-2f95-4e95-89b9-981562ceef06@github.com> On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/659ebef2...444cc1c8 Marked as reviewed by darcy (Reviewer). Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535940924 PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535946905 From liach at openjdk.org Wed Dec 3 16:44:15 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 16:44:15 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/c61f404d...444cc1c8 Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535980615 From iris at openjdk.org Wed Dec 3 16:56:43 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 3 Dec 2025 16:56:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/afcc5cbc...444cc1c8 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3536041848 From duke at openjdk.org Wed Dec 3 17:57:31 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Dec 2025 17:57:31 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v4] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:55:06 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Reworked the test some more @fthevenet Your change (at version 975a72433ffccb91ee73746a147ee329dbaec4aa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28579#issuecomment-3608092881 From mgronlun at openjdk.org Wed Dec 3 18:16:28 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Dec 2025 18:16:28 GMT Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for class loading [v16] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:08:23 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> restore aotClassLocation.cpp > > Marked as reviewed by egahlin (Reviewer). Thanks @egahlin and @coleenp for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28505#issuecomment-3608156678 From mgronlun at openjdk.org Wed Dec 3 18:16:31 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Dec 2025 18:16:31 GMT Subject: Integrated: 8365400: Enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:10:55 GMT, Markus Gr?nlund wrote: > Greetings, > > this enhancement adds a "source" field, label "Source" to the jdk.ClassDefine event. > > To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements. > > Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths. > > Testing: jdk_jfr, manual AOT verification, stress testing > > Thanks > Markus This pull request has now been integrated. Changeset: e93b10d0 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/e93b10d08456f720e303771a882e79660911e1eb Stats: 1372 lines in 33 files changed: 1035 ins; 162 del; 175 mod 8365400: Enhance JFR to emit file and module metadata for class loading Reviewed-by: coleenp, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/28505 From pchilanomate at openjdk.org Wed Dec 3 18:33:32 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 18:33:32 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v4] In-Reply-To: References: Message-ID: > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - use int - Merge branch 'master' into JDK-8360702 - Remove extra space - Remove finally block - David's comments - v1 ------------- Changes: https://git.openjdk.org/jdk/pull/27582/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=03 Stats: 51 lines in 2 files changed: 20 ins; 18 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27582.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27582/head:pull/27582 PR: https://git.openjdk.org/jdk/pull/27582 From pchilanomate at openjdk.org Wed Dec 3 18:33:35 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 18:33:35 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 15:02:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - Remove extra space > - Remove finally block I've made a small update to the test to avoid the issue found in JDK-8371081. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3608247106 From sspitsyn at openjdk.org Wed Dec 3 19:05:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 19:05:55 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVM TI ERROR 13 Message-ID: Please, review a simple correction of the test issue. The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. Testing: This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. ------------- Commit messages: - 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13wq Changes: https://git.openjdk.org/jdk/pull/28643/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28643&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372769 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28643/head:pull/28643 PR: https://git.openjdk.org/jdk/pull/28643 From lmesnik at openjdk.org Wed Dec 3 19:05:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 3 Dec 2025 19:05:55 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVM TI ERROR 13 In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. Thanks for fixing this. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28643#pullrequestreview-3536494601 From pchilanomate at openjdk.org Wed Dec 3 19:31:16 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 19:31:16 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 In-Reply-To: References: Message-ID: <8Z8ntwvqpGN8LPFWbPAJ5CNbGW-VhyTzX57-Sw17goE=.a87f44a8-3279-46e8-8120-9a32c85197ed@github.com> On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > - This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. > - In progress: mach5 tiers 1-4 (to be safe) Looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28643#pullrequestreview-3536598832 From enikitin at openjdk.org Wed Dec 3 19:31:24 2025 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Wed, 3 Dec 2025 19:31:24 GMT Subject: RFR: 8373049: Update JCStress test suite Message-ID: The new, updated version of Jcstress. Testing: the whole suite run, no new issues found. ------------- Commit messages: - 8373049: Update JCStress test suite Changes: https://git.openjdk.org/jdk/pull/28644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28644&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373049 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28644/head:pull/28644 PR: https://git.openjdk.org/jdk/pull/28644 From epavlova at openjdk.org Wed Dec 3 19:34:14 2025 From: epavlova at openjdk.org (Ekaterina Pavlova) Date: Wed, 3 Dec 2025 19:34:14 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: <7Rz8ncGU8ZKzrY444YUjDVnb15jaYCnL7FcZvobadiU=.77200811-137d-4bd6-8a89-573f9e6461e7@github.com> On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. Look good, Did testing pass? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28644#issuecomment-3608502967 From cjplummer at openjdk.org Wed Dec 3 19:38:04 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 3 Dec 2025 19:38:04 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > - This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. > - In progress: mach5 tiers 1-4 (to be safe) Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28643#pullrequestreview-3536617433 From amenkov at openjdk.org Wed Dec 3 19:38:05 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 3 Dec 2025 19:38:05 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 In-Reply-To: References: Message-ID: <97mGHzNKBUKXjAkZ0FjaHpBbezKzx9nYhL2_RvpsHok=.bb3fbed0-9112-48d3-a01c-9f915fc21758@github.com> On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > - This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. > - In progress: mach5 tiers 1-4 (to be safe) Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28643#pullrequestreview-3536619369 From sspitsyn at openjdk.org Wed Dec 3 19:43:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 19:43:54 GMT Subject: RFR: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > - This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. > - In progress: mach5 tiers 1-4 (to be safe) Thank you for reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28643#issuecomment-3608534405 From enikitin at openjdk.org Wed Dec 3 20:15:16 2025 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Wed, 3 Dec 2025 20:15:16 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: <7Rz8ncGU8ZKzrY444YUjDVnb15jaYCnL7FcZvobadiU=.77200811-137d-4bd6-8a89-573f9e6461e7@github.com> References: <7Rz8ncGU8ZKzrY444YUjDVnb15jaYCnL7FcZvobadiU=.77200811-137d-4bd6-8a89-573f9e6461e7@github.com> Message-ID: On Wed, 3 Dec 2025 19:31:17 GMT, Ekaterina Pavlova wrote: > Look good, Did testing pass? Yep. One test failed (the coherence.java), but it fails with the current version as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28644#issuecomment-3608651023 From epavlova at openjdk.org Wed Dec 3 20:19:20 2025 From: epavlova at openjdk.org (Ekaterina Pavlova) Date: Wed, 3 Dec 2025 20:19:20 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. Marked as reviewed by epavlova (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28644#pullrequestreview-3536758080 From coleenp at openjdk.org Wed Dec 3 20:26:07 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Dec 2025 20:26:07 GMT Subject: RFR: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock In-Reply-To: References: Message-ID: <1bCVVX5o7gub6mn7Psc9ElURUSGLz4tWT3W_abygRmY=.513c8538-4bc1-4b1c-81a5-744c6aefb853@github.com> On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore wrote: > This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. > Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. Thanks Robbin and thank you for reporting it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28633#issuecomment-3608694460 From dholmes at openjdk.org Wed Dec 3 21:35:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Dec 2025 21:35:02 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:30:57 GMT, Patricio Chilano Mateo wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove extra space >> - Remove finally block > > I've made a small update to the test to avoid the issue found in JDK-8371081. @pchilano I don't think you meant to commit the ProblemList-Virtual.txt update ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3608923866 From lmesnik at openjdk.org Wed Dec 3 21:49:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 3 Dec 2025 21:49:57 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28644#pullrequestreview-3537055064 From duke at openjdk.org Wed Dec 3 21:49:58 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Dec 2025 21:49:58 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. @lepestock Your change (at version 3783cfa4484e0e33559fb0be6122016bcf96b3ec) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28644#issuecomment-3608979413 From lmesnik at openjdk.org Wed Dec 3 22:00:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 3 Dec 2025 22:00:55 GMT Subject: RFR: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. Sorry, haven't mention explicitly, that the fix is trivial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28644#issuecomment-3609013248 From enikitin at openjdk.org Wed Dec 3 22:00:56 2025 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Wed, 3 Dec 2025 22:00:56 GMT Subject: Integrated: 8373049: Update JCStress test suite In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:24:12 GMT, Evgeny Nikitin wrote: > The new, updated version of Jcstress. > > Testing: the whole suite run, no new issues found. This pull request has now been integrated. Changeset: 9b386014 Author: Evgeny Nikitin Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/9b386014a01b2bff47856bf9a8e113317db1f081 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8373049: Update JCStress test suite Reviewed-by: epavlova, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28644 From pchilanomate at openjdk.org Wed Dec 3 22:45:03 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 22:45:03 GMT Subject: RFR: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore wrote: > This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. > Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. LGTM! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28633#pullrequestreview-3537224047 From sspitsyn at openjdk.org Wed Dec 3 22:46:16 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Dec 2025 22:46:16 GMT Subject: Integrated: 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:56:46 GMT, Serguei Spitsyn wrote: > Please, review a simple correction of the test issue. > The test method `suspendThread()` does not throw an exception if JVMTI `SuspendThread` returns `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. So these two error codes are accepted as valid. JVMTI `SuspendThread` does not suspend the target thread in such a case, so JVMTI `ResumeThread` can return the JVMTI_ERROR_THREAD_NOT_SUSPENDED (13). > > The fix is to skip call to JVMTI `ResumeThread` if JVMTI `SuspendThread` returned `JVMTI_ERROR_THREAD_NOT_ALIVE` or `JVMTI_ERROR_WRONG_PHASE`. > > Testing: > - This problem is hard to reproduce, but I was able to reproduce it with a JVMTI hack. The fixed test does not fail anymore. > - In progress: mach5 tiers 1-4 (to be safe) This pull request has now been integrated. Changeset: 1294d55b Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/1294d55b194704dce92c5132d6779e6f4d4850e6 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8372769: Test runtime/handshake/HandshakeDirectTest.java failed - JVMTI ERROR 13 Reviewed-by: lmesnik, pchilanomate, cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/28643 From pchilanomate at openjdk.org Wed Dec 3 23:14:35 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 23:14:35 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v5] In-Reply-To: References: Message-ID: <4Sq_pT8rOD2Ru-UJRtnd9zQPYnb7vhNm66dX7XMo3tM=.f0c35346-a8cf-4b57-8f3d-18a4db3a73c0@github.com> > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: remove test.thread.factory requirement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27582/files - new: https://git.openjdk.org/jdk/pull/27582/files/c4e5a9ac..c174861e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27582.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27582/head:pull/27582 PR: https://git.openjdk.org/jdk/pull/27582 From pchilanomate at openjdk.org Wed Dec 3 23:14:37 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Dec 2025 23:14:37 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:30:57 GMT, Patricio Chilano Mateo wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove extra space >> - Remove finally block > > I've made a small update to the test to avoid the issue found in JDK-8371081. > @pchilano I don't think you meant to commit the ProblemList-Virtual.txt update > You mean the `@require` added in 8348844, right? Yes, removed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3609219936 From sspitsyn at openjdk.org Thu Dec 4 00:34:06 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 4 Dec 2025 00:34:06 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: On Wed, 3 Dec 2025 07:22:51 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 possibility 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 t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > addressed review comments We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module. We got the following concerns: - Do we really need 3x implementations of the MacOS `tempdir` finder function? - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3609399390 From duke at openjdk.org Thu Dec 4 01:18:00 2025 From: duke at openjdk.org (jonghoonpark) Date: Thu, 4 Dec 2025 01:18:00 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Mon, 6 Oct 2025 09:38:24 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8367717 >> >> ## Changes >> - deleted all definitions of atomic_copy64 >> - replaced all calls to `atomic_copy64` with `AtomicAccess::store(dst, AtomicAccess::load(src))` >> >> ## Verification >> - Verified by running: >> - `make run-test TEST="gtest:StubRoutines*"` >> - `make run-test TEST="gtest:AtomicAccess*"` >> >> Please let me know if there are any additional or more appropriate verification steps I should perform. > > jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: > > cleanup: align to use AtomicAccess > > Signed-off-by: jonghoonpark The discussion seems unresolved, so I?ll convert this PR back to draft for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3609496095 From dholmes at openjdk.org Thu Dec 4 01:55:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Dec 2025 01:55:56 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v5] In-Reply-To: <4Sq_pT8rOD2Ru-UJRtnd9zQPYnb7vhNm66dX7XMo3tM=.f0c35346-a8cf-4b57-8f3d-18a4db3a73c0@github.com> References: <4Sq_pT8rOD2Ru-UJRtnd9zQPYnb7vhNm66dX7XMo3tM=.f0c35346-a8cf-4b57-8f3d-18a4db3a73c0@github.com> Message-ID: On Wed, 3 Dec 2025 23:14:35 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > remove test.thread.factory requirement Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27582#pullrequestreview-3537568876 From dholmes at openjdk.org Thu Dec 4 01:55:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Dec 2025 01:55:57 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 23:10:36 GMT, Patricio Chilano Mateo wrote: > > @pchilano I don't think you meant to commit the ProblemList-Virtual.txt update > > You mean the `@require` added in 8348844, right? Yes, removed now. No, when I looked at "commits since you last reviewed" git showed me changes to the ProblemList-Virtual.txt file that seemed unrelated to this change. But now looking at the individual commits I can't see it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3609619999 From dholmes at openjdk.org Thu Dec 4 08:26:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Dec 2025 08:26:17 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v4] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:55:06 GMT, Frederic Thevenet wrote: >> This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` >> >> This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). >> >> Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Reworked the test some more Update looks fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28579#pullrequestreview-3538681002 From fthevenet at openjdk.org Thu Dec 4 08:26:19 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 4 Dec 2025 08:26:19 GMT Subject: Integrated: 8372802: PrintFlagsFinal should also print locked flags In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:56:54 GMT, Frederic Thevenet wrote: > This change aims to provide a way to print all flags including "locked" ones (e.g. Diagnostic and Experimental) without having to explicitly set `+UnlockExperimentalVMOptions` or `+UnlockDiagnosticVMOptions` > > This applies to the following VM options: `PrintFlagsFinal` , `PrintFlagsRanges`, `PrintFlagsInitial`, `PrintFlagsWithComments`, `-XprintFlags`, as well as the `PrintVMFlagsDCmd` diagnostic command (when set to show all flags). > > Places that print out only flags that have been changed (i.e. that skip flags with default values), like when during the generation of hs_err reports, are not affected by this. This pull request has now been integrated. Changeset: 771253e2 Author: Frederic Thevenet Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/771253e285c48329a9b45dfaaa852b64e74b31d4 Stats: 70 lines in 2 files changed: 69 ins; 0 del; 1 mod 8372802: PrintFlagsFinal should also print locked flags Reviewed-by: dholmes, stuefe, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28579 From fthevenet at openjdk.org Thu Dec 4 09:20:21 2025 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 4 Dec 2025 09:20:21 GMT Subject: RFR: 8372802: PrintFlagsFinal should also print locked flags [v4] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 08:21:45 GMT, David Holmes wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Reworked the test some more > > Update looks fine. Thanks, @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/28579#issuecomment-3611039355 From mgronlun at openjdk.org Thu Dec 4 10:45:25 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Dec 2025 10:45:25 GMT Subject: RFR: 8373062: JFR build failure with CDS disabled [v3] In-Reply-To: References: Message-ID: > Greetings, > > [JDK-8365400](https://bugs.openjdk.org/browse/JDK-8365400) caused a build problem when passing build option "--disable-cds" because of missing conditionals. > > Testing: manually building with "--disable-cds" > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: apa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28656/files - new: https://git.openjdk.org/jdk/pull/28656/files/369297f5..0e8612c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28656&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28656&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28656/head:pull/28656 PR: https://git.openjdk.org/jdk/pull/28656 From egahlin at openjdk.org Thu Dec 4 10:45:26 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Dec 2025 10:45:26 GMT Subject: RFR: 8373062: JFR build failure with CDS disabled [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 10:42:56 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> [JDK-8365400](https://bugs.openjdk.org/browse/JDK-8365400) caused a build problem when passing build option "--disable-cds" because of missing conditionals. >> >> Testing: manually building with "--disable-cds" >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > apa Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28656#pullrequestreview-3539289435 From mgronlun at openjdk.org Thu Dec 4 12:27:53 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Dec 2025 12:27:53 GMT Subject: RFR: 8373062: JFR build failure with CDS disabled [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 10:42:01 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> apa > > Marked as reviewed by egahlin (Reviewer). Thanks @egahlin for the review. I am going to to proceed with integration to ensure no build issues remain for RDP1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28656#issuecomment-3611987285 From mgronlun at openjdk.org Thu Dec 4 12:27:55 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Dec 2025 12:27:55 GMT Subject: Integrated: 8373062: JFR build failure with CDS disabled In-Reply-To: References: Message-ID: <50F7UB-iOcEhzjtgSeuYCHLBtS0EMmTNqZs_2wTM9Hs=.5a87c2be-06d6-4719-9285-1d6487016dee@github.com> On Thu, 4 Dec 2025 10:09:50 GMT, Markus Gr?nlund wrote: > Greetings, > > [JDK-8365400](https://bugs.openjdk.org/browse/JDK-8365400) caused a build problem when passing build option "--disable-cds" because of missing conditionals. > > Testing: manually building with "--disable-cds" > > Thanks > Markus This pull request has now been integrated. Changeset: bcbdf90f Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/bcbdf90fce44ad87e7728ba0febef0951e361589 Stats: 29 lines in 5 files changed: 16 ins; 11 del; 2 mod 8373062: JFR build failure with CDS disabled Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/28656 From pchilanomate at openjdk.org Thu Dec 4 14:34:34 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 4 Dec 2025 14:34:34 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v5] In-Reply-To: <4Sq_pT8rOD2Ru-UJRtnd9zQPYnb7vhNm66dX7XMo3tM=.f0c35346-a8cf-4b57-8f3d-18a4db3a73c0@github.com> References: <4Sq_pT8rOD2Ru-UJRtnd9zQPYnb7vhNm66dX7XMo3tM=.f0c35346-a8cf-4b57-8f3d-18a4db3a73c0@github.com> Message-ID: <2sZWc3wK09oJWJiGESb-QPKimxJCcb0oJFpoUcBxqS4=.c00d27ff-b85e-4de6-9770-38dfaf4d0281@github.com> On Wed, 3 Dec 2025 23:14:35 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > remove test.thread.factory requirement Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3612542226 From pchilanomate at openjdk.org Thu Dec 4 15:05:13 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 4 Dec 2025 15:05:13 GMT Subject: Integrated: 8360702: runtime/Thread/AsyncExceptionTest.java timed out In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 16:20:11 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 6f03c780 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/6f03c7808de2b07b1e501d05b1bb7d5bfde5e393 Stats: 52 lines in 2 files changed: 20 ins; 19 del; 13 mod 8360702: runtime/Thread/AsyncExceptionTest.java timed out Reviewed-by: dholmes, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/27582 From nbenalla at openjdk.org Thu Dec 4 17:06:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Dec 2025 17:06:54 GMT Subject: Integrated: 8370890: Start of release updates for JDK 27 In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla wrote: > Get JDK 27 underway. This pull request has now been integrated. Changeset: c55287d1 Author: Nizar Benalla Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c55287d197ef024033f8dfbb5a365cb091bc67fb Stats: 1233 lines in 50 files changed: 1157 ins; 0 del; 76 mod 8370890: Start of release updates for JDK 27 8370893: Add SourceVersion.RELEASE_27 8370894: Add source 27 and target 27 to javac Reviewed-by: darcy, iris, liach, erikj, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28130 From coleenp at openjdk.org Thu Dec 4 22:37:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Dec 2025 22:37:02 GMT Subject: RFR: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore wrote: > This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. > Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. Thanks Robbin and Patricio. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28633#issuecomment-3614591220 From coleenp at openjdk.org Thu Dec 4 22:37:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Dec 2025 22:37:02 GMT Subject: Integrated: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore wrote: > This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that. This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff. > Tested with tier1-4. I wrote a test case where I verified this change but the test case times out, so noreg-hard. This pull request has now been integrated. Changeset: 6db1c4f5 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/6db1c4f5b93a1b7f7d9da36745dc433c9985a169 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock Reviewed-by: rehn, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/28633 From schernyshev at openjdk.org Fri Dec 5 10:27:43 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 5 Dec 2025 10:27:43 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v9] In-Reply-To: References: 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. Previously, JDK-8197387 introduced the same possibility 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... Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: - Reapply "8319589: Attach from root to a user java process not supported in Mac" consolidated as a single patch, with reviewers suggestions. - Revert "8319589: Attach from root to a user java process not supported in Mac" This reverts commit 9fd3781d73286fadf971ab0b6fcc231fba008c94. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25824/files - new: https://git.openjdk.org/jdk/pull/25824/files/fd1645b0..1dd07e6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=07-08 Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 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 Fri Dec 5 10:27:45 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 5 Dec 2025 10:27:45 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: On Thu, 4 Dec 2025 00:31:37 GMT, Serguei Spitsyn wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comments > > We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module. > We got the following concerns: > - Do we really need 3x implementations of the MacOS `tempdir` finder function? > - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`? > New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. > My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS? > Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this. Hi @sspitsyn , Thank you for looking at this patch! > This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions? The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root. > * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory. > * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux). > * Is it right that the `jvmstat` implementation still does not properly support root user on macOS? Yes and this is what this patch was intended for. > * Do we really need 3x implementations of the MacOS `tempdir` finder function? It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to. > * Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`? It was already a dependency of `jdk.attach` to `sun.jvmstat.monitor`. This change exports also `sun.jvmstat`, in addition to `sun.jvmstat.monitor` as it was before. > src/hotspot/os/bsd/os_bsd.cpp line 956: > >> 954: } >> 955: #endif >> 956: > > Nit: I'd suggest to get rid of empty lines which do not improve readability: > 890, 903, 908, 917, 923, 930, 933, 941, 944 > Also, the comment at line 931 is better to start with a capital letter: `// If the ..` . Thanks @sspitsyn , done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3616052858 PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2592160722 From dholmes at openjdk.org Mon Dec 8 06:34:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Dec 2025 06:34:03 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 13:44:09 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. Sorry it has taken so long to look at this one. I was surprised to see the limited cases covered in the PR, but looking at the code now I see that the motivating example in JBS: if (::FindClose(f) == 0) { errno = ::GetLastError(); log_debug(os)("is_symbolic_link() failed to FindClose: GetLastError->%ld.", errno); } is no longer applicable after we untangled Windows use of `GetLastError` from use of `errno`. And it was not as prevalent as initially thought. I think we can dispense with `ErrorPreserver` in most cases. Thanks src/hotspot/os/aix/os_aix.cpp line 2334: > 2332: ErrnoPreserver ep; > 2333: ::close(fd); > 2334: errno = ep.saved_errno(); I suspect the intent is that we set EISDIR assuming the close succeeds, but if the close fails then errno reflects that error. Otherwise the trivial change here would be to reorder the two statements. src/hotspot/os/windows/os_windows.cpp line 4785: > 4783: ErrnoPreserver ep; > 4784: os::free(wide_path); > 4785: errno = ep.saved_errno(); Just swap the statements src/hotspot/os/windows/os_windows.cpp line 4805: > 4803: os::free(wide_path); > 4804: os::free(path_to_target); > 4805: errno = ep.saved_errno(); I would just move the free calls higher, then set errno after that. src/hotspot/os/windows/os_windows.cpp line 5007: > 5005: ErrnoPreserver ep; > 5006: os::free(wide_path); > 5007: errno = ep.saved_errno(); Again in this simple case we can just switch the order and set errno after the free. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28086#pullrequestreview-3550254075 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597146168 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597181639 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597178368 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597157272 From aartemov at openjdk.org Mon Dec 8 08:38:47 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 08:38:47 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v2] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. 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 two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly - 8366272: Improved errno management in os:xxx methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28086/files - new: https://git.openjdk.org/jdk/pull/28086/files/f3ab0677..e40afdb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=00-01 Stats: 275195 lines in 2669 files changed: 185212 ins; 49712 del; 40271 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From aartemov at openjdk.org Mon Dec 8 09:23:44 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 09:23:44 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v3] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366272: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28086/files - new: https://git.openjdk.org/jdk/pull/28086/files/e40afdb2..5f7ad209 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=01-02 Stats: 18 lines in 2 files changed: 3 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From aartemov at openjdk.org Mon Dec 8 09:23:47 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 09:23:47 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v3] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 05:58:56 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366272: Addressed reviewer's comments. > > src/hotspot/os/aix/os_aix.cpp line 2334: > >> 2332: ErrnoPreserver ep; >> 2333: ::close(fd); >> 2334: errno = ep.saved_errno(); > > I suspect the intent is that we set EISDIR assuming the close succeeds, but if the close fails then errno reflects that error. Otherwise the trivial change here would be to reorder the two statements. Right, a bit over-engineered. Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4785: > >> 4783: ErrnoPreserver ep; >> 4784: os::free(wide_path); >> 4785: errno = ep.saved_errno(); > > Just swap the statements Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4805: > >> 4803: os::free(wide_path); >> 4804: os::free(path_to_target); >> 4805: errno = ep.saved_errno(); > > I would just move the free calls higher, then set errno after that. Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 5007: > >> 5005: ErrnoPreserver ep; >> 5006: os::free(wide_path); >> 5007: errno = ep.saved_errno(); > > Again in this simple case we can just switch the order and set errno after the free. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597743098 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597743986 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597743604 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597743312 From kbarrett at openjdk.org Mon Dec 8 10:06:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 8 Dec 2025 10:06:05 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v3] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 09:23:44 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366272: Addressed reviewer's comments. Changes requested by kbarrett (Reviewer). src/hotspot/os/bsd/os_bsd.cpp line 2281: > 2279: ErrnoPreserver ep; > 2280: ::close(fd); > 2281: errno = ep.saved_errno(); Just reorder close and errno assignment here too? src/hotspot/os/linux/os_linux.cpp line 4936: > 4934: ErrnoPreserver ep; > 4935: ::close(fd); > 4936: errno = ep.saved_errno(); Just reorder close and errno assignment here too? src/hotspot/os/posix/os_posix.cpp line 1033: > 1031: ErrnoPreserver ep; > 1032: permit_forbidden_function::free(p); // *not* os::free > 1033: errno = ep.saved_errno(); `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. src/hotspot/os/posix/signals_posix.cpp line 1730: > 1728: } > 1729: > 1730: errno = ep.saved_errno(); `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. src/hotspot/os/windows/os_windows.cpp line 5278: > 5276: ErrnoPreserver ep; > 5277: permit_forbidden_function::free(p); // *not* os::free > 5278: errno = ep.saved_errno(); `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. ------------- PR Review: https://git.openjdk.org/jdk/pull/28086#pullrequestreview-3551117584 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597868282 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597868998 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597873055 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597866119 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2597895784 From aartemov at openjdk.org Mon Dec 8 11:17:44 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 11:17:44 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v4] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366272: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28086/files - new: https://git.openjdk.org/jdk/pull/28086/files/5f7ad209..d721128f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=02-03 Stats: 10 lines in 5 files changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From aartemov at openjdk.org Mon Dec 8 11:17:52 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 11:17:52 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v3] In-Reply-To: References: Message-ID: <5RxP8HCXN0B9bZ8ZqCKbTL1v4klhFaMq_JN_dkjKgqI=.3c3630b0-43d9-4d60-a0dd-49b74f1a07db@github.com> On Mon, 8 Dec 2025 09:49:33 GMT, Kim Barrett wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366272: Addressed reviewer's comments. > > src/hotspot/os/bsd/os_bsd.cpp line 2281: > >> 2279: ErrnoPreserver ep; >> 2280: ::close(fd); >> 2281: errno = ep.saved_errno(); > > Just reorder close and errno assignment here too? Yep, same as in `os_aix.cpp`. Addressed. > src/hotspot/os/linux/os_linux.cpp line 4936: > >> 4934: ErrnoPreserver ep; >> 4935: ::close(fd); >> 4936: errno = ep.saved_errno(); > > Just reorder close and errno assignment here too? Addressed. > src/hotspot/os/posix/os_posix.cpp line 1033: > >> 1031: ErrnoPreserver ep; >> 1032: permit_forbidden_function::free(p); // *not* os::free >> 1033: errno = ep.saved_errno(); > > `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. Addressed. > src/hotspot/os/posix/signals_posix.cpp line 1730: > >> 1728: } >> 1729: >> 1730: errno = ep.saved_errno(); > > `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. Right, I missed that, explicitness is redundant here. Addressed. > src/hotspot/os/windows/os_windows.cpp line 5278: > >> 5276: ErrnoPreserver ep; >> 5277: permit_forbidden_function::free(p); // *not* os::free >> 5278: errno = ep.saved_errno(); > > `~ErrnoPreserver()` restores the saved errno, so don't need this assignment. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2598196844 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2598199817 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2598199592 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2598196565 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2598199331 From aartemov at openjdk.org Mon Dec 8 12:58:15 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 12:58:15 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v5] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366272: Fixed whitespaces. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28086/files - new: https://git.openjdk.org/jdk/pull/28086/files/d721128f..bc0c45f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From aartemov at openjdk.org Mon Dec 8 16:17:41 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 8 Dec 2025 16:17:41 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v6] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. 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 six additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly - 8366272: Fixed whitespaces. - 8366272: Addressed reviewer's comments. - 8366272: Addressed reviewer's comments. - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly - 8366272: Improved errno management in os:xxx methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28086/files - new: https://git.openjdk.org/jdk/pull/28086/files/bc0c45f7..6097b291 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=04-05 Stats: 21464 lines in 497 files changed: 12414 ins; 6894 del; 2156 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From jvernee at openjdk.org Mon Dec 8 20:21:59 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Dec 2025 20:21:59 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles I had a look at the document you wrote, but I think it still needs some work. I suggest maybe splitting that out into a separate PR. src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12: > 10: > 11: Constant folding means a read of a variable of a constant value can be replaced > 12: by the read constant value, during the construction of an IR graph. The I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran. We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated. Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field. I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples. ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3553830433 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2599952662 From liach at openjdk.org Mon Dec 8 20:51:00 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 20:51:00 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 20:00:20 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> bracket styles > > src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12: > >> 10: >> 11: Constant folding means a read of a variable of a constant value can be replaced >> 12: by the read constant value, during the construction of an IR graph. The > > I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran. > > We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated. > > Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field. > > I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples. Sure, I have created https://bugs.openjdk.org/browse/JDK-8373286 to track that effort instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2600090805 From liach at openjdk.org Mon Dec 8 21:14:24 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 21:14:24 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v5] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang 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: - Jorn review - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - bracket styles - Doc tweaks - Essay - Spurious change - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - Issue number and test update - Fixed optional and unit test - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - ... and 1 more: https://git.openjdk.org/jdk/compare/383203c0...b20b7f5b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/d353bdbe..b20b7f5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=03-04 Stats: 38514 lines in 729 files changed: 24382 ins; 11087 del; 3045 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From schernyshev at openjdk.org Mon Dec 8 21:34:37 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 8 Dec 2025 21:34:37 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v10] In-Reply-To: References: 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. Previously, JDK-8197387 introduced the same possibility 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... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: updated copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25824/files - new: https://git.openjdk.org/jdk/pull/25824/files/1dd07e6f..c318ac87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 kbarrett at openjdk.org Tue Dec 9 00:07:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Dec 2025 00:07:11 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable Message-ID: Please review this change to Atomic to meet the requirements for constant initialization in cases where the value type provides the requisite support. This ensures that in such cases dynamic initialization won't even be considered a possibility when initialized with constant arguments. Testing: mach5 tier1 ------------- Commit messages: - constexpr Atomc ctors Changes: https://git.openjdk.org/jdk/pull/28711/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28711&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373208 Stats: 27 lines in 1 file changed: 13 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28711.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28711/head:pull/28711 PR: https://git.openjdk.org/jdk/pull/28711 From dholmes at openjdk.org Tue Dec 9 01:35:07 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 01:35:07 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java Message-ID: To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent thread test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. Testing: - tiers 1-4 (sanity) Thanks ------------- Commit messages: - 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java Changes: https://git.openjdk.org/jdk/pull/28713/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373293 Stats: 40 lines in 1 file changed: 19 ins; 3 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28713/head:pull/28713 PR: https://git.openjdk.org/jdk/pull/28713 From jpai at openjdk.org Tue Dec 9 02:06:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Dec 2025 02:06:56 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java In-Reply-To: References: Message-ID: <0nYTUaxWmYzGkM4Vs7aIuMZy4ZhqjX84_8jmpMhrRqM=.e9876c51-474e-4803-a24b-afd055b0e7c4@github.com> On Tue, 9 Dec 2025 01:28:39 GMT, David Holmes wrote: > To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent thread test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. > > Testing: > - tiers 1-4 (sanity) > > Thanks I don't have prior knowledge of this test, but this refactoring/cleanup in context of this test failure looks good to me. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 68: > 66: } > 67: } catch (InterruptedException e) { > 68: throw new Error("Unexpected interrupt"); Hello David, while at it, it might be good to even include the `e` as the `cause` of this `Error`. That way we get to see which `join()` line in that try block resulted in the `InterruptedException`. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28713#pullrequestreview-3554931609 PR Review Comment: https://git.openjdk.org/jdk/pull/28713#discussion_r2600785891 From dholmes at openjdk.org Tue Dec 9 04:10:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 04:10:30 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v2] In-Reply-To: References: Message-ID: <4fmcq-tr0H1Ndvigs8sg-9VRabCSCXhtfIRDfUTf9GI=.652482eb-38a3-45f4-9ae0-fd53e2776348@github.com> > To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent thread test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. > > Testing: > - tiers 1-4 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Reviewer suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28713/files - new: https://git.openjdk.org/jdk/pull/28713/files/3bfc2544..5c8f20e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28713&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28713&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28713/head:pull/28713 PR: https://git.openjdk.org/jdk/pull/28713 From dholmes at openjdk.org Tue Dec 9 04:10:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 04:10:30 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v2] In-Reply-To: <0nYTUaxWmYzGkM4Vs7aIuMZy4ZhqjX84_8jmpMhrRqM=.e9876c51-474e-4803-a24b-afd055b0e7c4@github.com> References: <0nYTUaxWmYzGkM4Vs7aIuMZy4ZhqjX84_8jmpMhrRqM=.e9876c51-474e-4803-a24b-afd055b0e7c4@github.com> Message-ID: On Tue, 9 Dec 2025 02:03:55 GMT, Jaikiran Pai wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer suggestion > > I don't have prior knowledge of this test, but this refactoring/cleanup in context of this test failure looks good to me. Thanks for the review @jaikiran ! > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 68: > >> 66: } >> 67: } catch (InterruptedException e) { >> 68: throw new Error("Unexpected interrupt"); > > Hello David, while at it, it might be good to even include the `e` as the `cause` of this `Error`. That way we get to see which `join()` line in that try block resulted in the `InterruptedException`. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/28713#issuecomment-3630166865 PR Review Comment: https://git.openjdk.org/jdk/pull/28713#discussion_r2601009479 From dholmes at openjdk.org Tue Dec 9 04:22:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 04:22:01 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v6] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 16:17:41 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. >> >> Tested in tiers 1 - 5. > > 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly > - 8366272: Fixed whitespaces. > - 8366272: Addressed reviewer's comments. > - 8366272: Addressed reviewer's comments. > - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly > - 8366272: Improved errno management in os:xxx methods Looks good. Thanks src/hotspot/os/posix/signals_posix.cpp line 1648: > 1646: // Save and restore errno to avoid confusing native code with EINTR > 1647: // after sigsuspend. > 1648: ErrnoPreserver ep; I don't think this is incorrect but I will just note that by using the `ErrnoPreserver` we now restore `errno` on all the return paths below, not just for the "success" case. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28086#pullrequestreview-3555349386 PR Review Comment: https://git.openjdk.org/jdk/pull/28086#discussion_r2601028047 From iklam at openjdk.org Tue Dec 9 04:28:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 04:28:23 GMT Subject: RFR: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM Message-ID: Please review this small fix for some CDS tests that fail on machines with a lot of RAM. The reason is the max heap size setting is used only when the CDS archive is dumped. As a result, when we try to use the CDS archive, the VM ergonomics may use a different oop encoding, and the CDS archive becomes unuseable. The fix is to use the same -Xmx when both dumping and using the CDS archive. ------------- Commit messages: - 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM Changes: https://git.openjdk.org/jdk/pull/28715/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28715&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368701 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28715.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28715/head:pull/28715 PR: https://git.openjdk.org/jdk/pull/28715 From iklam at openjdk.org Tue Dec 9 04:42:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 04:42:30 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting Message-ID: Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` Note: this is the same log channel used just a few lines above. https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 ------------- Commit messages: - 8373295: Wrong log tag for UseCompressedOops ergo setting Changes: https://git.openjdk.org/jdk/pull/28716/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28716&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373295 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28716/head:pull/28716 PR: https://git.openjdk.org/jdk/pull/28716 From dholmes at openjdk.org Tue Dec 9 04:52:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 04:52:57 GMT Subject: RFR: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:21:50 GMT, Ioi Lam wrote: > Please review this small fix for some CDS tests that fail on machines with a lot of RAM. > > The reason is the max heap size setting is used only when the CDS archive is dumped. As a result, when we try to use the CDS archive, the VM ergonomics may use a different oop encoding, and the CDS archive becomes unuseable. > > The fix is to use the same -Xmx when both dumping and using the CDS archive. That seems fine, assuming 256M is big enough. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28715#pullrequestreview-3555441696 From iklam at openjdk.org Tue Dec 9 05:01:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 05:01:06 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v2] In-Reply-To: <4fmcq-tr0H1Ndvigs8sg-9VRabCSCXhtfIRDfUTf9GI=.652482eb-38a3-45f4-9ae0-fd53e2776348@github.com> References: <4fmcq-tr0H1Ndvigs8sg-9VRabCSCXhtfIRDfUTf9GI=.652482eb-38a3-45f4-9ae0-fd53e2776348@github.com> Message-ID: On Tue, 9 Dec 2025 04:10:30 GMT, David Holmes wrote: >> To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent thread test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. >> >> Testing: >> - tiers 1-4 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer suggestion Changes requested by iklam (Reviewer). test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 66: > 64: if (threadException != null) { > 65: throw new Error("TestThread encountered unexpected exception", threadException); > 66: } Comments in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) mentione the possibility of OOM. When that happens, the above code may get a secondary OOM while doing the `new Error`, thus obscuring the original `threadException`. I think it's better to make change `main()` to `throws Throwable` and change the above line to if (threadException != null) { Throwable t = threadException; try { t = new Error("TestThread encountered unexpected exception", threadException); } catch (OutOfMemoryError oom) { // t may be an OOM. If we get a secondary OOM then just throw the original exception } throw t; } ------------- PR Review: https://git.openjdk.org/jdk/pull/28713#pullrequestreview-3555459829 PR Review Comment: https://git.openjdk.org/jdk/pull/28713#discussion_r2601096893 From dholmes at openjdk.org Tue Dec 9 05:06:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 05:06:56 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v2] In-Reply-To: References: <4fmcq-tr0H1Ndvigs8sg-9VRabCSCXhtfIRDfUTf9GI=.652482eb-38a3-45f4-9ae0-fd53e2776348@github.com> Message-ID: On Tue, 9 Dec 2025 04:58:31 GMT, Ioi Lam wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer suggestion > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 66: > >> 64: if (threadException != null) { >> 65: throw new Error("TestThread encountered unexpected exception", threadException); >> 66: } > > Comments in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) mentione the possibility of OOM. When that happens, the above code may get a secondary OOM while doing the `new Error`, thus obscuring the original `threadException`. > > I think it's better to make change `main()` to `throws Throwable` and change the above line to > > > if (threadException != null) { > Throwable t = threadException; > try { > t = new Error("TestThread encountered unexpected exception", threadException); > } catch (OutOfMemoryError oom) { > // t may be an OOM. If we get a secondary OOM then just throw the original exception > } > throw t; > } Thanks for looking at this @iklam . Good point. Though termination of the thread should free some memory there is certainly no guarantee, so lets try to make this even more exception-proof. Rethrowing another thread's exception can give a confusing stacktrace however. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28713#discussion_r2601107870 From dholmes at openjdk.org Tue Dec 9 05:11:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 05:11:38 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v3] In-Reply-To: References: Message-ID: > To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent thread test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. > > Testing: > - tiers 1-4 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Use Ioi's suggestion to fix OOME handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28713/files - new: https://git.openjdk.org/jdk/pull/28713/files/5c8f20e3..a4dcb2fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28713&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28713&range=01-02 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28713/head:pull/28713 PR: https://git.openjdk.org/jdk/pull/28713 From ysuenaga at openjdk.org Tue Dec 9 05:13:55 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Dec 2025 05:13:55 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:35:19 GMT, Ioi Lam wrote: > Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` > > > Note: this is the same log channel used just a few lines above. > > https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 I completely agree with your change! But I received review that it should not be changed from CDS tag (I know it is `aot` now). See review thread in my past proposal for details: https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2019-October/036315.html I'm happy to approve if we can accept. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28716#issuecomment-3630347951 From iklam at openjdk.org Tue Dec 9 05:15:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 05:15:57 GMT Subject: RFR: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:50:15 GMT, David Holmes wrote: > That seems fine, assuming 256M is big enough. The test app is very simple (HelloWorld) so 256M is enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28715#issuecomment-3630352547 From iklam at openjdk.org Tue Dec 9 05:15:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 05:15:58 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 05:11:38 GMT, David Holmes wrote: >> To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent the test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. >> >> Testing: >> - tiers 1-4 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Use Ioi's suggestion to fix OOME handling Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28713#pullrequestreview-3555490727 From jpai at openjdk.org Tue Dec 9 05:15:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Dec 2025 05:15:59 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 05:11:38 GMT, David Holmes wrote: >> To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent the test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. >> >> Testing: >> - tiers 1-4 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Use Ioi's suggestion to fix OOME handling Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28713#pullrequestreview-3555492737 From dholmes at openjdk.org Tue Dec 9 05:15:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 05:15:59 GMT Subject: RFR: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 05:12:20 GMT, Ioi Lam wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Ioi's suggestion to fix OOME handling > > Marked as reviewed by iklam (Reviewer). Thanks for the reviews @iklam and @jaikiran ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28713#issuecomment-3630353386 From dholmes at openjdk.org Tue Dec 9 05:19:07 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 05:19:07 GMT Subject: Integrated: 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 01:28:39 GMT, David Holmes wrote: > To prevent the failure mode seen in [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) we should prevent the test threads from being terminated by uncaught exceptions, and allow the main thread to detect and throw all errors. That way we should see what the actual failure is. > > Testing: > - tiers 1-4 (sanity) > > Thanks This pull request has now been integrated. Changeset: 020e3f95 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/020e3f959194029715c18891e79aeed020abd59c Stats: 50 lines in 1 file changed: 28 ins; 3 del; 19 mod 8373293: Change the exception handling in TestNestHostErrorWithMultiThread.java Reviewed-by: jpai, iklam ------------- PR: https://git.openjdk.org/jdk/pull/28713 From dholmes at openjdk.org Tue Dec 9 06:45:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 06:45:54 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:35:19 GMT, Ioi Lam wrote: > Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` > > > Note: this is the same log channel used just a few lines above. > > https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 The CDS logging line was put in for JDK-8226462, and as referenced by Yasumasa it was there for CDS users to be informed (or perhaps more accurately for one of our CDS tests to check it). Does that test no longer exist, or check this condition? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28716#issuecomment-3630609392 From iklam at openjdk.org Tue Dec 9 07:22:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 07:22:32 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting [v2] In-Reply-To: References: Message-ID: <_6HqKSDvWn_IcgdPGn8KXvzVfREpXHUEVaZZ4ZQa-SM=.6026490d-9095-49fe-bbff-a68be95b0494@github.com> > Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` > > > Note: this is the same log channel used just a few lines above. > > https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Removed test case that checks the old log but is no longer relevant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28716/files - new: https://git.openjdk.org/jdk/pull/28716/files/bae01e13..8910b775 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28716&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28716&range=00-01 Stats: 84 lines in 1 file changed: 0 ins; 84 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28716/head:pull/28716 PR: https://git.openjdk.org/jdk/pull/28716 From dholmes at openjdk.org Tue Dec 9 07:35:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Dec 2025 07:35:54 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting [v2] In-Reply-To: <_6HqKSDvWn_IcgdPGn8KXvzVfREpXHUEVaZZ4ZQa-SM=.6026490d-9095-49fe-bbff-a68be95b0494@github.com> References: <_6HqKSDvWn_IcgdPGn8KXvzVfREpXHUEVaZZ4ZQa-SM=.6026490d-9095-49fe-bbff-a68be95b0494@github.com> Message-ID: On Tue, 9 Dec 2025 07:22:32 GMT, Ioi Lam wrote: >> Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` >> >> >> Note: this is the same log channel used just a few lines above. >> >> https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed test case that checks the old log but is no longer relevant If test is no longer relevant then change seems fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28716#pullrequestreview-3555901105 From iklam at openjdk.org Tue Dec 9 07:35:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 07:35:56 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting In-Reply-To: References: Message-ID: <60Eiu1LoxQCPwzp1Zc33E7B8od6Lta18_Lohosbuk7E=.7c5ab7fc-2942-4d21-b8c6-d90700e22178@github.com> On Tue, 9 Dec 2025 06:42:47 GMT, David Holmes wrote: > The CDS logging line was put in for JDK-8226462, and as referenced by Yasumasa it was there for CDS users to be informed (or perhaps more accurately for one of our CDS tests to check it). Does that test no longer exist, or check this condition? This log is used only by the SysDictCras.java test . CDS dumping requires `UseCompressedClassPointers==true`. In the time of JDK-8226462, when running on a host with lot of RAM, `UseCompressedOops` would be disabled, which causes `UseCompressedClassPointers` to be disabled, which caused the CDS dump to fail. This is no longer the case -- `UseCompressedClassPointers` is now independent of `UseCompressedOops` $ java -XX:MaxRAM=512g -XX:MaxRAMPercentage=12.5 -XX:+PrintFlagsFinal --version | grep UseCompressedClassPointers bool UseCompressedClassPointers = true {product} {default} Also, the test is kind of pointless now. The only significant VM flags are - `-XX:SharedBaseAddress=0`: this is covered by other test cases such as test/hotspot/jtreg/runtime/cds/appcds/ArchiveRelocationTest.java - `-XX:MaxRAMPercentage=12.5`: this might have been useful in reproducing the original crash but it's no longer relevant. So I removed this test altogether. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28716#issuecomment-3630781054 From ysuenaga at openjdk.org Tue Dec 9 07:38:59 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Dec 2025 07:38:59 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting [v2] In-Reply-To: <_6HqKSDvWn_IcgdPGn8KXvzVfREpXHUEVaZZ4ZQa-SM=.6026490d-9095-49fe-bbff-a68be95b0494@github.com> References: <_6HqKSDvWn_IcgdPGn8KXvzVfREpXHUEVaZZ4ZQa-SM=.6026490d-9095-49fe-bbff-a68be95b0494@github.com> Message-ID: On Tue, 9 Dec 2025 07:22:32 GMT, Ioi Lam wrote: >> Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` >> >> >> Note: this is the same log channel used just a few lines above. >> >> https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed test case that checks the old log but is no longer relevant Thank you for fixing this! ------------- Marked as reviewed by ysuenaga (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28716#pullrequestreview-3555912377 From sspitsyn at openjdk.org Tue Dec 9 09:06:13 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 9 Dec 2025 09:06:13 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: On Fri, 5 Dec 2025 09:42:51 GMT, Sergey Chernyshev wrote: >> We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module. >> We got the following concerns: >> - Do we really need 3x implementations of the MacOS `tempdir` finder function? >> - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`? >> New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. >> My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS? >> Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this. > > Hi @sspitsyn , > > Thank you for looking at this patch! > >> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions? > > The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root. > >> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. > > The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory. > >> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? > > I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux). > >> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS? > > Yes and this is what this patch was intended for. > >> * Do we really need 3x implementations of the MacOS `tempdir` finder function? > > It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to. > >> * Do we really need a modular dependency f... @sercher Thank you for the readability updates and answering questions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3631118258 From aartemov at openjdk.org Tue Dec 9 10:18:10 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 9 Dec 2025 10:18:10 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v6] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 16:17:41 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. >> >> Tested in tiers 1 - 5. > > 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly > - 8366272: Fixed whitespaces. > - 8366272: Addressed reviewer's comments. > - 8366272: Addressed reviewer's comments. > - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly > - 8366272: Improved errno management in os:xxx methods Thanks for reviews, let's ------------- PR Comment: https://git.openjdk.org/jdk/pull/28086#issuecomment-3631413025 From aartemov at openjdk.org Tue Dec 9 10:18:11 2025 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 9 Dec 2025 10:18:11 GMT Subject: Integrated: 8366272: The os::xxx APIs do not manage errno correctly In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 13:44:09 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. > > Tested in tiers 1 - 5. This pull request has now been integrated. Changeset: 830c4d3b Author: Anton Artemov URL: https://git.openjdk.org/jdk/commit/830c4d3b198597b6af7a21b708bd3a852af200d4 Stats: 20 lines in 6 files changed: 10 ins; 9 del; 1 mod 8366272: The os::xxx APIs do not manage errno correctly Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28086 From jsjolen at openjdk.org Tue Dec 9 14:51:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 9 Dec 2025 14:51:28 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:40:21 GMT, Casper Norrbin wrote: > Hi everyone, > > Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. > > This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. > > Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. > > Testing: > - Oracle tiers 1-8 RDP1 has passed, let\s get this in! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27212#pullrequestreview-3557861488 From syan at openjdk.org Tue Dec 9 15:05:38 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 9 Dec 2025 15:05:38 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v2] In-Reply-To: References: Message-ID: > Hi all, > > On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: > > > page_size = 64K > _java_thread_min_stack_allowed = 72K > _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K > _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K > _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K > > > This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > Change has been verified locally both on linux-x64 and linux-aarch64. SendaoYan 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: - Make TestStackOverflowDuringInit.java start java sub-process after get wb.getMinimumJavaStackSize() - Make TestStackOverflowDuringInit.java start java sub-process after get wb.getMinimumJavaStackSize() - Add WhiteBox.getMinimumJavaStackSize() to get the minimum allowed java stack size - Merge branch 'openjdk:master' into jbs8371948 - 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28352/files - new: https://git.openjdk.org/jdk/pull/28352/files/633f6a79..b3f4fa96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=00-01 Stats: 96082 lines in 1652 files changed: 63062 ins; 23095 del; 9925 mod Patch: https://git.openjdk.org/jdk/pull/28352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352 PR: https://git.openjdk.org/jdk/pull/28352 From iklam at openjdk.org Tue Dec 9 16:13:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 16:13:01 GMT Subject: RFR: 8373295: Wrong log tag for UseCompressedOops ergo setting In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 05:10:55 GMT, Yasumasa Suenaga wrote: >> Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` >> >> >> Note: this is the same log channel used just a few lines above. >> >> https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 > > I completely agree with your change! > > But I received review that it should not be changed from CDS tag (I know it is `aot` now). See review thread in my past proposal for details: https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2019-October/036315.html > > I'm happy to approve if we can accept. Thanks @YaSuenag @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28716#issuecomment-3633064865 From iklam at openjdk.org Tue Dec 9 16:13:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Dec 2025 16:13:02 GMT Subject: Integrated: 8373295: Wrong log tag for UseCompressedOops ergo setting In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:35:19 GMT, Ioi Lam wrote: > Please review this trivial change: Ergonomic settings of `UseCompressedOops` should be logged with `log_debug(gc, heap, coops)` > > > Note: this is the same log channel used just a few lines above. > > https://github.com/openjdk/jdk/blob/c9ab330b7bdd3cc2410ffdb336a63aa0ac7256a3/src/hotspot/share/runtime/arguments.cpp#L1579-L1586 This pull request has now been integrated. Changeset: 8c8d21db Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/8c8d21db6f5bdc35f6eddf91065b4eec462a716f Stats: 88 lines in 2 files changed: 0 ins; 84 del; 4 mod 8373295: Wrong log tag for UseCompressedOops ergo setting Reviewed-by: dholmes, ysuenaga ------------- PR: https://git.openjdk.org/jdk/pull/28716 From lmesnik at openjdk.org Tue Dec 9 18:05:06 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Dec 2025 18:05:06 GMT Subject: RFR: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:21:50 GMT, Ioi Lam wrote: > Please review this small fix for some CDS tests that fail on machines with a lot of RAM. > > The reason is the max heap size setting is used only when the CDS archive is dumped. As a result, when we try to use the CDS archive, the VM ergonomics may use a different oop encoding, and the CDS archive becomes unuseable. > > The fix is to use the same -Xmx when both dumping and using the CDS archive. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28715#pullrequestreview-3558857510 From dhanalla at openjdk.org Tue Dec 9 18:08:39 2025 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Tue, 9 Dec 2025 18:08:39 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows Message-ID: Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. Tests performed: jtreg tier1 & tier2 ------------- Commit messages: - [AArch64] Populate CPU _features flag on Windows Changes: https://git.openjdk.org/jdk/pull/28461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371651 Stats: 20 lines in 1 file changed: 8 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28461/head:pull/28461 PR: https://git.openjdk.org/jdk/pull/28461 From dhanalla at openjdk.org Tue Dec 9 18:08:40 2025 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Tue, 9 Dec 2025 18:08:40 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 21:25:05 GMT, Dhamoder Nalla wrote: > Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. > > Tests performed: jtreg tier1 & tier2 @brianjstafford, can someone from Microsoft take a look at this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28461#issuecomment-3564643190 From bstafford at openjdk.org Wed Dec 10 00:04:36 2025 From: bstafford at openjdk.org (Brian Stafford) Date: Wed, 10 Dec 2025 00:04:36 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 21:25:05 GMT, Dhamoder Nalla wrote: > Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. > > Tests performed: jtreg tier1 & tier2 LGTM src/hotspot/os_cpu/windows_aarch64/vm_version_windows_aarch64.cpp line 31: > 29: int VM_Version::get_current_sve_vector_length() { > 30: assert(VM_Version::supports_sve(), "should not call this"); > 31: // TODO: This is not available in the Windows SDK yet , so conservatively go with the lowest value (128 bits) nit: no space before comma src/hotspot/os_cpu/windows_aarch64/vm_version_windows_aarch64.cpp line 38: > 36: int VM_Version::set_and_get_current_sve_vector_length(int length) { > 37: assert(VM_Version::supports_sve(), "should not call this"); > 38: // TODO: This is not available in the Windows SDK yet , so conservatively go with the lowest value (128 bits) nit: no space before comma ------------- Marked as reviewed by bstafford (Author). PR Review: https://git.openjdk.org/jdk/pull/28461#pullrequestreview-3560178222 PR Review Comment: https://git.openjdk.org/jdk/pull/28461#discussion_r2604698050 PR Review Comment: https://git.openjdk.org/jdk/pull/28461#discussion_r2604698430 From iklam at openjdk.org Wed Dec 10 02:26:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Dec 2025 02:26:09 GMT Subject: RFR: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:50:15 GMT, David Holmes wrote: >> Please review this small fix for some CDS tests that fail on machines with a lot of RAM. >> >> The reason is the max heap size setting is used only when the CDS archive is dumped. As a result, when we try to use the CDS archive, the VM ergonomics may use a different oop encoding, and the CDS archive becomes unuseable. >> >> The fix is to use the same -Xmx when both dumping and using the CDS archive. > > That seems fine, assuming 256M is big enough. > > Thanks Thanks @dholmes-ora @lmesnik for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28715#issuecomment-3635077940 From iklam at openjdk.org Wed Dec 10 02:28:53 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Dec 2025 02:28:53 GMT Subject: Integrated: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 04:21:50 GMT, Ioi Lam wrote: > Please review this small fix for some CDS tests that fail on machines with a lot of RAM. > > The reason is the max heap size setting is used only when the CDS archive is dumped. As a result, when we try to use the CDS archive, the VM ergonomics may use a different oop encoding, and the CDS archive becomes unuseable. > > The fix is to use the same -Xmx when both dumping and using the CDS archive. This pull request has now been integrated. Changeset: d36a234c Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/d36a234c1228fdb12eb5931506ba1e03ebae95fc Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM Reviewed-by: dholmes, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28715 From syan at openjdk.org Wed Dec 10 02:44:04 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 10 Dec 2025 02:44:04 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v3] In-Reply-To: References: Message-ID: > Hi all, > > On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: > > > page_size = 64K > _java_thread_min_stack_allowed = 72K > _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K > _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K > _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K > > > This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > Change has been verified locally both on linux-x64 and linux-aarch64. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Try to fix size_t->jint data loss compiler warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28352/files - new: https://git.openjdk.org/jdk/pull/28352/files/b3f4fa96..bad8596c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352 PR: https://git.openjdk.org/jdk/pull/28352 From syan at openjdk.org Wed Dec 10 03:21:58 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 10 Dec 2025 03:21:58 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v4] In-Reply-To: References: Message-ID: > Hi all, > > On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: > > > page_size = 64K > _java_thread_min_stack_allowed = 72K > _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K > _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K > _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K > > > This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > Change has been verified locally both on linux-x64 and linux-aarch64. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Use jlong instead of jint ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28352/files - new: https://git.openjdk.org/jdk/pull/28352/files/bad8596c..f45cc0cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=02-03 Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352 PR: https://git.openjdk.org/jdk/pull/28352 From stefank at openjdk.org Wed Dec 10 07:23:23 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Dec 2025 07:23:23 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 00:01:11 GMT, Kim Barrett wrote: > Please review this change to Atomic to meet the requirements for constant > initialization in cases where the value type provides the requisite support. > This ensures that in such cases dynamic initialization won't even be > considered a possibility when initialized with constant arguments. > > Testing: mach5 tier1 On the surface, this looks fine to me. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28711#pullrequestreview-3561103973 From epeter at openjdk.org Wed Dec 10 07:42:29 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 07:42:29 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v5] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:14:24 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang 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: > > - Jorn review > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - bracket styles > - Doc tweaks > - Essay > - Spurious change > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Issue number and test update > - Fixed optional and unit test > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - ... and 1 more: https://git.openjdk.org/jdk/compare/f4fe3397...b20b7f5b Drive-by comments about IR test only ;) test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. We would like to move all tests away from `irTests`. It would be better to sort tests by topic, rather than by the method we test them. test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 39: > 37: * @summary Verify constant folding for Optional > 38: * @library /test/lib / > 39: * @requires vm.compiler2.enabled I doubt you actually need the C2 restriction here. IR tests could still run verification for results without C2. IR rules only run if C2 is available, otherwise the test can still pass, just no IR rules are run. test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 40: > 38: * @library /test/lib / > 39: * @requires vm.compiler2.enabled > 40: * @run driver compiler.c2.irTests.constantFold.TestOptional Suggestion: * @run driver ${test.main.class} Since this is now possible, we should use this templated approach now, to avoid invoking the wrong test classes by accident. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3561154527 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605537189 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605543019 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605539633 From dholmes at openjdk.org Wed Dec 10 07:52:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Dec 2025 07:52:31 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v4] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 03:21:58 GMT, SendaoYan wrote: >> Hi all, >> >> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: >> >> >> page_size = 64K >> _java_thread_min_stack_allowed = 72K >> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K >> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K >> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K >> >> >> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java >> >> Change has been verified locally both on linux-x64 and linux-aarch64. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Use jlong instead of jint Looking good. Just a couple of minor issues. Thanks src/hotspot/share/runtime/os.cpp line 2580: > 2578: } > 2579: > 2580: jlong os::get_minimum_java_stack_sizes() { Suggestion: jlong os::get_minimum_java_stack_size() { src/hotspot/share/runtime/os.hpp line 394: > 392: public: > 393: // get allowed minimum java stack sizes > 394: static jlong get_minimum_java_stack_sizes(); Suggestion: // get allowed minimum java stack size static jlong get_minimum_java_stack_size(); test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java line 1: > 1: /* We don't need a test to exercise the WhiteBox API explicitly. test/lib/jdk/test/whitebox/WhiteBox.java line 80: > 78: public native long getHeapSpaceAlignment(); > 79: public native long getHeapAlignment(); > 80: public native long getMinimumJavaStackSize(); Suggestion: public native long getMinimumJavaStackSize(); ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3561172332 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605559716 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605552128 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605565863 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605566674 From kbarrett at openjdk.org Wed Dec 10 10:00:38 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Dec 2025 10:00:38 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly [v6] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 10:13:00 GMT, Anton Artemov 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 six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly >> - 8366272: Fixed whitespaces. >> - 8366272: Addressed reviewer's comments. >> - 8366272: Addressed reviewer's comments. >> - Merge remote-tracking branch 'origin/master' into JDK-8366272-the-os-xxx-api-do-not-manage-errno-correctly >> - 8366272: Improved errno management in os:xxx methods > > Thanks for reviews, let's For the record, although @toxaart accidentally integrated with only 1 approval, I also think it's fine, and only hadn't approved because I'd missed that it had been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28086#issuecomment-3636267855 From sspitsyn at openjdk.org Wed Dec 10 10:26:26 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 10 Dec 2025 10:26:26 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads Message-ID: This update fixes the following problem. The function JavaThread::java_suspend has the following assert: bool JavaThread::java_suspend(bool register_vthread_SR) { // Suspending a vthread transition disabler can cause deadlocks. assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); . . . This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed. A more adequate approach is to tweak the function `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)` so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. Testing: - In progress: mach5 tiers 1-6 ------------- Commit messages: - 8373366: HandshakeState should disallow suspend ops for disabler threads Changes: https://git.openjdk.org/jdk/pull/28740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373366 Stats: 13 lines in 4 files changed: 2 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From stefank at openjdk.org Wed Dec 10 10:39:39 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Dec 2025 10:39:39 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled Message-ID: Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. ------------- Commit messages: - 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled Changes: https://git.openjdk.org/jdk/pull/28741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373411 Stats: 46 lines in 2 files changed: 45 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28741/head:pull/28741 PR: https://git.openjdk.org/jdk/pull/28741 From stefank at openjdk.org Wed Dec 10 10:39:39 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Dec 2025 10:39:39 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: <0YWYyvQOxOpmllvophcXgC4RhDFxkagItoi78Tx0h44=.10191612-99d5-4b99-bdf7-5d630a07d25a@github.com> On Wed, 10 Dec 2025 10:33:04 GMT, Stefan Karlsson wrote: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. This is the assert that you get when hitting this issue: # assert(_heap_load_mode != HeapArchiveMode::_uninitialized) failed: not initialized yet ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3636419073 From epeter at openjdk.org Wed Dec 10 13:12:34 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 13:12:34 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:25:29 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Typo Drive-by comments test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37: > 35: * @library /test/lib / > 36: * @requires vm.compiler2.enabled > 37: * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold Suggestion: * @run driver ${test.main.class} Is the C2 requirement really necessary? test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51: > 49: public int testSum() { > 50: return a.hashCode() + System.identityHashCode(b); > 51: } This does not test correctness of the result. How confident are we that this patch is sufficiently tested? How can we test that the compiled and interpreter hashcode are equivalent? ------------- PR Review: https://git.openjdk.org/jdk/pull/28589#pullrequestreview-3562463539 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2606597900 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2606602984 From liach at openjdk.org Wed Dec 10 15:39:53 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 15:39:53 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 13:07:20 GMT, Emanuel Peter wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37: > >> 35: * @library /test/lib / >> 36: * @requires vm.compiler2.enabled >> 37: * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold > > Suggestion: > > * @run driver ${test.main.class} > > Is the C2 requirement really necessary? The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular. > test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51: > >> 49: public int testSum() { >> 50: return a.hashCode() + System.identityHashCode(b); >> 51: } > > This does not test correctness of the result. How confident are we that this patch is sufficiently tested? > How can we test that the compiled and interpreter hashcode are equivalent? I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607156541 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607151871 From epeter at openjdk.org Wed Dec 10 17:21:05 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 17:21:05 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: Message-ID: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> On Wed, 10 Dec 2025 15:36:36 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37: >> >>> 35: * @library /test/lib / >>> 36: * @requires vm.compiler2.enabled >>> 37: * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold >> >> Suggestion: >> >> * @run driver ${test.main.class} >> >> Is the C2 requirement really necessary? > > The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular. You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal. I would generally remove `@requires` from any test we can, to get more coverage. >> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51: >> >>> 49: public int testSum() { >>> 50: return a.hashCode() + System.identityHashCode(b); >>> 51: } >> >> This does not test correctness of the result. How confident are we that this patch is sufficiently tested? >> How can we test that the compiled and interpreter hashcode are equivalent? > > I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work? You could compute the result in the static initializer, it should therefore be computed in the interpreter. And then add a `@Check` method to compare the `testSum` value from the compiler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607542060 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607538782 From iklam at openjdk.org Wed Dec 10 17:31:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Dec 2025 17:31:34 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> On Wed, 10 Dec 2025 10:33:04 GMT, Stefan Karlsson wrote: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java line 26: > 24: /** > 25: * @test > 26: * @summary Testing -XX:+PrintSharedArchiveAndExit option with no shared heap Please add bug ID. test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java line 30: > 28: * @library /test/lib > 29: * @modules java.base/jdk.internal.misc > 30: * java.management Is this required? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2607576451 PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2607572681 From dhanalla at openjdk.org Wed Dec 10 19:03:46 2025 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Wed, 10 Dec 2025 19:03:46 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows [v2] In-Reply-To: References: Message-ID: > Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. > > Tests performed: jtreg tier1 & tier2 Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision: cleanup spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28461/files - new: https://git.openjdk.org/jdk/pull/28461/files/40af1503..d13c1b26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28461&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28461/head:pull/28461 PR: https://git.openjdk.org/jdk/pull/28461 From dhanalla at openjdk.org Wed Dec 10 19:03:47 2025 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Wed, 10 Dec 2025 19:03:47 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 23:56:24 GMT, Brian Stafford wrote: > LGTM Thanks @brianjstafford for reviewing this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28461#issuecomment-3638530896 From vlivanov at openjdk.org Wed Dec 10 19:49:07 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Dec 2025 19:49:07 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> Message-ID: On Wed, 10 Dec 2025 17:18:15 GMT, Emanuel Peter wrote: >> The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular. > > You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal. > I would generally remove `@requires` from any test we can, to get more coverage. It's a test on C2 IR. What's the point in running it w/o C2? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2608004982 From duke at openjdk.org Wed Dec 10 21:19:42 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 10 Dec 2025 21:19:42 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache Message-ID: ### Summary This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. ### Description The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. ### Performance Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. ### Testing * CodeCache tests have been updated to cover the new `HotCodeHeap`. * Dedicated tests for the `HotCodeGrouper` will be added in follow-up work. ### Logging * New logging: `-Xlog:hotcodegrouper`. ------------- Commit messages: - Update blob checks - Merge fix - Merge remote-tracking branch 'origin/master' into JDK-8326205 - Clean up - New implementation - Mark nmethods seen by profiler as maybe on stack - Rename option HotCodeGrouper to HotCodeHeap due to name conflict - Dont count nmethods from HotCodeHeap as new - Resize _samples if needed; Profile till steady nmethod count - Use existing Platform.java functions to determine if C2 is available - ... and 12 more: https://git.openjdk.org/jdk/compare/1ae4a6c4...c4c779a5 Changes: https://git.openjdk.org/jdk/pull/27858/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326205 Stats: 1284 lines in 40 files changed: 1198 ins; 18 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From kvn at openjdk.org Wed Dec 10 21:19:44 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 10 Dec 2025 21:19:44 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:06:35 GMT, Chad Rakoczy wrote: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... Consider making this feature C2 specific since you require presence of C2. Move flags into `opto/c2_globals.hpp` or `compiler/compiler_globals.hpp` and add `#ifdef COMPILER2` around new code. Especially new `hotCodeGrouper.*` files. We don't need this code in VM which is built without C2. You would still need to check `is_c2_enabled()` because of `StopAtTierLevel=n` flag. src/hotspot/share/compiler/compilerDefinitions.cpp line 346: > 344: vm_exit_during_initialization("HotCodeHeap requires C2 enabled", NULL); > 345: } > 346: } Put it under `#ifdef COMPILER2` ------------- PR Review: https://git.openjdk.org/jdk/pull/27858#pullrequestreview-3351380445 PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2440788365 From duke at openjdk.org Wed Dec 10 21:19:45 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 10 Dec 2025 21:19:45 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: <5Yq39yXUeGDG7OjkvbvP1wcFb6Qz4AaIOOhmR8XlGMY=.5a60d563-073b-4bd6-b5c2-262bcbe8bee6@github.com> On Fri, 17 Oct 2025 18:10:16 GMT, Vladimir Kozlov wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Dedicated... > > src/hotspot/share/compiler/compilerDefinitions.cpp line 346: > >> 344: vm_exit_during_initialization("HotCodeHeap requires C2 enabled", NULL); >> 345: } >> 346: } > > Put it under `#ifdef COMPILER2` I moved most of the new code under `#ifdef COMPILER2` and into `opto/c2_globals.hpp` I'm unsure what to do about `HotCodeHeapSize`. I can also make that flag C2 only which requires some updates to `codeCache.cpp` and overall I don't think it makes the code too messy. The biggest problem with that is what to do about `CodeBlobType` with the addition of the `MethodHot` type Before: enum class CodeBlobType { MethodNonProfiled = 0, // Execution level 1 and 4 (non-profiled) nmethods (including native nmethods) MethodProfiled = 1, // Execution level 2 and 3 (profiled) nmethods NonNMethod = 2, // Non-nmethods like Buffers, Adapters and Runtime Stubs All = 3, // All types (No code cache segmentation) NumTypes = 4 // Number of CodeBlobTypes }; After: enum class CodeBlobType { MethodNonProfiled = 0, // Execution level 1 and 4 (non-profiled) nmethods (including native nmethods) MethodProfiled = 1, // Execution level 2 and 3 (profiled) nmethods MethodHot = 2, // Nmethods predicted to be always hot NonNMethod = 3, // Non-nmethods like Buffers, Adapters and Runtime Stubs All = 4, // All types (No code cache segmentation) NumTypes = 5 // Number of CodeBlobTypes }; If we do #ifdef COMPILER2 /* AFTER */ #else /* BEFORE */ #endif Things start getting weird if blob types have different values in different builds. Particuatlly in tests such as [BlobType.java](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/whitebox/code/BlobType.java). I think that we need to leave `CodeBlobType::MethodHot` regardless if C2 is present or not. In terms of `HotCodeHeapSize` I'm not sure the best place for it. I think it makes sense to leave with the other code heap flags which also allows us to print an error if specified without C2. On the other hand if it requires C2 is should be in `opto/c2_globals.hpp` @vnkozlov @eastig What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2475158385 From eastigeevich at openjdk.org Wed Dec 10 21:41:48 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Dec 2025 21:41:48 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: <5Yq39yXUeGDG7OjkvbvP1wcFb6Qz4AaIOOhmR8XlGMY=.5a60d563-073b-4bd6-b5c2-262bcbe8bee6@github.com> References: <5Yq39yXUeGDG7OjkvbvP1wcFb6Qz4AaIOOhmR8XlGMY=.5a60d563-073b-4bd6-b5c2-262bcbe8bee6@github.com> Message-ID: On Wed, 29 Oct 2025 19:51:42 GMT, Chad Rakoczy wrote: > I think that we need to leave `CodeBlobType::MethodHot` regardless if C2 is present or not. I agree. Another option might be to create a heap of `MethodNonProfiled` type which is hidden from `CodeCache::allocate`. `nmethod::relocate(CodeBlobType)` will be changed to `nmethod::relocate(CodeHeap*)`. This might simplify things, for example with putting `HotCodeHeapSize` in `opto/c2_globals.hpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2608299316 From syan at openjdk.org Thu Dec 11 01:57:58 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 11 Dec 2025 01:57:58 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v5] In-Reply-To: References: Message-ID: > Hi all, > > On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: > > > page_size = 64K > _java_thread_min_stack_allowed = 72K > _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K > _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K > _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K > > > This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > Change has been verified locally both on linux-x64 and linux-aarch64. SendaoYan has updated the pull request incrementally with two additional commits since the last revision: - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28352/files - new: https://git.openjdk.org/jdk/pull/28352/files/f45cc0cb..ee8c621f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=03-04 Stats: 51 lines in 5 files changed: 0 ins; 46 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352 PR: https://git.openjdk.org/jdk/pull/28352 From syan at openjdk.org Thu Dec 11 02:11:25 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 11 Dec 2025 02:11:25 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v4] In-Reply-To: References: Message-ID: <7kVq0fx3slrYGIW-Q6lwPw92gELG0E7BmhjVgAGc_8w=.75d74468-ee41-4e4d-a038-1645616fe778@github.com> On Wed, 10 Dec 2025 07:46:27 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use jlong instead of jint > > src/hotspot/share/runtime/os.cpp line 2580: > >> 2578: } >> 2579: >> 2580: jlong os::get_minimum_java_stack_sizes() { > > Suggestion: > > jlong os::get_minimum_java_stack_size() { Fixed. > src/hotspot/share/runtime/os.hpp line 394: > >> 392: public: >> 393: // get allowed minimum java stack sizes >> 394: static jlong get_minimum_java_stack_sizes(); > > Suggestion: > > // get allowed minimum java stack size > static jlong get_minimum_java_stack_size(); Thanks. `get_minimum_java_stack_sizes` has been replaced as `get_minimum_java_stack_size`. > test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java line 1: > >> 1: /* > > We don't need a test to exercise the WhiteBox API explicitly. Okey. The new test test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java has been removed. > test/lib/jdk/test/whitebox/WhiteBox.java line 80: > >> 78: public native long getHeapSpaceAlignment(); >> 79: public native long getHeapAlignment(); >> 80: public native long getMinimumJavaStackSize(); > > Suggestion: > > public native long getMinimumJavaStackSize(); Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608861966 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608861218 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608863514 PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608862645 From shade at openjdk.org Thu Dec 11 07:20:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 07:20:23 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:33:04 GMT, Stefan Karlsson wrote: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. Hold on, how does it crash? I cannot see right away how this would fail: size_t StringTable::shared_entry_count() { assert(HeapShared::is_loading_mapping_mode(), "should not reach here"); return _shared_table.entry_count(); } class SimpleCompactHashtable { ... inline size_t entry_count() const { return _entry_count; } ... } static SharedStringTable _shared_table; The assert in `StringTable::shared_entry_count()` is likely incomplete too. ------------- PR Review: https://git.openjdk.org/jdk/pull/28741#pullrequestreview-3566059384 From epeter at openjdk.org Thu Dec 11 07:22:34 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 11 Dec 2025 07:22:34 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> Message-ID: <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> On Wed, 10 Dec 2025 19:46:43 GMT, Vladimir Ivanov wrote: >> You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal. >> I would generally remove `@requires` from any test we can, to get more coverage. > > It's a test on C2 IR. What's the point in running it w/o C2? You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2609462695 From shade at openjdk.org Thu Dec 11 07:25:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 07:25:28 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 07:17:48 GMT, Aleksey Shipilev wrote: > Hold on, how does it crash? Oh, so it fails the assert in the mode checker: inline bool HeapShared::is_loading_mapping_mode() { assert(_heap_load_mode != HeapArchiveMode::_uninitialized, "not initialized yet"); // <--- return _heap_load_mode == HeapArchiveMode::_mapping; } All right. The assert in `StringTable::shared_entry_count()` needs fixing as well then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3640594738 From lmesnik at openjdk.org Thu Dec 11 07:42:22 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 11 Dec 2025 07:42:22 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:18:11 GMT, Serguei Spitsyn wrote: > This update fixes the following problem. The function JavaThread::java_suspend has the following assert: > > bool JavaThread::java_suspend(bool register_vthread_SR) { > // Suspending a vthread transition disabler can cause deadlocks. > assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); > . . . > > This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed. > > A more adequate approach is to tweak the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)` > so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > Testing: > - In progress: mach5 tiers 1-6 The fix looks good. However, I think the it makes a sense to add regression test that tries to suspend thread while it processing event callback. Can you please show where mounting/unmounting is disabled for jvmti events. i was unable to fines this place. ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3566121535 From stefank at openjdk.org Thu Dec 11 08:59:22 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 08:59:22 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 07:17:48 GMT, Aleksey Shipilev wrote: > Hold on, how does it crash? I cannot see right away how this would fail: > > ``` > size_t StringTable::shared_entry_count() { > assert(HeapShared::is_loading_mapping_mode(), "should not reach here"); > return _shared_table.entry_count(); > } > > class SimpleCompactHashtable { > ... > inline size_t entry_count() const { > return _entry_count; > } > ... > } > > static SharedStringTable _shared_table; > ``` > > The assert in `StringTable::shared_entry_count()` is likely incomplete too. That one has been left as-is intentionally. We should never call `shared_entry_count` without having enabled "heap sharing" and "loading mode of heap sharing". If anyone would try to call it without enabling/initializing "loading mode", then we'll get an appropriate assert that the loading mode has not been initialized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3640883819 From stefank at openjdk.org Thu Dec 11 08:59:24 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 08:59:24 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:33:04 GMT, Stefan Karlsson wrote: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. I could change the code to: size_t StringTable::shared_entry_count() { assert(HeapShared::is_loading(), "should not reach here"); assert(HeapShared::is_loading_mapping_mode(), "should not reach here"); return _shared_table.entry_count(); } Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3640906547 From stefank at openjdk.org Thu Dec 11 08:59:27 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 08:59:27 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> References: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> Message-ID: On Wed, 10 Dec 2025 17:28:06 GMT, Ioi Lam wrote: >> Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. > > test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java line 26: > >> 24: /** >> 25: * @test >> 26: * @summary Testing -XX:+PrintSharedArchiveAndExit option with no shared heap > > Please add bug ID. Just curious: why is that important? I would have guessed that the git history would be sufficient to figure this out. > test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java line 30: > >> 28: * @library /test/lib >> 29: * @modules java.base/jdk.internal.misc >> 30: * java.management > > Is this required? I don't know. I copy-n-pasted the code from `PrintSharedArchiveAndExit.java` and didn't think about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2609699814 PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2609726050 From dholmes at openjdk.org Thu Dec 11 09:20:24 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Dec 2025 09:20:24 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v5] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan wrote: >> Hi all, >> >> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: >> >> >> page_size = 64K >> _java_thread_min_stack_allowed = 72K >> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K >> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K >> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K >> >> >> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java >> >> Change has been verified locally both on linux-x64 and linux-aarch64. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java > - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3566467929 From shade at openjdk.org Thu Dec 11 09:26:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 09:26:10 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> Message-ID: On Thu, 11 Dec 2025 08:45:42 GMT, Stefan Karlsson wrote: >> test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java line 26: >> >>> 24: /** >>> 25: * @test >>> 26: * @summary Testing -XX:+PrintSharedArchiveAndExit option with no shared heap >> >> Please add bug ID. > > Just curious: why is that important? I would have guessed that the git history would be sufficient to figure this out. jtreg allows running the tests related to a particular bug ID: https://openjdk.org/jtreg/command-help.html -- although I don't know who uses this feature instead of just running the majority of the tests most of the time :) -bug: Run only those tests which apply to the given bugid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2609821185 From shade at openjdk.org Thu Dec 11 09:32:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 09:32:56 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 08:56:54 GMT, Stefan Karlsson wrote: > Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it. Meh, can go either way. Honestly, I find it confusing that `HeapShared::is_loading_mapping_mode()` is not a subset of `HeapShared::is_loading()`. The name suggests it is. In other words, I would have expected `is_loading_mapping_mode() == true` implies `is_loading() == true`. But I won't quibble for this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3641040274 From stefank at openjdk.org Thu Dec 11 09:46:19 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 09:46:19 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: Message-ID: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28741/files - new: https://git.openjdk.org/jdk/pull/28741/files/4221e141..a1dde921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28741&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28741/head:pull/28741 PR: https://git.openjdk.org/jdk/pull/28741 From shade at openjdk.org Thu Dec 11 09:46:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 09:46:19 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 09:42:28 GMT, Stefan Karlsson wrote: >> Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28741#pullrequestreview-3566567238 From shade at openjdk.org Thu Dec 11 09:46:21 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 09:46:21 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 08:56:54 GMT, Stefan Karlsson wrote: > Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it. Meh, can go either way. I won't quibble for this patch. Honestly, my expectation is that when `HeapShared::is_loading_mapping_mode() == true`, then `HeapShared::is_loading() == true`, and when `is_loading_mapping_mode() == false`, then `is_loading()` is undefined/dont-care value. In that sense, current code that checks only `HeapShared::is_loading_mapping_mode()` would have been correct already. But I am guessing you don't want to miss a bug when `is_loading_mapping_mode()` returns `false`, just because we have a lifecycle bug somewhere and loading mode is uninitialized. OTOH, it is literally the same as checking `is_loading()` explicitly like your PR does, so it gains us nothing safety-wise, and only confuses ourselves. Maybe rethinking the state machinery a bit here would be a good cleanup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3641077572 From stefank at openjdk.org Thu Dec 11 09:54:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 09:54:42 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 09:38:56 GMT, Aleksey Shipilev wrote: > > Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it. > > Meh, can go either way. I won't quibble for this patch. > > Honestly, my expectation is that when `HeapShared::is_loading_mapping_mode() == true`, then `HeapShared::is_loading() == true`, and when `is_loading_mapping_mode() == false`, then `is_loading()` is undefined/dont-care value. In that sense, current code that checks only `HeapShared::is_loading_mapping_mode()` would have been correct already. But I am guessing you don't want to miss a bug when `is_loading_mapping_mode()` returns `false`, just because we have a lifecycle bug somewhere and loading mode is uninitialized. Yes. We have had a few of those bugs at the end of the development cycle for the object streaming JEP. > OTOH, it is literally the same as checking `is_loading()` explicitly like your PR does, so it gains us nothing safety-wise, and only confuses ourselves. Maybe rethinking the state machinery a bit here would be a good cleanup. I think Erik had it more like you suggest, but if I understood Ioi correctly he wanted things to be more explicit, and this is what we ended up with. I don't mind if someone wants to take a stab at restructuring this, but I'm not personally volunteering to do this. I would rather take the time to make other refactoring and renaming that we felt would benefit the heap sharing code, and we had hope to get to it after the JEP was delivered. However, the reality is that we're all prioritizing other work at the moment so I don't know if / when we'll get to that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3641121965 From stefank at openjdk.org Thu Dec 11 09:54:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 09:54:44 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> Message-ID: On Thu, 11 Dec 2025 09:23:35 GMT, Aleksey Shipilev wrote: >> Just curious: why is that important? I would have guessed that the git history would be sufficient to figure this out. > > jtreg allows running the tests related to a particular bug ID: https://openjdk.org/jtreg/command-help.html -- although I don't know who uses this feature instead of just running the majority of the tests most of the time :) > > > -bug: Run only those tests which apply to the given bugid. OK. I've never felt the need or want to use that :D. I'll add the bugid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2609864122 From cnorrbin at openjdk.org Thu Dec 11 12:08:36 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 11 Dec 2025 12:08:36 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing Message-ID: Hi everyone, The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. Here is the container printout before: container (cgroup) information: container_type: cgroupv1 cpu_cpuset_cpus: 0-15 cpu_memory_nodes: 0-1 active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 cpu_quota: 1600000 cpu_period: 100000 cpu_shares: no shares cpu_usage_in_micros: 2648091 memory_limit_in_bytes: 4194304 k memory_and_swap_limit_in_bytes: 8388608 k memory_soft_limit_in_bytes: unlimited memory_throttle_limit_in_bytes: unavailable memory_usage_in_bytes: 61116 k memory_max_usage_in_bytes: 61116 k rss_usage_in_bytes: 56332 k cache_usage_in_bytes: 1880 k kernel_memory_limit_in_bytes: unlimited kernel_memory_usage_in_bytes: 1584 k kernel_memory_max_usage_in_bytes: 1644 k maximum number of tasks: unlimited current number of tasks: 17 And here it is after: container (cgroup) information: container_type: cgroupv1 cpu_cpuset_cpus: 0-15 cpu_memory_nodes: 0-1 active_processor_count: 8 (from -XX:ActiveProcessorCount) cpu_quota: 1600000 cpu_period: 100000 cpu_shares: no shares cpu_usage: 2648091 us memory_limit: 4194304 kB memory_and_swap_limit: 8388608 kB memory_soft_limit: unlimited memory_throttle_limit: unavailable memory_usage: 61116 kB memory_max_usage: 61116 kB rss_usage: 56332 kB cache_usage: 1880 kB kernel_memory_limit: unlimited kernel_memory_usage: 1584 kB kernel_memory_max_usage: 1644 kB maximum number of tasks: unlimited current number of tasks: 17 To accomplish this, I have added a new `OSContainer::print_container_metric()` function that does the prettified printing. This function is templated to accept various value types and relies on a helper struct to select the correct format string at compile time. This is necessary since dynamic format strings are not allowed (`-Wformat-nonliteral`). As a consequence, we have to explicitly instantiate the function for each templated type. The updated formatting required changes to some tests, as they previously matched the old strings exactly. I have updated these tests to use more robust regex checks. Testing: - Oracle tiers 1-5 - Local container tests on cgroup v1 and v2 on both Podman and Docker ------------- Commit messages: - improved container limit printing Changes: https://git.openjdk.org/jdk/pull/28766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371408 Stats: 109 lines in 10 files changed: 32 ins; 20 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/28766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28766/head:pull/28766 PR: https://git.openjdk.org/jdk/pull/28766 From sgehwolf at openjdk.org Thu Dec 11 13:50:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Dec 2025 13:50:04 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 12:02:22 GMT, Casper Norrbin wrote: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... Nice work! I like it. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28766#pullrequestreview-3567531682 From cnorrbin at openjdk.org Thu Dec 11 14:19:33 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 11 Dec 2025 14:19:33 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 12:02:22 GMT, Casper Norrbin wrote: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... Removing the other issue and marking it as duplicate instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28766#issuecomment-3642139873 From iklam at openjdk.org Thu Dec 11 14:44:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Dec 2025 14:44:38 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> Message-ID: <319S19YCl4MZ-2RiDK-DEgf2LsgT1LLBsr4acVdAtg4=.b5b9fe1e-804b-4f41-9626-54433e52cedd@github.com> On Thu, 11 Dec 2025 09:35:44 GMT, Stefan Karlsson wrote: >> jtreg allows running the tests related to a particular bug ID: https://openjdk.org/jtreg/command-help.html -- although I don't know who uses this feature instead of just running the majority of the tests most of the time :) >> >> >> -bug: Run only those tests which apply to the given bugid. > > OK. I've never felt the need or want to use that :D. I'll add the bugid. The reason I asked for the bug ID: The usage in this test is not common: `java -XX:AOTCacheOutput=... -XX:+PrintSharedArchiveAndExit` will not create the specified AOT cache. Having the bug ID will make it easy to understand why the test is written in this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2610854454 From iklam at openjdk.org Thu Dec 11 14:44:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Dec 2025 14:44:34 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: Message-ID: <4FbiTuO1sIR2TGz0mDecHWjkxyEDW8Kx8YF5FNDb240=.73621d33-f210-4f4e-83ec-57211c96b39c@github.com> On Thu, 11 Dec 2025 09:46:19 GMT, Stefan Karlsson wrote: >> Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28741#pullrequestreview-3567786368 From aph at openjdk.org Thu Dec 11 15:11:35 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 11 Dec 2025 15:11:35 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:06:35 GMT, Chad Rakoczy wrote: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... Thanks. I need to stress test this code, especially by moving nmethods as much as possible while many threads are executing. Is one of the stress tests here suitable for that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3642374309 From fbredberg at openjdk.org Thu Dec 11 15:17:27 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 11 Dec 2025 15:17:27 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file [v2] In-Reply-To: References: Message-ID: > The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 > > By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. > > Passes tier1-7 without any problems that can be traced to this PR. Fredrik Bredberg 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 branch 'master' into 8371347_object_monitor_table_in_separate_file - Update after review - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file - 8371347: Move the ObjectMonitorTable to a separate new file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28565/files - new: https://git.openjdk.org/jdk/pull/28565/files/764e6692..608c55db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28565&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28565&range=00-01 Stats: 49335 lines in 712 files changed: 30970 ins; 14868 del; 3497 mod Patch: https://git.openjdk.org/jdk/pull/28565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28565/head:pull/28565 PR: https://git.openjdk.org/jdk/pull/28565 From fbredberg at openjdk.org Thu Dec 11 15:17:28 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 11 Dec 2025 15:17:28 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 13:07:53 GMT, Coleen Phillimore wrote: >> Fredrik Bredberg 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 branch 'master' into 8371347_object_monitor_table_in_separate_file >> - Update after review >> - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file >> - 8371347: Move the ObjectMonitorTable to a separate new file > > src/hotspot/share/runtime/objectMonitorTable.hpp line 35: > >> 33: >> 34: class ObjectMonitorTable : AllStatic { >> 35: struct Config { > > Can you hide all of this in the .cpp file like symbolTable.cpp hides the CHT implementation instead of having it all in the hpp file? The interface only needs to be the functions at the end. Hopefully this "[Update after review](https://github.com/openjdk/jdk/pull/28565/commits/914589326270ec61c6b64d086d01d6d6f16357be)" version is what you want. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28565#discussion_r2610982098 From cnorrbin at openjdk.org Thu Dec 11 15:41:47 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 11 Dec 2025 15:41:47 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: cross-compile fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28766/files - new: https://git.openjdk.org/jdk/pull/28766/files/34f89c14..e88713c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28766/head:pull/28766 PR: https://git.openjdk.org/jdk/pull/28766 From cnorrbin at openjdk.org Thu Dec 11 15:41:48 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 11 Dec 2025 15:41:48 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 12:02:22 GMT, Casper Norrbin wrote: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... The template types mismatched when cross-compiling to 32-bit. I've fixed so we use the correct types for the format, but as a consequence we need one more template instantiation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28766#issuecomment-3642510020 From stefank at openjdk.org Thu Dec 11 15:54:50 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Dec 2025 15:54:50 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: <319S19YCl4MZ-2RiDK-DEgf2LsgT1LLBsr4acVdAtg4=.b5b9fe1e-804b-4f41-9626-54433e52cedd@github.com> References: <4BcwapAl-mrhfICQrDvDxAw-NZ3QuD60_vs8-i8Mlto=.af0ab632-c9ef-4fc9-9977-d880b13cdccf@github.com> <319S19YCl4MZ-2RiDK-DEgf2LsgT1LLBsr4acVdAtg4=.b5b9fe1e-804b-4f41-9626-54433e52cedd@github.com> Message-ID: On Thu, 11 Dec 2025 14:41:13 GMT, Ioi Lam wrote: >> OK. I've never felt the need or want to use that :D. I'll add the bugid. > > The reason I asked for the bug ID: > > The usage in this test is not common: `java -XX:AOTCacheOutput=... -XX:+PrintSharedArchiveAndExit` will not create the specified AOT cache. Having the bug ID will make it easy to understand why the test is written in this way. OK. I would have used git for that ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28741#discussion_r2611125098 From eastigeevich at openjdk.org Thu Dec 11 17:30:19 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 11 Dec 2025 17:30:19 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:06:35 GMT, Chad Rakoczy wrote: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... src/hotspot/share/runtime/hotCodeGrouper.cpp line 77: > 75: void HotCodeGrouper::run() { > 76: while (true) { > 77: os::naked_sleep(HotCodeIntervalSeconds * 1000); I see you have switched to `sleep` to control HotCodeGrouper. Is it better than wait/notify when HotCodeGrouper thread waits for a number of new nmethods exceeding a threshold? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2611452734 From eastigeevich at openjdk.org Thu Dec 11 17:45:58 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 11 Dec 2025 17:45:58 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:06:35 GMT, Chad Rakoczy wrote: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... src/hotspot/share/runtime/hotCodeSampler.cpp line 41: > 39: uint64_t start_time = os::javaTimeMillis(); > 40: > 41: while (true) { Should we skip sampling if we are at a safepoint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2611501217 From kvn at openjdk.org Thu Dec 11 18:29:43 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Dec 2025 18:29:43 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:06:35 GMT, Chad Rakoczy wrote: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... I am planning to review that but I currently don't have time. I will look on it later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3643234641 From coleenp at openjdk.org Thu Dec 11 19:26:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Dec 2025 19:26:20 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:17:27 GMT, Fredrik Bredberg wrote: >> The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 >> >> By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. >> >> Passes tier1-7 without any problems that can be traced to this PR. > > Fredrik Bredberg 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 branch 'master' into 8371347_object_monitor_table_in_separate_file > - Update after review > - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file > - 8371347: Move the ObjectMonitorTable to a separate new file Thank you! It looks great! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28565#pullrequestreview-3568967618 From duke at openjdk.org Thu Dec 11 20:57:30 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 11 Dec 2025 20:57:30 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 17:43:07 GMT, Evgeny Astigeevich wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Dedicated... > > src/hotspot/share/runtime/hotCodeSampler.cpp line 41: > >> 39: uint64_t start_time = os::javaTimeMillis(); >> 40: >> 41: while (true) { > > Should we skip sampling if we are at a safepoint? I don't think we should stop sampling but we could add a check and `continue` if we are at a safepoint. Ultimately I'm not sure it would make a huge difference because safepoints are usually relatively short but I think it's worth adding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2612036943 From duke at openjdk.org Thu Dec 11 21:08:29 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 11 Dec 2025 21:08:29 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 17:27:24 GMT, Evgeny Astigeevich wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Dedicated... > > src/hotspot/share/runtime/hotCodeGrouper.cpp line 77: > >> 75: void HotCodeGrouper::run() { >> 76: while (true) { >> 77: os::naked_sleep(HotCodeIntervalSeconds * 1000); > > I see you have switched to `sleep` to control HotCodeGrouper. Is it better than wait/notify when HotCodeGrouper thread waits for a number of new nmethods exceeding a threshold? My concern with wait/notify is when the application is in a steady state and no longer compiling many methods. If a hot method is registered shortly after we finish sampling we could wait a long time before we actually profile again and relocate it. Maybe there's a middle ground? When a new nmethod is registered starting sampling if (1) we are above the "new C2 threshold" or (2) it has be X minutes since the last sampling ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2612062778 From dholmes at openjdk.org Thu Dec 11 21:38:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Dec 2025 21:38:41 GMT Subject: RFR: 8373522: Remove expired flags in JDK 27 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 - the Java man page is trivially updated Thanks ------------- Commit messages: - 8373522: Remove expired flags in JDK 27 Changes: https://git.openjdk.org/jdk/pull/28776/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28776&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373522 Stats: 28 lines in 2 files changed: 2 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28776/head:pull/28776 PR: https://git.openjdk.org/jdk/pull/28776 From jnorlinder at openjdk.org Thu Dec 11 22:12:00 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 11 Dec 2025 22:12:00 GMT Subject: RFR: 8373557: Remove stale comments after JDK-8372584 Message-ID: Hi all, This is a small patch to fix stale comments after removing reading /proc to get user CPU time. A note on the proposed removal of: // This is the fastest way to get thread cpu time on Linux. // Returns cpu time (user+sys) for any thread, not only for current. // POSIX compliant clocks are implemented in the kernels 2.6.16+. // It might work on 2.6.10+ with a special kernel/glibc patch. // For reference, please, see IEEE Std 1003.1-2004: // http://www.unix.org/single_unix_specification jlong os::Linux::thread_cpu_time(clockid_t clockid) { Since we may call this method with a clockid_t that will only resolve user time this comment may be confusing. Moreover, I don't think we need to keep the comment here when POSIX compliant clock are implemented. ------------- Commit messages: - Remove stale comments Changes: https://git.openjdk.org/jdk/pull/28777/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28777&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373557 Stats: 11 lines in 2 files changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28777/head:pull/28777 PR: https://git.openjdk.org/jdk/pull/28777 From pchilanomate at openjdk.org Thu Dec 11 22:13:19 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 11 Dec 2025 22:13:19 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:18:11 GMT, Serguei Spitsyn wrote: > This update fixes the following problem. The function JavaThread::java_suspend has the following assert: > > bool JavaThread::java_suspend(bool register_vthread_SR) { > // Suspending a vthread transition disabler can cause deadlocks. > assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); > . . . > > This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed. > > A more adequate approach is to tweak the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)` > so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > Testing: > - In progress: mach5 tiers 1-6 Hi Serguei, some comments below, thanks. src/hotspot/share/runtime/handshake.cpp line 524: > 522: assert(allow_suspend || !check_async_exception, "invalid case"); > 523: #if INCLUDE_JVMTI > 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation? src/hotspot/share/runtime/javaThread.cpp line 1182: > 1180: bool JavaThread::java_suspend(bool register_vthread_SR) { > 1181: // Suspending a vthread transition disabler can cause deadlocks. > 1182: assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run? ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3569493854 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2612230146 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2612215094 From dholmes at openjdk.org Thu Dec 11 22:30:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Dec 2025 22:30:14 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file [v2] In-Reply-To: References: Message-ID: <5hbEZQQkBfXoq8V6hypV1joAeT13V69G6jgr6K5lTAQ=.6057051f-b76f-403c-a02e-7b35c3eed418@github.com> On Thu, 11 Dec 2025 15:17:27 GMT, Fredrik Bredberg wrote: >> The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 >> >> By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. >> >> Passes tier1-7 without any problems that can be traced to this PR. > > Fredrik Bredberg 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 branch 'master' into 8371347_object_monitor_table_in_separate_file > - Update after review > - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file > - 8371347: Move the ObjectMonitorTable to a separate new file Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28565#pullrequestreview-3569571531 From kvn at openjdk.org Thu Dec 11 22:33:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Dec 2025 22:33:00 GMT Subject: RFR: 8373522: Remove expired flags in JDK 27 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 21:31:07 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 > - the Java man page is trivially updated > > Thanks Good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28776#pullrequestreview-3569579151 From duke at openjdk.org Fri Dec 12 00:13:32 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Fri, 12 Dec 2025 00:13:32 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v2] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Dedicated tests for the `HotCodeGrouper` will be ... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Add StessHotCodeGrouper test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/c4c779a5..ce1c685f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=00-01 Stats: 167 lines in 2 files changed: 166 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From dholmes at openjdk.org Fri Dec 12 01:43:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Dec 2025 01:43:51 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:41:47 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. >> >> This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. >> >> >> Here is the container printout before: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage_in_micros: 2648091 >> memory_limit_in_bytes: 4194304 k >> memory_and_swap_limit_in_bytes: 8388608 k >> memory_soft_limit_in_bytes: unlimited >> memory_throttle_limit_in_bytes: unavailable >> memory_usage_in_bytes: 61116 k >> memory_max_usage_in_bytes: 61116 k >> rss_usage_in_bytes: 56332 k >> cache_usage_in_bytes: 1880 k >> kernel_memory_limit_in_bytes: unlimited >> kernel_memory_usage_in_bytes: 1584 k >> kernel_memory_max_usage_in_bytes: 1644 k >> maximum number of tasks: unlimited >> current number of tasks: 17 >> >> >> And here it is after: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 8 (from -XX:ActiveProcessorCount) >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage: 2648091 us >> memory_limit: 4194304 kB >> memory_and_swap_limit: 8388608 kB >> memory_soft_limit: unlimited >> memory_throttle_limit: unavailable >> memory_usage: 61116 kB >> memory_max_usage: 61116 kB >> rss_usage: 56332 kB >> cache_usage: 1880 kB >> kernel_memory_limit: unlimited >> kernel_memory_usage: 1584 kB >> kernel_memory_max_usage: ... > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > cross-compile fix That looks good. A couple of queries below. Thanks src/hotspot/os/linux/osContainer_linux.cpp line 308: > 306: os::snprintf_checked(value_str, longest_value, metric_fmt::fmt, value); > 307: st->print("%s: %*s", metrics, max_length - static_cast(strlen(metrics)) - 2, value_str); // -2 for the ": " > 308: st->print_cr(unit[0] != '\0' ? " %s" : "", unit); Might a format checker complain about passing `unit` in the case there is no actual format specifier provided? src/hotspot/os/linux/osContainer_linux.cpp line 315: > 313: if (res.value() != value_unlimited) { > 314: if (res.value() >= 1024) { > 315: print_container_metric(st, metrics, res.value() / K, "kB"); Pre-existing, but does this assume the value will always be a multiple of K? src/hotspot/os/linux/os_linux.cpp line 2450: > 2448: assert(i > 0, "must be"); > 2449: if (ActiveProcessorCount > 0) { > 2450: OSContainer::print_container_metric(st, "active_processor_count", ActiveProcessorCount, "(from -XX:ActiveProcessorCount)"); Is it worth still reporting the true processor count in this case? You can infer it from `cpu_cpusets_cpus` ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28766#pullrequestreview-3569922128 PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612579655 PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612583695 PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612578764 From dholmes at openjdk.org Fri Dec 12 01:58:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Dec 2025 01:58:16 GMT Subject: RFR: 8373522: Remove expired flags in JDK 27 In-Reply-To: References: Message-ID: <9l188INMArkYxYfVhGrNikp5nB6HYdMSL7s4Sr5SRaY=.6f28552a-b23e-4415-8229-60731172514c@github.com> On Thu, 11 Dec 2025 22:30:47 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 >> - the Java man page is trivially updated >> >> Thanks > > Good Thanks for the review @vnkozlov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28776#issuecomment-3644562327 From dholmes at openjdk.org Fri Dec 12 01:59:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Dec 2025 01:59:55 GMT Subject: RFR: 8373557: Remove stale comments after JDK-8372584 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 22:03:54 GMT, Jonas Norlinder wrote: > Hi all, > > This is a small patch to fix stale comments after removing reading /proc to get user CPU time. > > A note on the proposed removal of: > > // This is the fastest way to get thread cpu time on Linux. > // Returns cpu time (user+sys) for any thread, not only for current. > // POSIX compliant clocks are implemented in the kernels 2.6.16+. > // It might work on 2.6.10+ with a special kernel/glibc patch. > // For reference, please, see IEEE Std 1003.1-2004: > // http://www.unix.org/single_unix_specification > > jlong os::Linux::thread_cpu_time(clockid_t clockid) { > > > Since we may call this method with a clockid_t that will only resolve user time this comment may be confusing. Moreover, I don't think we need to keep the comment here when POSIX compliant clock are implemented. Seems fine and trivial. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28777#pullrequestreview-3569962594 From jpai at openjdk.org Fri Dec 12 05:32:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Dec 2025 05:32:31 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option Message-ID: Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. ------------- Commit messages: - replace deprecated -verify with -Xverify:all Changes: https://git.openjdk.org/jdk/pull/28780/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28780&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373561 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28780/head:pull/28780 PR: https://git.openjdk.org/jdk/pull/28780 From jsjolen at openjdk.org Fri Dec 12 10:33:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 12 Dec 2025 10:33:07 GMT Subject: RFR: 8373557: Remove stale comments after JDK-8372584 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 22:03:54 GMT, Jonas Norlinder wrote: > Hi all, > > This is a small patch to fix stale comments after removing reading /proc to get user CPU time. > > A note on the proposed removal of: > > // This is the fastest way to get thread cpu time on Linux. > // Returns cpu time (user+sys) for any thread, not only for current. > // POSIX compliant clocks are implemented in the kernels 2.6.16+. > // It might work on 2.6.10+ with a special kernel/glibc patch. > // For reference, please, see IEEE Std 1003.1-2004: > // http://www.unix.org/single_unix_specification > > jlong os::Linux::thread_cpu_time(clockid_t clockid) { > > > Since we may call this method with a clockid_t that will only resolve user time this comment may be confusing. Moreover, I don't think we need to keep the comment here when POSIX compliant clock are implemented. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28777#pullrequestreview-3571264751 From duke at openjdk.org Fri Dec 12 10:39:54 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Dec 2025 10:39:54 GMT Subject: RFR: 8373557: Remove stale comments after JDK-8372584 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 22:03:54 GMT, Jonas Norlinder wrote: > Hi all, > > This is a small patch to fix stale comments after removing reading /proc to get user CPU time. > > A note on the proposed removal of: > > // This is the fastest way to get thread cpu time on Linux. > // Returns cpu time (user+sys) for any thread, not only for current. > // POSIX compliant clocks are implemented in the kernels 2.6.16+. > // It might work on 2.6.10+ with a special kernel/glibc patch. > // For reference, please, see IEEE Std 1003.1-2004: > // http://www.unix.org/single_unix_specification > > jlong os::Linux::thread_cpu_time(clockid_t clockid) { > > > Since we may call this method with a clockid_t that will only resolve user time this comment may be confusing. Moreover, I don't think we need to keep the comment here when POSIX compliant clock are implemented. @JonasNorlinder Your change (at version 7b056ce8fe7c22e5d8a848c9060086aa681c1ccf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28777#issuecomment-3645922563 From sspitsyn at openjdk.org Fri Dec 12 10:56:18 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 10:56:18 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads In-Reply-To: References: Message-ID: <-Of70ssdlYqY5Ye1S7vxRo6j5w-NmxBHGpXy0wPjKu4=.ee93fbde-3e11-4644-a888-d74f845bcb7f@github.com> On Thu, 11 Dec 2025 22:03:36 GMT, Patricio Chilano Mateo wrote: >> This update fixes the following problem. The function JavaThread::java_suspend has the following assert: >> >> bool JavaThread::java_suspend(bool register_vthread_SR) { >> // Suspending a vthread transition disabler can cause deadlocks. >> assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); >> . . . >> >> This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed. >> >> A more adequate approach is to tweak the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)` >> so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > src/hotspot/share/runtime/javaThread.cpp line 1182: > >> 1180: bool JavaThread::java_suspend(bool register_vthread_SR) { >> 1181: // Suspending a vthread transition disabler can cause deadlocks. >> 1182: assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); > > So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run? You are asking right question, thanks! I've found and fixed the issue caused this and also restored the assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2613792839 From sspitsyn at openjdk.org Fri Dec 12 11:03:03 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 11:03:03 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v2] In-Reply-To: References: Message-ID: > This update fixes the following problem. The function JavaThread::java_suspend has the following assert: > > bool JavaThread::java_suspend(bool register_vthread_SR) { > // Suspending a vthread transition disabler can cause deadlocks. > assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); > . . . > > This is an over-hard requirement/invariant for threads that execute JVMTI functions (e.g. in an agent event handler). Such threads need a chance to be eventually suspended after JVMTI function completes its work and its `mountUnmountDisabler` is destructed. > > A more adequate approach is to tweak the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)` > so it could skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: restored the assert and fixed the issue caused it to fire ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/8c25f690..b51267f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Fri Dec 12 11:46:57 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 11:46:57 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 22:07:45 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: restored the assert and fixed the issue caused it to fire > > src/hotspot/share/runtime/handshake.cpp line 524: > >> 522: assert(allow_suspend || !check_async_exception, "invalid case"); >> 523: #if INCLUDE_JVMTI >> 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { > > I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation? Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes. As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2613932869 From sspitsyn at openjdk.org Fri Dec 12 11:53:58 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 11:53:58 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 07:40:08 GMT, Leonid Mesnik wrote: > However, I think the it makes a sense to add regression test that tries to suspend thread while it processing event callback. Right question, thanks. This issue came from testing of the PR https://github.com/openjdk/jdk/pull/28407 . The issue appeared on the updated test: `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest`. Initially, I wanted to move the test update to this PR but encountered one more issue which needs to be addressed separately. So, I gave up on moving the test update. > Can you please show where mounting/unmounting is disabled for jvmti events. i was unable to fines this place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3646170897 From cnorrbin at openjdk.org Fri Dec 12 11:59:33 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 11:59:33 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v3] In-Reply-To: References: Message-ID: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: split unit print ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28766/files - new: https://git.openjdk.org/jdk/pull/28766/files/e88713c7..ccb7dc48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28766/head:pull/28766 PR: https://git.openjdk.org/jdk/pull/28766 From cnorrbin at openjdk.org Fri Dec 12 11:59:33 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 11:59:33 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v2] In-Reply-To: References: Message-ID: <0aWYvTC5aWWOClfnni5LPnB9WIQ37rit67N88UP0nJk=.1beaecd8-919f-4dd3-a801-e8c7503c0abc@github.com> On Fri, 12 Dec 2025 01:38:02 GMT, David Holmes wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> cross-compile fix > > src/hotspot/os/linux/osContainer_linux.cpp line 308: > >> 306: os::snprintf_checked(value_str, longest_value, metric_fmt::fmt, value); >> 307: st->print("%s: %*s", metrics, max_length - static_cast(strlen(metrics)) - 2, value_str); // -2 for the ": " >> 308: st->print_cr(unit[0] != '\0' ? " %s" : "", unit); > > Might a format checker complain about passing `unit` in the case there is no actual format specifier provided? While this is explicitly allowed in the C standard, it could maybe cause some checker to complain. I didn't have any issues, but I went ahead and split this into two prints to be safe. > src/hotspot/os/linux/osContainer_linux.cpp line 315: > >> 313: if (res.value() != value_unlimited) { >> 314: if (res.value() >= 1024) { >> 315: print_container_metric(st, metrics, res.value() / K, "kB"); > > Pre-existing, but does this assume the value will always be a multiple of K? We either assume that it's a multiple of K, or we accept some loss in accuracy. The memory values where this function is used are often large and are specified in MB/GB, so will be evenly divisible. One could set a weird manual value, and in that case we would lose some accuracy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2613958672 PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2613953824 From cnorrbin at openjdk.org Fri Dec 12 12:03:09 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 12:03:09 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 01:37:24 GMT, David Holmes wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> cross-compile fix > > src/hotspot/os/linux/os_linux.cpp line 2450: > >> 2448: assert(i > 0, "must be"); >> 2449: if (ActiveProcessorCount > 0) { >> 2450: OSContainer::print_container_metric(st, "active_processor_count", ActiveProcessorCount, "(from -XX:ActiveProcessorCount)"); > > Is it worth still reporting the true processor count in this case? You can infer it from `cpu_cpusets_cpus` The "true" processor count previously reported is already restricted based on cgroup values. Since that becomes unused with the flag set, I think it's clearer to only report the value that is actually in use. As you said, if needed, we can infer the other original or potential CPU count from `cpu_cpusets_cpus` and `cpu_quota`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2613973981 From cnorrbin at openjdk.org Fri Dec 12 12:07:15 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 12:07:15 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v4] In-Reply-To: References: Message-ID: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: indentation fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28766/files - new: https://git.openjdk.org/jdk/pull/28766/files/ccb7dc48..3b22363c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28766&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28766/head:pull/28766 PR: https://git.openjdk.org/jdk/pull/28766 From sspitsyn at openjdk.org Fri Dec 12 12:47:20 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 12:47:20 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: On Fri, 5 Dec 2025 09:42:51 GMT, Sergey Chernyshev wrote: >> We had a private discussion with Larry on this PR and undesired dependency on the `sun.jvmstat` module. >> We got the following concerns: >> - Do we really need 3x implementations of the MacOS `tempdir` finder function? >> - Do we really need a modular dependency from `jdk.attach` to `jdk.internal.jvmstat`? >> New method `getTemporaryDirectories(int pid)` is placed into the `jdk.internal.jvmstat/macosx/classes/sun/jvmstat/PlatformSupportImpl.java`. It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. >> My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? Is it right that the `jvmstat` implementation still does not properly support root user on macOS? >> Anyway, some unification and refactoring is needed here. We could file a follow up enhancement to sort this out but also wanted to know your opinion on this. > > Hi @sspitsyn , > > Thank you for looking at this patch! > >> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions? > > The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root. > >> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. > > The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory. > >> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? > > I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux). > >> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS? > > Yes and this is what this patch was intended for. > >> * Do we really need 3x implementations of the MacOS `tempdir` finder function? > > It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to. > >> * Do we really need a modular dependency f... @sercher I have a plan to submit mach5 tiers 1-6 to be completely safe from regressions. Will approve this PR if the results are good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3646340957 From sgehwolf at openjdk.org Fri Dec 12 13:31:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 12 Dec 2025 13:31:04 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v4] In-Reply-To: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> References: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> Message-ID: On Fri, 12 Dec 2025 12:07:15 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. >> >> This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. >> >> >> Here is the container printout before: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage_in_micros: 2648091 >> memory_limit_in_bytes: 4194304 k >> memory_and_swap_limit_in_bytes: 8388608 k >> memory_soft_limit_in_bytes: unlimited >> memory_throttle_limit_in_bytes: unavailable >> memory_usage_in_bytes: 61116 k >> memory_max_usage_in_bytes: 61116 k >> rss_usage_in_bytes: 56332 k >> cache_usage_in_bytes: 1880 k >> kernel_memory_limit_in_bytes: unlimited >> kernel_memory_usage_in_bytes: 1584 k >> kernel_memory_max_usage_in_bytes: 1644 k >> maximum number of tasks: unlimited >> current number of tasks: 17 >> >> >> And here it is after: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 8 (from -XX:ActiveProcessorCount) >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage: 2648091 us >> memory_limit: 4194304 kB >> memory_and_swap_limit: 8388608 kB >> memory_soft_limit: unlimited >> memory_throttle_limit: unavailable >> memory_usage: 61116 kB >> memory_max_usage: 61116 kB >> rss_usage: 56332 kB >> cache_usage: 1880 kB >> kernel_memory_limit: unlimited >> kernel_memory_usage: 1584 kB >> kernel_memory_max_usage: ... > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > indentation fix Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28766#pullrequestreview-3571823040 From stefank at openjdk.org Fri Dec 12 14:06:38 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Dec 2025 14:06:38 GMT Subject: RFR: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 09:46:19 GMT, Stefan Karlsson wrote: >> Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review Thanks for the reviews! Tier1 testing passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28741#issuecomment-3646603805 From stefank at openjdk.org Fri Dec 12 14:06:39 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Dec 2025 14:06:39 GMT Subject: Integrated: 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:33:04 GMT, Stefan Karlsson wrote: > Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code. This pull request has now been integrated. Changeset: d854a042 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/d854a04231a437a6af36ae65780961f40f336343 Stats: 45 lines in 2 files changed: 44 ins; 0 del; 1 mod 8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled Reviewed-by: shade, iklam ------------- PR: https://git.openjdk.org/jdk/pull/28741 From mbaesken at openjdk.org Fri Dec 12 14:29:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 12 Dec 2025 14:29:24 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp Message-ID: VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . ------------- Commit messages: - JDK-8373593 Changes: https://git.openjdk.org/jdk/pull/28792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373593 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28792/head:pull/28792 PR: https://git.openjdk.org/jdk/pull/28792 From cnorrbin at openjdk.org Fri Dec 12 15:49:20 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 15:49:20 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. > > This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. > > Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. > > Testing: > - Oracle tiers 1-8 Casper Norrbin 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 branch 'master' into blocktree-intrusive - Merge branch 'master' into blocktree-intrusive - moved blocktree tree logic to intrusive rbtree ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27212/files - new: https://git.openjdk.org/jdk/pull/27212/files/b74c1e18..fd0571a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27212&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27212&range=00-01 Stats: 571881 lines in 5817 files changed: 397102 ins; 110724 del; 64055 mod Patch: https://git.openjdk.org/jdk/pull/27212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27212/head:pull/27212 PR: https://git.openjdk.org/jdk/pull/27212 From cnorrbin at openjdk.org Fri Dec 12 15:49:21 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Dec 2025 15:49:21 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:40:21 GMT, Casper Norrbin wrote: > Hi everyone, > > Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. > > This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. > > Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. > > Testing: > - Oracle tiers 1-8 I ran a few DaCapo benchmarks as a sanity check to ensure that there were no unexpected side effects from these changes. The VM.info output (expandable section below) shows that the values remain the same, as expected.
VM.info output (expandable) Output before this patch: Metaspace: Metaspace used 99301K, committed 100608K, reserved 1179648K class space used 11954K, committed 12544K, reserved 1048576K Usage: Non-class: 85.30 MB used. Class: 11.67 MB used. Both: 96.97 MB used. Virtual space: Non-class space: 128.00 MB reserved, 86.00 MB ( 67%) committed, 2 nodes. Class space: 1.00 GB reserved, 12.25 MB ( 1%) committed, 1 nodes. Both: 1.12 GB reserved, 98.25 MB ( 9%) committed. Chunk freelists: Non-Class: 10.08 MB Class: 3.83 MB Both: 13.91 MB num_allocs: 635176. num_deallocs: 6834. num_allocs_from_deallocated_blocks: 21675. num_chunks_retired: 3605. num_allocs_failed_limit: 9. num_arena_births: 1780. num_arena_deaths: 438. num_vsnodes_births: 3. num_vsnodes_deaths: 0. num_space_committed: 1572. num_space_uncommitted: 0. num_chunks_returned_to_freelist: 575. num_chunks_taken_from_freelist: 5386. num_chunk_merges: 209. num_chunk_splits: 3640. num_chunks_enlarged: 5236. num_inconsistent_stats: 0. Output after this patch: Metaspace: Metaspace used 99311K, committed 100608K, reserved 1179648K class space used 11951K, committed 12544K, reserved 1048576K Usage: Non-class: 85.31 MB used. Class: 11.67 MB used. Both: 96.98 MB used. Virtual space: Non-class space: 128.00 MB reserved, 86.00 MB ( 67%) committed, 2 nodes. Class space: 1.00 GB reserved, 12.25 MB ( 1%) committed, 1 nodes. Both: 1.12 GB reserved, 98.25 MB ( 9%) committed. Chunk freelists: Non-Class: 10.31 MB Class: 3.83 MB Both: 14.14 MB Internal statistics: num_allocs: 635534. num_deallocs: 6709. num_allocs_from_deallocated_blocks: 21265. num_chunks_retired: 3600. num_allocs_failed_limit: 9. num_arena_births: 1790. num_arena_deaths: 438. num_vsnodes_births: 3. num_vsnodes_deaths: 0. num_space_committed: 1572. num_space_uncommitted: 0. num_chunks_returned_to_freelist: 556. num_chunks_taken_from_freelist: 5391. num_chunk_merges: 213. num_chunk_splits: 3672. num_chunks_enlarged: 5268. num_inconsistent_stats: 0.
To quickly recap how the intrusive tree works: we embed an `IntrusiveNode` inside an external structure. This `IntrusiveNode` is a lightweight data class containing three pointers, used to connect elements in a tree structure. The user must provide comparison functions that operate on the external data, since the intrusive tree neither manages nor allocates memory itself. When a node is added or removed, only the pointers within `IntrusiveNode` are updated. By swapping the `BlockTree` parent/child pointers to use an `IntrusiveNode`, we are effectively maintaining the same tree structure, just managed differently. The process for inserts/removals remain similar, but we now also balance the tree, which only involves shuffling some pointers. Importantly, no additional memory allocation is done: all relevant data still resides in the outside class (`BlockTree::Node` in this case). The main difference is that pointer management is handled by a separate class, rather than maintaining internal tree logic within `BlockTree`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3647082153 From serb at openjdk.org Fri Dec 12 16:43:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Dec 2025 16:43:51 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3572713212 From iklam at openjdk.org Fri Dec 12 16:48:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Dec 2025 16:48:25 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod Message-ID: I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 This REF improves these functions by: - Sorting the names of classes and methods - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work - Print the C++/Java objects that represent classes and methods. ------------- Commit messages: - 8373615: Improve HotSpot debug functions findclass() and findmethod Changes: https://git.openjdk.org/jdk/pull/28796/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373615 Stats: 100 lines in 2 files changed: 90 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28796/head:pull/28796 PR: https://git.openjdk.org/jdk/pull/28796 From iklam at openjdk.org Fri Dec 12 16:48:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Dec 2025 16:48:25 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 16:40:24 GMT, Ioi Lam wrote: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Example 1: (gdb) p findclass("*.ArrayList", 0x20) "Executing findclass" flags (bitmask): 0x01 - print names of methods 0x02 - print bytecodes 0x04 - print the address of bytecodes 0x08 - print info for invokedynamic 0x10 - print info for invokehandle 0x20 - print details of the C++ and Java objects that represent classes 0x40 - print details of the C++ objects that represent methods [ 0] 0x000000005527ddb8 class: java/util/ArrayList mirror: 0x00000007ff854410 loader data: 0x00007ffff010cf30 of 'bootstrap' InstanceKlass: java.util.ArrayList {0x000000005527ddb8} - instance size: 3 - klass size: 205 - access: public synchronized - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods defined_by_boot_loader has_localvariable_table has_miranda_methods - state: fully_initialized - name: 'java/util/ArrayList' - super: 'java/util/AbstractList' - sub: - arrays: null - methods: Array(0x000000005591e538) - method ordering: Array(0x000000005577a0d8) - default_methods: Array(0x000000005591f438) - default vtable indices: Array(0x000000005577a1f0) - local interfaces: Array(0x000000005591f468) - trans. interfaces: Array(0x000000005591f490) - secondary supers: Array(0x0000000055918860) - hash_slot: 26 - secondary bitmap: 0x4000000100220203 - constants: constant pool [516] {0x000000005591b918} for 'java/util/ArrayList' cache=0x0000000055282018 - class loader data: loader data: 0x00007ffff010cf30 of 'bootstrap' - source file: 'ArrayList.java' - generic signature: 'Ljava/util/AbstractList;Ljava/util/List;Ljava/util/RandomAccess;Ljava/lang/Cloneable;Ljava/io/Serializable;' - inner classes: Array(0x0000000055779f68) - nest members: Array(0x000000005577a238) - permitted subclasses: Array(0x00000000557590b0) - java mirror: a 'java/lang/Class'{0x00000007ff854410} = 'java/util/ArrayList' - vtable length 55 (start addr: 0x000000005527df98) - itable length 89 (start addr: 0x000000005527e150) - ---- static fields (3 words): - private static final 'serialVersionUID' 'J' @128 - private static final 'DEFAULT_CAPACITY' 'I' @136 - private static final 'EMPTY_ELEMENTDATA' '[Ljava/lang/Object;' @120 - private static final 'DEFAULTCAPACITY_EMPTY_ELEMENTDATA' '[Ljava/lang/Object;' @124 - ---- non-static fields (3 words): - protected transient 'modCount' 'I' @12 - private 'size' 'I' @16 - transient 'elementData' '[Ljava/lang/Object;' @20 - non-static oop maps (1 entries): 20-20 Java mirror oop for java/util/ArrayList: java.lang.Class {0x00000007ff854410} - klass: 'java/lang/Class' - flags: - ---- fields (total size 18 words): - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) - injected 'klass' 'J' @16 1428676024 (0x000000005527ddb8) - injected 'array_klass' 'J' @24 0 (0x0000000000000000) - injected 'oop_size' 'I' @32 18 (0x00000012) - injected 'static_oop_field_count' 'I' @36 2 (0x00000002) - private final transient 'modifiers' 'C' @40 1 (0x0001) - private final transient 'classFileAccessFlags' 'C' @42 ! 33 (0x0021) - private final transient 'primitive' 'Z' @44 false (0x00) - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @48 null (0x00000000) - private transient 'name' 'Ljava/lang/String;' @52 null (0x00000000) - private transient 'module' 'Ljava/lang/Module;' @56 a 'java/lang/Module'{0x00000007ff8205a0} (0xfff040b4) - private final 'classLoader' 'Ljava/lang/ClassLoader;' @60 null (0x00000000) - private transient 'classData' 'Ljava/lang/Object;' @64 null (0x00000000) - private transient 'signers' '[Ljava/lang/Object;' @68 null (0x00000000) - private transient 'packageName' 'Ljava/lang/String;' @72 null (0x00000000) - private final transient 'componentType' 'Ljava/lang/Class;' @76 null (0x00000000) - private final transient 'protectionDomain' 'Ljava/security/ProtectionDomain;' @80 null (0x00000000) - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @84 null (0x00000000) - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @88 null (0x00000000) - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @92 null (0x00000000) - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @96 null (0x00000000) - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @100 null (0x00000000) - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @104 null (0x00000000) - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @108 null (0x00000000) - injected 'source_file' 'Ljava/lang/Object;' @112 null (0x00000000) - injected '' 'Ljava/lang/Object;' @116 null (0x00000000) - signature: Ljava/util/ArrayList; - ---- static fields (2): - private static final 'serialVersionUID' 'J' @128 8683452581122892189 (0x7881d21d99c7619d) - private static final 'DEFAULT_CAPACITY' 'I' @136 10 (0x0000000a) - private static final 'EMPTY_ELEMENTDATA' '[Ljava/lang/Object;' @120 a 'java/lang/Object'[0] {0x000000043800f188} (0x87001e31) - private static final 'DEFAULTCAPACITY_EMPTY_ELEMENTDATA' '[Ljava/lang/Object;' @124 a 'java/lang/Object'[0] {0x000000043800f198} (0x87001e33) Example 2 (sorting of methods): (gdb) p findmethod("*.ArrayList", "*remove*", 0x0) "Executing findmethod" flags (bitmask): 0x01 - print names of methods 0x02 - print bytecodes 0x04 - print the address of bytecodes 0x08 - print info for invokedynamic 0x10 - print info for invokehandle 0x20 - print details of the C++ and Java objects that represent classes 0x40 - print details of the C++ objects that represent methods [ 0] 0x000000009e27ddb8 class: java/util/ArrayList mirror: 0x00000007ff854410 loader data: 0x00007ffff010cef0 of 'bootstrap' 0x000000009e283470 method batchRemove : (Ljava/util/Collection;ZII)Z 0x000000009e283a20 method fastRemove : ([Ljava/lang/Object;I)V 0x000000009e282910 method remove : (I)Ljava/lang/Object; 0x000000009e282280 method remove : (Ljava/lang/Object;)Z 0x000000009e2826e0 method removeAll : (Ljava/util/Collection;)Z 0x000000009e2830f0 method removeFirst : ()Ljava/lang/Object; 0x000000009e2828a0 method removeIf : (Ljava/util/function/Predicate;)Z 0x000000009e2834e0 method removeIf : (Ljava/util/function/Predicate;II)Z 0x000000009e282ec0 method removeLast : ()Ljava/lang/Object; 0x000000009e282c90 method removeRange : (II)V ------------- PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3647317868 PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3647322243 From pchilanomate at openjdk.org Fri Dec 12 17:05:02 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Dec 2025 17:05:02 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v2] In-Reply-To: References: Message-ID: <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com> On Fri, 12 Dec 2025 11:44:28 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/handshake.cpp line 524: >> >>> 522: assert(allow_suspend || !check_async_exception, "invalid case"); >>> 523: #if INCLUDE_JVMTI >>> 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { >> >> I see we need this because a thread could be suspended outside a disable operation (e.g. waiting in `disable_transition_for_one()`) but only process the suspend once inside it. Looking at the places where we use `MountUnmountDisabler`, the one where I can clearly see this could happen is `JvmtiEnv::InterruptThread` because of the upcall to Java. Did you encounter any other places where we could process suspend requests inside a disabling operation? > > Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes. > As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario. Right, I was just curious whether you ran into this issue or only found it by code inspection. But I'm guessing you found disablers processing `ThreadSelfSuspensionHandshakeClosure` handshakes because of the other issue in `enable_transition_for_all()`, and that accidentally led you to consider this other potential case where a thread is suspended before entering a `MountUnmountDisabler` scope but processes the async handshake inside it? Thanks for updating the PR description. >> src/hotspot/share/runtime/javaThread.cpp line 1182: >> >>> 1180: bool JavaThread::java_suspend(bool register_vthread_SR) { >>> 1181: // Suspending a vthread transition disabler can cause deadlocks. >>> 1182: assert(!is_vthread_transition_disabler(), "no suspend allowed for vthread transition disablers"); >> >> So except for self-suspend, how can we hit this assert if we use an exclusive disabler? And if we remove it and allow a disabler to self-suspend, wouldn't we deadlock since the resumer would be unable to run? > > You are asking right question, thanks! > I've found and fixed the issue caused this and also restored the assert. > I will also need to update the PR description to reflect this change. Thanks! Now it makes sense why we were hitting this assert. Since that was introduced in 8364343 I think we should separate that fix and backport it to 26. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2614963770 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2614961974 From prr at openjdk.org Fri Dec 12 18:04:54 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Dec 2025 18:04:54 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3573006281 From matsaave at openjdk.org Fri Dec 12 19:37:52 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 12 Dec 2025 19:37:52 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 16:40:24 GMT, Ioi Lam wrote: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Looks good, thanks for updating this tool! I have one nit below but otherwise this looks great src/hotspot/share/classfile/classPrinter.cpp line 111: > 109: } > 110: > 111: static int compare_klasses_alphadetically(InstanceKlass** a, InstanceKlass** b) { Typo here: alphadetically -> alphabetically You might even want to use alphanumerically or even just "by name" as klasses can have numbers or other characters in their name. ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28796#pullrequestreview-3572745279 PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2614920850 From asmehra at openjdk.org Fri Dec 12 20:38:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 12 Dec 2025 20:38:52 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 16:40:24 GMT, Ioi Lam wrote: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. src/hotspot/share/classfile/classPrinter.cpp line 96: > 94: return; > 95: } > 96: _klasses.append(InstanceKlass::cast(k)); It doesn't really matter much as these are for debugging, but it would be more efficient if filtering based on `_class_name_pattern` is done here before adding the class to the array. src/hotspot/share/classfile/classPrinter.cpp line 164: > 162: oop mirror = ik->java_mirror(); > 163: if (mirror != nullptr) { > 164: _st->print("\nJava mirror oop for %s: ", ik->name()->as_C_string()); Indentation is off src/hotspot/share/classfile/classPrinter.hpp line 56: > 54: PRINT_METHOD_HANDLE = 1 << 4, // extra information for invokehandle > 55: PRINT_CLASS_DETAILS = 1 << 5, // print details of the C++ and Java objects that represent classes > 56: PRINT_METHOD_DETAILS = 1 << 6, // print details of the C++ that represent methods Suggestion: PRINT_METHOD_DETAILS = 1 << 6, // print details of the C++ objects that represent methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615512327 PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615512117 PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615512521 From sspitsyn at openjdk.org Fri Dec 12 21:10:04 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 21:10:04 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v10] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:34:37 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 possibility 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 t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright header The fix looks good - approved. Thank you for your patience! Larry is also okay with your fix but does not have status yet to formally approve. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3573605043 From sspitsyn at openjdk.org Fri Dec 12 21:13:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 21:13:55 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v2] In-Reply-To: <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com> References: <4sAW1NS49QAquz1NjdlSGlteb2ofw-wgH5xbqhzIcrw=.b97e3786-b6e2-479e-a47d-077c5d9ab4ad@github.com> Message-ID: On Fri, 12 Dec 2025 17:02:36 GMT, Patricio Chilano Mateo wrote: >> Not sure, I correctly understand your question. Are you asking about possible suspend points inside a `MountUnmountDisabler` scope? It is used for implementation of the JVMTI functions which have a deal with threads. They normally have suspend points (points where an asynchronous suspend operation can be picked and executed by the target thread itself with `HandshakeState::process_by_self()`), for instance, because they use handshakes. >> As I understand, the `ThreadSelfSuspensionHandshakeClosure` is an `AsyncHandshakeClosure`. As the suspending operation is asynchronous, the suspending thread can finish its suspending work and get out of the exclusive operation scope. Then the target thread can enter its own `MountUnmountDisabler` scope and get suspended there. The tweak above is to disallow such a scenario. > > Right, I was just curious whether you ran into this issue or only found it by code inspection. But I'm guessing you found disablers processing `ThreadSelfSuspensionHandshakeClosure` handshakes because of the other issue in `enable_transition_for_all()`, and that accidentally led you to consider this other potential case where a thread is suspended before entering a `MountUnmountDisabler` scope but processes the async handshake inside it? Thanks for updating the PR description. This is right, thanks! >> You are asking right question, thanks! >> I've found and fixed the issue caused this and also restored the assert. >> I will also need to update the PR description to reflect this change. > > Thanks! Now it makes sense why we were hitting this assert. Since that was introduced in 8364343 I think we should separate that fix and backport it to 26. Thanks. Okay, will do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2615590699 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2615586743 From sspitsyn at openjdk.org Fri Dec 12 21:56:31 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Dec 2025 21:56:31 GMT Subject: RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers Message-ID: This is a 1-liner fix of a regression. The issue was discovered after merge with main line of this PR: https://github.com/openjdk/jdk/pull/28407 . It will need to be back ported to 26 as well. Testing: - TBD: This was already tested in another PR repo but will submit mach5 tiers 1-3 to be completely safe. ------------- Commit messages: - 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers Changes: https://git.openjdk.org/jdk/pull/28805/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28805&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373627 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28805/head:pull/28805 PR: https://git.openjdk.org/jdk/pull/28805 From duke at openjdk.org Fri Dec 12 23:04:29 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Fri, 12 Dec 2025 23:04:29 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v3] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Add HotCodeGrouperMoveFunction test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/ce1c685f..3697718f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=01-02 Stats: 91 lines in 1 file changed: 91 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From duke at openjdk.org Fri Dec 12 23:04:31 2025 From: duke at openjdk.org (Chad Rakoczy) Date: Fri, 12 Dec 2025 23:04:31 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:08:19 GMT, Andrew Haley wrote: > Thanks. > > I need to stress test this code, especially by moving nmethods as much as possible while many threads are executing. Is one of the stress tests here suitable for that? I created `test/hotspot/jtreg/compiler/hotcodegrouper/StressHotCodeGrouper.java`. It generates many nmethods and calls them while the grouper continuously runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3648439296 From iklam at openjdk.org Fri Dec 12 23:26:27 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Dec 2025 23:26:27 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - sort includes - @ashu-mehra and @matias9927 review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28796/files - new: https://git.openjdk.org/jdk/pull/28796/files/14e1b9dc..5b2504ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=00-01 Stats: 57 lines in 2 files changed: 6 ins; 5 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/28796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28796/head:pull/28796 PR: https://git.openjdk.org/jdk/pull/28796 From iklam at openjdk.org Fri Dec 12 23:26:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Dec 2025 23:26:30 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:36:18 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - sort includes >> - @ashu-mehra and @matias9927 review comments > > src/hotspot/share/classfile/classPrinter.cpp line 96: > >> 94: return; >> 95: } >> 96: _klasses.append(InstanceKlass::cast(k)); > > It doesn't really matter much as these are for debugging, but it would be more efficient if filtering based on `_class_name_pattern` is done here before adding the class to the array. Fixed > src/hotspot/share/classfile/classPrinter.cpp line 164: > >> 162: oop mirror = ik->java_mirror(); >> 163: if (mirror != nullptr) { >> 164: _st->print("\nJava mirror oop for %s: ", ik->name()->as_C_string()); > > Indentation is off Fixed > src/hotspot/share/classfile/classPrinter.hpp line 56: > >> 54: PRINT_METHOD_HANDLE = 1 << 4, // extra information for invokehandle >> 55: PRINT_CLASS_DETAILS = 1 << 5, // print details of the C++ and Java objects that represent classes >> 56: PRINT_METHOD_DETAILS = 1 << 6, // print details of the C++ that represent methods > > Suggestion: > > PRINT_METHOD_DETAILS = 1 << 6, // print details of the C++ objects that represent methods Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615831157 PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615831190 PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615831136 From iklam at openjdk.org Fri Dec 12 23:26:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Dec 2025 23:26:30 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 16:49:08 GMT, Matias Saavedra Silva wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - sort includes >> - @ashu-mehra and @matias9927 review comments > > src/hotspot/share/classfile/classPrinter.cpp line 111: > >> 109: } >> 110: >> 111: static int compare_klasses_alphadetically(InstanceKlass** a, InstanceKlass** b) { > > Typo here: > alphadetically -> alphabetically > > You might even want to use alphanumerically or even just "by name" as klasses can have numbers or other characters in their name. I fixed the typo. There's existing code that uses "alphabetically", so I will stick with that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2615830844 From vlivanov at openjdk.org Sat Dec 13 01:00:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 13 Dec 2025 01:00:52 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> Message-ID: On Thu, 11 Dec 2025 07:19:24 GMT, Emanuel Peter wrote: >> It's a test on C2 IR. What's the point in running it w/o C2? > > You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary. I don't argue that there's always a chance to catch a bug, but unit tests on C2 IR are mostly trivial, so the actual chance to spot a unique problem is quite low. And the price is execution time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2615925589 From asmehra at openjdk.org Sat Dec 13 01:58:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Sat, 13 Dec 2025 01:58:52 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:26:27 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - sort includes > - @ashu-mehra and @matias9927 review comments Marked as reviewed by asmehra (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28796#pullrequestreview-3574078647 From asmehra at openjdk.org Sat Dec 13 02:02:51 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Sat, 13 Dec 2025 02:02:51 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:26:27 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - sort includes > - @ashu-mehra and @matias9927 review comments lgtm, although there are some test failures likely related to these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3648737875 From jrose at openjdk.org Sat Dec 13 02:13:52 2025 From: jrose at openjdk.org (John R Rose) Date: Sat, 13 Dec 2025 02:13:52 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: Message-ID: <_j4OsghE4w1f2L8K6QZOEGozC9-HrFDq1Mhn871B2_Q=.a32b5068-6fac-491a-8861-0d17526dbada@github.com> On Tue, 2 Dec 2025 23:25:29 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Typo src/hotspot/share/opto/library_call.cpp line 4786: > 4784: if (t != nullptr && t->const_oop() != nullptr) { > 4785: jint hash = t->const_oop()->identity_hash_or_no_hash(); > 4786: if (hash != 0) { Don?t compare against zero, please, but against no_hash. (Any other stray zeroes?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2615991597 From vlivanov at openjdk.org Sat Dec 13 02:35:58 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 13 Dec 2025 02:35:58 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant In-Reply-To: References: Message-ID: <03LS79mJXIs41UMm3gio_urrsHSZP7dPw81NEfcag88=.c6542fe1-f94a-4e80-8393-7cd235136e34@github.com> On Tue, 2 Dec 2025 23:08:44 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > I tried to come up with an example where the buggy code from Vladimir would inline to identityHashCode when the right call would be virtual - couldn't construct such a case unfortunately :( > > I think we can deal with IGVN later, as this involves creating new macro node and other infrastructure support. @liach please, incorporate latest version from https://github.com/openjdk/jdk/compare/master...iwanowww:jdk:c2.identity_hash ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3648776804 From iklam at openjdk.org Sat Dec 13 06:24:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 13 Dec 2025 06:24:32 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v3] In-Reply-To: References: Message-ID: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed test and added more test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28796/files - new: https://git.openjdk.org/jdk/pull/28796/files/5b2504ad..4d40f01e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=01-02 Stats: 45 lines in 1 file changed: 37 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28796/head:pull/28796 PR: https://git.openjdk.org/jdk/pull/28796 From ayang at openjdk.org Sun Dec 14 05:21:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 14 Dec 2025 05:21:50 GMT Subject: RFR: 8373522: Remove expired flags in JDK 27 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 21:31:07 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 > - the Java man page is trivially updated > > Thanks `LockingMode` is still referenced in `phaseX.cpp`, just fyi. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28776#pullrequestreview-3574777031 From dholmes at openjdk.org Sun Dec 14 20:48:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 14 Dec 2025 20:48:04 GMT Subject: Integrated: 8373522: Remove expired flags in JDK 27 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 21:31:07 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 > - the Java man page is trivially updated > > Thanks This pull request has now been integrated. Changeset: d03e7cb8 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/d03e7cb87ae04c1d32559b4a49d71d32f9d616a8 Stats: 28 lines in 2 files changed: 2 ins; 26 del; 0 mod 8373522: Remove expired flags in JDK 27 Reviewed-by: kvn, ayang ------------- PR: https://git.openjdk.org/jdk/pull/28776 From dholmes at openjdk.org Sun Dec 14 20:48:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 14 Dec 2025 20:48:02 GMT Subject: RFR: 8373522: Remove expired flags in JDK 27 In-Reply-To: References: Message-ID: <4yJYx_jLDjJ3UbhzzOjb9ueD87Rs9OGFQcv9uVxuMpc=.410f7ea3-e9ba-423b-a044-971f4360697e@github.com> On Sun, 14 Dec 2025 05:19:04 GMT, Albert Mingkun Yang wrote: > `LockingMode` is still referenced in `phaseX.cpp`, just fyi. Yes, as I recall that was intentional. Thanks for the review @albertnetymk ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28776#issuecomment-3652053019 From kbarrett at openjdk.org Mon Dec 15 01:39:44 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Dec 2025 01:39:44 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable [v2] In-Reply-To: References: Message-ID: > Please review this change to Atomic to meet the requirements for constant > initialization in cases where the value type provides the requisite support. > This ensures that in such cases dynamic initialization won't even be > considered a possibility when initialized with constant arguments. > > Testing: mach5 tier1 Kim Barrett 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 constinit-atomic - constexpr Atomc ctors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28711/files - new: https://git.openjdk.org/jdk/pull/28711/files/e3f6f8a1..dec499b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28711&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28711&range=00-01 Stats: 18007 lines in 308 files changed: 11474 ins; 4268 del; 2265 mod Patch: https://git.openjdk.org/jdk/pull/28711.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28711/head:pull/28711 PR: https://git.openjdk.org/jdk/pull/28711 From syan at openjdk.org Mon Dec 15 02:35:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 02:35:51 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. Looking for 2rd reviewer, since this PR touch files in hotspot directory? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3652648703 From dholmes at openjdk.org Mon Dec 15 04:21:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 04:21:27 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical Message-ID: As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. There is no regression test as this has only been seen in long running stress tests. Testing: -tiers 1-6 ------------- Commit messages: - 8369515 Changes: https://git.openjdk.org/jdk/pull/28779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369515 Stats: 31 lines in 2 files changed: 27 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779 PR: https://git.openjdk.org/jdk/pull/28779 From dholmes at openjdk.org Mon Dec 15 04:22:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 04:22:06 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt Message-ID: In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). Testing: - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug - tiers 1-3 sanity Thanks ------------- Commit messages: - 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt Changes: https://git.openjdk.org/jdk/pull/28817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372988 Stats: 12 lines in 2 files changed: 5 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28817/head:pull/28817 PR: https://git.openjdk.org/jdk/pull/28817 From dholmes at openjdk.org Mon Dec 15 05:27:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 05:27:54 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v4] In-Reply-To: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> References: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> Message-ID: On Fri, 12 Dec 2025 12:07:15 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. >> >> This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. >> >> >> Here is the container printout before: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage_in_micros: 2648091 >> memory_limit_in_bytes: 4194304 k >> memory_and_swap_limit_in_bytes: 8388608 k >> memory_soft_limit_in_bytes: unlimited >> memory_throttle_limit_in_bytes: unavailable >> memory_usage_in_bytes: 61116 k >> memory_max_usage_in_bytes: 61116 k >> rss_usage_in_bytes: 56332 k >> cache_usage_in_bytes: 1880 k >> kernel_memory_limit_in_bytes: unlimited >> kernel_memory_usage_in_bytes: 1584 k >> kernel_memory_max_usage_in_bytes: 1644 k >> maximum number of tasks: unlimited >> current number of tasks: 17 >> >> >> And here it is after: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 8 (from -XX:ActiveProcessorCount) >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage: 2648091 us >> memory_limit: 4194304 kB >> memory_and_swap_limit: 8388608 kB >> memory_soft_limit: unlimited >> memory_throttle_limit: unavailable >> memory_usage: 61116 kB >> memory_max_usage: 61116 kB >> rss_usage: 56332 kB >> cache_usage: 1880 kB >> kernel_memory_limit: unlimited >> kernel_memory_usage: 1584 kB >> kernel_memory_max_usage: ... > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > indentation fix Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28766#pullrequestreview-3576423146 From dholmes at openjdk.org Mon Dec 15 05:38:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 05:38:52 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. I'm unclear what you mean by some of the tests not working - are you saying those tests did not check the value of RETAIN_IMAGE_AFTER_TEST? Or that they never had it passed in - in which case why not? Where does it come from. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: > 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { > 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); > 255: } Pre-existing but indent is too big ------------- PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576429184 PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617997460 From dholmes at openjdk.org Mon Dec 15 05:38:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 05:38:53 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Mon, 15 Dec 2025 05:28:03 GMT, David Holmes wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: > >> 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { >> 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); >> 255: } > > Pre-existing but indent is too big You also need to document the fact the property is used to make this a no-op. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617999664 From dholmes at openjdk.org Mon Dec 15 06:15:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 06:15:57 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. LGTM ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3576551694 From syan at openjdk.org Mon Dec 15 06:15:58 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:15:58 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Mon, 15 Dec 2025 05:35:45 GMT, David Holmes wrote: > RETAIN_IMAGE_AFTER_TEST Some tests did not check the value of the RETAIN_IMAGE_AFTER_TEST variable, causing the docker image to be deleted at the end of the test run even if the -DRETAIN_IMAGE_AFTER_TEST=true option was used when running those tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3653534316 From jnorlinder at openjdk.org Mon Dec 15 06:16:09 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 15 Dec 2025 06:16:09 GMT Subject: Integrated: 8373557: Remove stale comments after JDK-8372584 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 22:03:54 GMT, Jonas Norlinder wrote: > Hi all, > > This is a small patch to fix stale comments after removing reading /proc to get user CPU time. > > A note on the proposed removal of: > > // This is the fastest way to get thread cpu time on Linux. > // Returns cpu time (user+sys) for any thread, not only for current. > // POSIX compliant clocks are implemented in the kernels 2.6.16+. > // It might work on 2.6.10+ with a special kernel/glibc patch. > // For reference, please, see IEEE Std 1003.1-2004: > // http://www.unix.org/single_unix_specification > > jlong os::Linux::thread_cpu_time(clockid_t clockid) { > > > Since we may call this method with a clockid_t that will only resolve user time this comment may be confusing. Moreover, I don't think we need to keep the comment here when POSIX compliant clock are implemented. This pull request has now been integrated. Changeset: dc1b0b5f Author: Jonas Norlinder Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/dc1b0b5f81b6c3de85a0234d0315370b6413c077 Stats: 11 lines in 2 files changed: 0 ins; 10 del; 1 mod 8373557: Remove stale comments after JDK-8372584 Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/28777 From syan at openjdk.org Mon Dec 15 06:18:35 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:18:35 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove extra ident ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28208/files - new: https://git.openjdk.org/jdk/pull/28208/files/75356d0e..5e39c8f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208 PR: https://git.openjdk.org/jdk/pull/28208 From syan at openjdk.org Mon Dec 15 06:25:43 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:25:43 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. SendaoYan 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 branch 'openjdk:master' into jbs8371503 - Remove extra ident - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28208/files - new: https://git.openjdk.org/jdk/pull/28208/files/5e39c8f3..0bfbe8ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=01-02 Stats: 301873 lines in 2852 files changed: 201864 ins; 58740 del; 41269 mod Patch: https://git.openjdk.org/jdk/pull/28208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208 PR: https://git.openjdk.org/jdk/pull/28208 From syan at openjdk.org Mon Dec 15 06:31:52 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:31:52 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <_TW1mSrJRHz9EYzpiDbjXIPk4IexJ1bX53I8U0s_Ec8=.63403b1b-e590-428f-abb7-8e20861f307d@github.com> On Mon, 15 Dec 2025 05:29:16 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: >> >>> 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { >>> 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); >>> 255: } >> >> Pre-existing but indent is too big > > You also need to document the fact the property is used to make this a no-op. > Pre-existing but indent is too big Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2618130670 From dholmes at openjdk.org Mon Dec 15 06:47:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 06:47:59 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <6vq4NQJDnsQ_06T_1Tqfx8MmiNv2dAWYIet1OgDT1X8=.5789459a-ec8b-4bb0-8ab1-76120b28becd@github.com> On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > SendaoYan 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 branch 'openjdk:master' into jbs8371503 > - Remove extra ident > - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Thanks - now it makes sense to me. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576654982 From lmesnik at openjdk.org Mon Dec 15 08:00:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 15 Dec 2025 08:00:58 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > SendaoYan 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 branch 'openjdk:master' into jbs8371503 > - Remove extra ident > - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576911752 From stefank at openjdk.org Mon Dec 15 08:24:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 15 Dec 2025 08:24:52 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 01:39:44 GMT, Kim Barrett wrote: >> Please review this change to Atomic to meet the requirements for constant >> initialization in cases where the value type provides the requisite support. >> This ensures that in such cases dynamic initialization won't even be >> considered a possibility when initialized with constant arguments. >> >> Testing: mach5 tier1 > > Kim Barrett 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 constinit-atomic > - constexpr Atomc ctors Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28711#pullrequestreview-3576982345 From fbredberg at openjdk.org Mon Dec 15 08:58:13 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 15 Dec 2025 08:58:13 GMT Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file [v2] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:17:27 GMT, Fredrik Bredberg wrote: >> The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 >> >> By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. >> >> Passes tier1-7 without any problems that can be traced to this PR. > > Fredrik Bredberg 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 branch 'master' into 8371347_object_monitor_table_in_separate_file > - Update after review > - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file > - 8371347: Move the ObjectMonitorTable to a separate new file Thanks for the reviews. Now let's... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28565#issuecomment-3654491291 From fbredberg at openjdk.org Mon Dec 15 08:58:15 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 15 Dec 2025 08:58:15 GMT Subject: Integrated: 8371347: Move the ObjectMonitorTable to a separate new file In-Reply-To: References: Message-ID: <_RIOOyYeBsoqf1JySXcZbbwQg0ehZff7T4TDl-6UVs4=.01d6fe6d-b994-4643-baec-ad6188d93298@github.com> On Sat, 29 Nov 2025 11:21:52 GMT, Fredrik Bredberg wrote: > The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893 > > By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean. > > Passes tier1-7 without any problems that can be traced to this PR. This pull request has now been integrated. Changeset: ad6611a9 Author: Fredrik Bredberg URL: https://git.openjdk.org/jdk/commit/ad6611a9a3fd5f9cf8b73ce3ccf976187e344654 Stats: 671 lines in 3 files changed: 386 ins; 285 del; 0 mod 8371347: Move the ObjectMonitorTable to a separate new file Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/28565 From cnorrbin at openjdk.org Mon Dec 15 10:23:42 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 15 Dec 2025 10:23:42 GMT Subject: RFR: 8371408: [Linux] VM.info output for container information is confusing [v4] In-Reply-To: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> References: <5M2TCasuAU9Ej99AWN_n6r8VcJzkxJAqWkb1PjJySgk=.95dced67-0695-4c51-ad06-bda6b4b5bb4a@github.com> Message-ID: <6kFw48uKewEVXzJBb67PgGcxFdYG75cas2hachW1mzU=.4deb2891-f39e-41cb-bc03-0e46a8a295fd@github.com> On Fri, 12 Dec 2025 12:07:15 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. >> >> This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. >> >> >> Here is the container printout before: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage_in_micros: 2648091 >> memory_limit_in_bytes: 4194304 k >> memory_and_swap_limit_in_bytes: 8388608 k >> memory_soft_limit_in_bytes: unlimited >> memory_throttle_limit_in_bytes: unavailable >> memory_usage_in_bytes: 61116 k >> memory_max_usage_in_bytes: 61116 k >> rss_usage_in_bytes: 56332 k >> cache_usage_in_bytes: 1880 k >> kernel_memory_limit_in_bytes: unlimited >> kernel_memory_usage_in_bytes: 1584 k >> kernel_memory_max_usage_in_bytes: 1644 k >> maximum number of tasks: unlimited >> current number of tasks: 17 >> >> >> And here it is after: >> >> container (cgroup) information: >> container_type: cgroupv1 >> cpu_cpuset_cpus: 0-15 >> cpu_memory_nodes: 0-1 >> active_processor_count: 8 (from -XX:ActiveProcessorCount) >> cpu_quota: 1600000 >> cpu_period: 100000 >> cpu_shares: no shares >> cpu_usage: 2648091 us >> memory_limit: 4194304 kB >> memory_and_swap_limit: 8388608 kB >> memory_soft_limit: unlimited >> memory_throttle_limit: unavailable >> memory_usage: 61116 kB >> memory_max_usage: 61116 kB >> rss_usage: 56332 kB >> cache_usage: 1880 kB >> kernel_memory_limit: unlimited >> kernel_memory_usage: 1584 kB >> kernel_memory_max_usage: ... > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > indentation fix Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28766#issuecomment-3654870485 From rrich at openjdk.org Mon Dec 15 10:26:08 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 15 Dec 2025 10:26:08 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 Thanks for providing a fix for the issue David. I've scheduled some local testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3654877794 From cnorrbin at openjdk.org Mon Dec 15 10:26:24 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 15 Dec 2025 10:26:24 GMT Subject: Integrated: 8371408: [Linux] VM.info output for container information is confusing In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 12:02:22 GMT, Casper Norrbin wrote: > Hi everyone, > > The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix. > > This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout. > > > Here is the container printout before: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8 > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage_in_micros: 2648091 > memory_limit_in_bytes: 4194304 k > memory_and_swap_limit_in_bytes: 8388608 k > memory_soft_limit_in_bytes: unlimited > memory_throttle_limit_in_bytes: unavailable > memory_usage_in_bytes: 61116 k > memory_max_usage_in_bytes: 61116 k > rss_usage_in_bytes: 56332 k > cache_usage_in_bytes: 1880 k > kernel_memory_limit_in_bytes: unlimited > kernel_memory_usage_in_bytes: 1584 k > kernel_memory_max_usage_in_bytes: 1644 k > maximum number of tasks: unlimited > current number of tasks: 17 > > > And here it is after: > > container (cgroup) information: > container_type: cgroupv1 > cpu_cpuset_cpus: 0-15 > cpu_memory_nodes: 0-1 > active_processor_count: 8 (from -XX:ActiveProcessorCount) > cpu_quota: 1600000 > cpu_period: 100000 > cpu_shares: no shares > cpu_usage: 2648091 us > memory_limit: 4194304 kB > memory_and_swap_limit: 8388608 kB > memory_soft_limit: unlimited > memory_throttle_limit: unavailable > memory_usage: 61116 kB > memory_max_usage: 61116 kB > rss_usage: 56332 kB > cache_usage: 1880 kB > kernel_memory_limit: unlimited > kernel_memory_usage: 1584 kB > kernel_memory_max_usage: 1644 kB > maximum number of tasks: unlimited > current number of tasks: 17 > > > To accomplish ... This pull request has now been integrated. Changeset: 629bf20f Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/629bf20f59f98a735ca22018ad00c93580aff5f3 Stats: 115 lines in 10 files changed: 38 ins; 20 del; 57 mod 8371408: [Linux] VM.info output for container information is confusing Reviewed-by: sgehwolf, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28766 From schernyshev at openjdk.org Mon Dec 15 11:04:42 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 15 Dec 2025 11:04:42 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v8] In-Reply-To: References: <7hs5qoZhrBxXH6kJ1uowTEWZEFU_5Bt3V14p5ATcoeg=.cd08c1ce-886a-4a0f-9222-3bdec6c0ba96@github.com> Message-ID: <1rGGt2ZaCUWE8YxQcsc_ubtHebJCzgqZochwtBQBLMI=.70ed4908-7cbb-451d-97dc-c0a74e09835e@github.com> On Fri, 12 Dec 2025 12:44:09 GMT, Serguei Spitsyn wrote: >> Hi @sspitsyn , >> >> Thank you for looking at this patch! >> >>> This is a nice fix in general. Thank you for this work! I hope to complete my review tomorrow with one more pass. Question: How was this update tested? Do you have a jtreg test or you've done it manually? Also, did you run mach5 tiers 1-6 to be safe and protected against regressions? >> >> The patch was tested against the current jtreg test groups (tier1-3) on macOS both amd64 and arm64. I also run jcmd and jps tools manually under root, because the change only affects the behavior under root. >> >>> * It seems it was needed to inherit the `PlatformSupport` class which has the method `PlatformSupport.getTemporaryDirectory()`. But it returns the same as the removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`. So, this implementation can be moved to the `jdk.attach` module. >> >> The removed function `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()` would return always the same string cached inside the libsystem_coreservices.dylib, that would correspond the user specific temporary path as of how the JVM process has started, that would have nothing to do with the target process/pid temporary directory. >> >>> * My understanding is that class `PlatformSupportImpl` and its method `getTemporaryDirectories(int pid)` is not currently used for `jvmstat` implementation. Is it correct? >> >> I think this is not exactly so. `getTemporaryDirectories(int pid)` is used currently in the LocalVmManager to get the list of active VMs, that is consumed by `jcmd`, `jps` and `jconsole` utilities. When 0 is passed as a parameter, it returns the list of temp directories for all processes, if they were different (for example if there are containerized JVM processes under Linux). >> >>> * Is it right that the `jvmstat` implementation still does not properly support root user on macOS? >> >> Yes and this is what this patch was intended for. >> >>> * Do we really need 3x implementations of the MacOS `tempdir` finder function? >> >> It was already 2x implementation of HotSpot perfdata files lookup, HotSpot itself uses the `os::get_temp_directory()`, on the java side the LocalVmManager in `sun.jvmstat.perfdata.monitor` relies on `getTemporaryDirectories(int pid)` in the PlatformSupport. The 3rd was the macOS native `Java_sun_tools_attach_VirtualMachineImpl_getTempDir()`, now it's proposed for removal as it returns only the current user temp path, no matter what process is being attached to. >> >>> ... > > @sercher I have a plan to submit mach5 tiers 1-6 to be completely safe from regressions. > Will approve this PR if the results are good. Thank you @sspitsyn and @larry-cable for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3655030577 From duke at openjdk.org Mon Dec 15 11:07:48 2025 From: duke at openjdk.org (duke) Date: Mon, 15 Dec 2025 11:07:48 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v10] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:34:37 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 possibility 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 t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright header @sercher Your change (at version c318ac87dc28b1812d2fcd2873d70fe59fd13ab3) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3655040763 From coleenp at openjdk.org Mon Dec 15 12:45:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Dec 2025 12:45:18 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 04:15:09 GMT, David Holmes wrote: > In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. > > The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). > > Testing: > - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug > - tiers 1-3 sanity > > Thanks Now where do we free the duplicate nest host error? ------------- PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3577974616 From jpai at openjdk.org Mon Dec 15 14:00:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Dec 2025 14:00:18 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: <46VBWrTZlAboGapEvJ7jcOc6G_-fLBTrLVvtRxWsJeA=.31442313-8f57-4bb8-91e4-02f9b8706063@github.com> On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. Thank you all for the reviews. There's one javac related test file update in this PR, so I'll need someone from compiler area to review this too, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28780#issuecomment-3655782579 From syan at openjdk.org Mon Dec 15 14:21:44 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:21:44 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> Message-ID: On Mon, 15 Dec 2025 07:58:35 GMT, Leonid Mesnik wrote: >> SendaoYan 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 branch 'openjdk:master' into jbs8371503 >> - Remove extra ident >> - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests > > Marked as reviewed by lmesnik (Reviewer). Thanks for the reviews @lmesnik @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3655876260 From syan at openjdk.org Mon Dec 15 14:21:46 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:21:46 GMT Subject: Integrated: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. This pull request has now been integrated. Changeset: 34f24131 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c Stats: 32 lines in 11 files changed: 2 ins; 20 del; 10 mod 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Reviewed-by: lmesnik, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28208 From coleenp at openjdk.org Mon Dec 15 14:39:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Dec 2025 14:39:39 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt In-Reply-To: References: Message-ID: <_GHQ26i52NAsEJH-iCDxpGcocZ3H6Q59d-LnVO_hAbM=.cbf5cbcb-7ba3-4c4b-b526-a2509e53ec1c@github.com> On Mon, 15 Dec 2025 04:15:09 GMT, David Holmes wrote: > In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. > > The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). > > Testing: > - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug > - tiers 1-3 sanity > > Thanks src/hotspot/share/classfile/systemDictionary.cpp line 1883: > 1881: else { > 1882: assert(strcmp(nhe, message) == 0, "New message %s, differs from original %s", message, nhe); > 1883: } The caller allocates this message so the caller should free it but that would require passing up that we actually installed the message. We could keep this leak temporarily until https://bugs.openjdk.org/browse/JDK-8372373 is fixed to resource allocate the message. Or add a FREE_C_HEAP_ARRAY here even though it's not the best place for it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2619702033 From syan at openjdk.org Mon Dec 15 14:39:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:39:51 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Message-ID: Hi all, This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. Thanks! ------------- Commit messages: - Backport 34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c Changes: https://git.openjdk.org/jdk/pull/28826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371503 Stats: 32 lines in 11 files changed: 2 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28826/head:pull/28826 PR: https://git.openjdk.org/jdk/pull/28826 From jnorlinder at openjdk.org Mon Dec 15 14:56:22 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 15 Dec 2025 14:56:22 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code Message-ID: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. A minimal example: public static void main(String[] args) { // Initial GC that clean up start-up garbage etc. System.gc(); for (int i = 1; i <= 128; i++) { addLoad(); // Creates 128 threads, that spins in a loop try { Thread.sleep(2000); } catch (InterruptedException e) {} System.gc(); } System.exit(0); } where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. In such scenario we can observe using G1 [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s ... [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s Since the Java code does not do anything the time should be close to 0. # Implementation Comment Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. ------------- Commit messages: - Fix JNI bug in GCTraceCPUTime Changes: https://git.openjdk.org/jdk/pull/28824/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361716 Stats: 203 lines in 11 files changed: 150 ins; 25 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From mdoerr at openjdk.org Mon Dec 15 15:23:26 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 Dec 2025 15:23:26 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . LGTM, but I'm not a Windows build expert. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28792#pullrequestreview-3578769858 From pchilanomate at openjdk.org Mon Dec 15 15:26:52 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 15 Dec 2025 15:26:52 GMT Subject: RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:48:54 GMT, Serguei Spitsyn wrote: > This is a 1-liner fix of a regression. > The issue was discovered after merge with main line of this PR: https://github.com/openjdk/jdk/pull/28407 . > > It will need to be back ported to 26 as well. > > Testing: > - TBD: This was already tested in another PR repo but will submit mach5 tiers 1-3 to be completely safe. Thanks for finding and fixing this Serguei! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28805#pullrequestreview-3578788500 From mbaesken at openjdk.org Mon Dec 15 15:26:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 15 Dec 2025 15:26:52 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . Thanks Martin ! It is a HS change (a very small one but still a HS change), so we need one more reviewer anyway! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28792#issuecomment-3656238859 From rrich at openjdk.org Mon Dec 15 15:54:29 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 15 Dec 2025 15:54:29 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 @dholmes-ora I do think that also _entering_ a critical region is problematic if it is nested. I'm currently testing with https://github.com/reinrich/jdk/commit/d7ce2ccb2150c92929b8d9140b4709833d188474 where a thread doesn't suspend for EscapeBarriers while in a critical region. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3656372702 From duke at openjdk.org Mon Dec 15 17:31:20 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Mon, 15 Dec 2025 17:31:20 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v10] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson 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 nativelibraries-fix - add test showing loading symlinked libraries with various combinations - revert dll_load fix - Merge branch 'master' into nativelibraries-fix - add cast - use os::malloc - Merge branch 'master' into nativelibraries-fix - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - ... and 6 more: https://git.openjdk.org/jdk/compare/ad29642d...d03535ce ------------- Changes: https://git.openjdk.org/jdk/pull/24694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=09 Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From iklam at openjdk.org Mon Dec 15 19:23:08 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Dec 2025 19:23:08 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v4] In-Reply-To: References: Message-ID: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Ioi Lam 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 six additional commits since the last revision: - Merge branch 'master' into 8373615-improve-findclass-and-findmethod - Fixed regex test problems on Windows - Fixed test and added more test cases - sort includes - @ashu-mehra and @matias9927 review comments - 8373615: Improve HotSpot debug functions findclass() and findmethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28796/files - new: https://git.openjdk.org/jdk/pull/28796/files/4d40f01e..6649620a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=02-03 Stats: 7538 lines in 283 files changed: 4672 ins; 1009 del; 1857 mod Patch: https://git.openjdk.org/jdk/pull/28796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28796/head:pull/28796 PR: https://git.openjdk.org/jdk/pull/28796 From liach at openjdk.org Mon Dec 15 19:49:52 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:49:52 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang 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 12 additional commits since the last revision: - Move test, fix merge garbage - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Typo - assert - refactorings - Typo - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Cleanup - identity hash support in C2 - ... and 2 more: https://git.openjdk.org/jdk/compare/9543b2fa...67a3954f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/b1d8be39..67a3954f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=02-03 Stats: 44910 lines in 756 files changed: 29623 ins; 11706 del; 3581 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From liach at openjdk.org Mon Dec 15 19:49:54 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:49:54 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> Message-ID: On Sat, 13 Dec 2025 00:57:52 GMT, Vladimir Ivanov wrote: >> You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary. > > I don't argue that there's always a chance to catch a bug, but unit tests on C2 IR are mostly trivial, so the actual chance to spot a unique problem is quite low. And the price is execution time. I kept the C2 limit (note this is a build restriction instead of a flag restriction), but updated to use test.main.class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2620621537 From liach at openjdk.org Mon Dec 15 19:49:55 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:49:55 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> Message-ID: <7oLQjFLs3t_6kGwXXUNec_Kyvbm-CDu-qX7if_UDfy8=.c613c4d0-6df2-49a4-bfa1-807e10c07147@github.com> On Wed, 10 Dec 2025 17:17:13 GMT, Emanuel Peter wrote: >> I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work? > > You could compute the result in the static initializer, it should therefore be computed in the interpreter. And then add a `@Check` method to compare the `testSum` value from the compiler. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2620621850 From dholmes at openjdk.org Mon Dec 15 20:15:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 20:15:59 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt In-Reply-To: <_GHQ26i52NAsEJH-iCDxpGcocZ3H6Q59d-LnVO_hAbM=.cbf5cbcb-7ba3-4c4b-b526-a2509e53ec1c@github.com> References: <_GHQ26i52NAsEJH-iCDxpGcocZ3H6Q59d-LnVO_hAbM=.cbf5cbcb-7ba3-4c4b-b526-a2509e53ec1c@github.com> Message-ID: On Mon, 15 Dec 2025 14:36:17 GMT, Coleen Phillimore wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > src/hotspot/share/classfile/systemDictionary.cpp line 1883: > >> 1881: else { >> 1882: assert(strcmp(nhe, message) == 0, "New message %s, differs from original %s", message, nhe); >> 1883: } > > The caller allocates this message so the caller should free it but that would require passing up that we actually installed the message. We could keep this leak temporarily until https://bugs.openjdk.org/browse/JDK-8372373 is fixed to resource allocate the message. Or add a FREE_C_HEAP_ARRAY here even though it's not the best place for it? Hmmm. We can't resource allocate the message unless we then copy to the C-heap as it has to out-live the thread that creates it. But we can pass the stringStream instead of the exposed "char*" and so avoid the leak. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620696756 From schernyshev at openjdk.org Mon Dec 15 20:22:51 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 15 Dec 2025 20:22:51 GMT Subject: Integrated: 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 possibility 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... This pull request has now been integrated. Changeset: f52d4992 Author: Sergey Chernyshev Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/f52d49925f9c60814a0a34720d7443e748b35c25 Stats: 279 lines in 9 files changed: 237 ins; 27 del; 15 mod 8319589: Attach from root to a user java process not supported in Mac Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25824 From dholmes at openjdk.org Mon Dec 15 20:41:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 20:41:01 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: References: Message-ID: > In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. > > The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). > > Testing: > - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug > - tiers 1-3 sanity > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Avoid memory leaks by passing stringStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28817/files - new: https://git.openjdk.org/jdk/pull/28817/files/e886320d..9332638b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28817&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28817&range=00-01 Stats: 12 lines in 3 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28817/head:pull/28817 PR: https://git.openjdk.org/jdk/pull/28817 From coleenp at openjdk.org Mon Dec 15 20:41:01 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Dec 2025 20:41:01 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: References: Message-ID: <2Z0z6dzZ-j1_shtL9rk9-tolR06PC-pHAs0Rv5O_bnY=.f7d2f03d-129d-4ba6-ad5a-597f86d4c07d@github.com> On Mon, 15 Dec 2025 20:37:19 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Avoid memory leaks by passing stringStream Yes, this looks really good! Now the ResolutionErrorEntry "owns" the memory for the char* message and it's less confusing overall. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3580039105 From dholmes at openjdk.org Mon Dec 15 20:45:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 20:45:51 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: <2Z0z6dzZ-j1_shtL9rk9-tolR06PC-pHAs0Rv5O_bnY=.f7d2f03d-129d-4ba6-ad5a-597f86d4c07d@github.com> References: <2Z0z6dzZ-j1_shtL9rk9-tolR06PC-pHAs0Rv5O_bnY=.f7d2f03d-129d-4ba6-ad5a-597f86d4c07d@github.com> Message-ID: On Mon, 15 Dec 2025 20:34:39 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid memory leaks by passing stringStream > > Yes, this looks really good! Now the ResolutionErrorEntry "owns" the memory for the char* message and it's less confusing overall. Thanks for the review @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28817#issuecomment-3657531644 From iklam at openjdk.org Mon Dec 15 20:52:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Dec 2025 20:52:31 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 20:41:01 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Avoid memory leaks by passing stringStream Looks good. Two minor nits. src/hotspot/share/classfile/resolutionErrors.cpp line 130: > 128: > 129: void ResolutionErrorEntry::set_nest_host_error(const char* message) { > 130: assert(_nest_host_error == nullptr, "caller should have checked"); May also check that you're holding `SystemDictionary_lock`? That way you're more certain that the field has not been changed since the caller checked it. src/hotspot/share/classfile/systemDictionary.cpp line 1881: > 1879: entry->set_nest_host_error(message.as_string(true /* on C-heap */)); > 1880: } > 1881: else { `} else {` should be in one line. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3580099164 PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620803907 PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620805362 From iklam at openjdk.org Mon Dec 15 20:57:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Dec 2025 20:57:04 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v2] In-Reply-To: References: Message-ID: On Sat, 13 Dec 2025 02:00:11 GMT, Ashutosh Mehra wrote: > lgtm, although there are some test failures likely related to these changes. I've fixed the test failures and added more test cases. The regexp checks needs to be disabled on Windows due to lack of support (see https://github.com/google/googletest/blob/main/docs/advanced.md#regular-expression-syntax) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3657568679 From jsjolen at openjdk.org Mon Dec 15 20:59:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 15 Dec 2025 20:59:01 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 20:41:01 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Avoid memory leaks by passing stringStream Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3580121078 From matsaave at openjdk.org Mon Dec 15 21:03:35 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 15 Dec 2025 21:03:35 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v4] In-Reply-To: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> References: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> Message-ID: <12BWDD9cBUae_qWbsEVPi2wGF272oTivyiONkNRNmeA=.d4db54fe-b467-4be3-b6fd-6d9c5a996977@github.com> On Mon, 15 Dec 2025 19:23:08 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam 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 six additional commits since the last revision: > > - Merge branch 'master' into 8373615-improve-findclass-and-findmethod > - Fixed regex test problems on Windows > - Fixed test and added more test cases > - sort includes > - @ashu-mehra and @matias9927 review comments > - 8373615: Improve HotSpot debug functions findclass() and findmethod Thanks for fixing the gtest, approved again ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28796#pullrequestreview-3580136652 From dholmes at openjdk.org Mon Dec 15 21:13:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 21:13:29 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 20:50:06 GMT, Ioi Lam wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid memory leaks by passing stringStream > > Looks good. Two minor nits. Thanks for the reviews @iklam and @jdksjolen ! > src/hotspot/share/classfile/resolutionErrors.cpp line 130: > >> 128: >> 129: void ResolutionErrorEntry::set_nest_host_error(const char* message) { >> 130: assert(_nest_host_error == nullptr, "caller should have checked"); > > May also check that you're holding `SystemDictionary_lock`? That way you're more certain that the field has not been changed since the caller checked it. Done > src/hotspot/share/classfile/systemDictionary.cpp line 1881: > >> 1879: entry->set_nest_host_error(message.as_string(true /* on C-heap */)); >> 1880: } >> 1881: else { > > `} else {` should be in one line. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/28817#issuecomment-3657618865 PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620858663 PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620859053 From dholmes at openjdk.org Mon Dec 15 21:13:26 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 21:13:26 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v3] In-Reply-To: References: Message-ID: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> > In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. > > The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). > > Testing: > - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug > - tiers 1-3 sanity > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28817/files - new: https://git.openjdk.org/jdk/pull/28817/files/9332638b..6bd0192e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28817&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28817&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28817/head:pull/28817 PR: https://git.openjdk.org/jdk/pull/28817 From asmehra at openjdk.org Mon Dec 15 21:31:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 15 Dec 2025 21:31:03 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v4] In-Reply-To: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> References: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> Message-ID: On Mon, 15 Dec 2025 19:23:08 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam 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 six additional commits since the last revision: > > - Merge branch 'master' into 8373615-improve-findclass-and-findmethod > - Fixed regex test problems on Windows > - Fixed test and added more test cases > - sort includes > - @ashu-mehra and @matias9927 review comments > - 8373615: Improve HotSpot debug functions findclass() and findmethod test/hotspot/gtest/runtime/test_classPrinter.cpp line 88: > 86: > 87: #ifndef PRODUCT > 88: // These are available only in debug builds Sorry for nitpicking but I see `PRINT_BYTECODE` and `PRINT_BYTECODE_ADDRESS` are available in product builds, only `PRINT_METHOD_DETAILS` relies on method present in debug build. Or did I miss something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2620911462 From kirk.pepperdine at gmail.com Mon Dec 15 21:51:29 2025 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 15 Dec 2025 13:51:29 -0800 Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: Hi Jonas, I believe the assumption of ?close to 0? is based on no other processes running on that machine, not just native JNI code. In a ?clean? system I have seen that these numbers are correct enough. The interesting thing about these numbers is the tell that they give you. For example, it appears as if you are running on a 32 core machine. Additionally, there are system level disturbances that are seen with an analysis of these measures. I?m sure enabling this analysis wasn?t intentional but it can be quite useful. Kind regards, Kirk > On Dec 15, 2025, at 6:56?AM, Jonas Norlinder wrote: > > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > ------------- > > Commit messages: > - Fix JNI bug in GCTraceCPUTime > > Changes: https://git.openjdk.org/jdk/pull/28824/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8361716 > Stats: 203 lines in 11 files changed: 150 ins; 25 del; 28 mod > Patch: https://git.openjdk.org/jdk/pull/28824.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 > > PR: https://git.openjdk.org/jdk/pull/28824 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1515 bytes Desc: not available URL: From coleenp at openjdk.org Mon Dec 15 22:22:16 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Dec 2025 22:22:16 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v3] In-Reply-To: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> References: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> Message-ID: On Mon, 15 Dec 2025 21:13:26 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3580414070 From iklam at openjdk.org Mon Dec 15 22:49:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Dec 2025 22:49:07 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v3] In-Reply-To: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> References: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> Message-ID: <3FSxho-e95IrXJujgqlY8_NFKxmjh_8pHEJOX87-IjA=.02241324-f494-4e38-8989-0daf30609d70@github.com> On Mon, 15 Dec 2025 21:13:26 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28817#pullrequestreview-3580481190 From dholmes at openjdk.org Tue Dec 16 00:23:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 00:23:04 GMT Subject: Integrated: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt In-Reply-To: References: Message-ID: <69W0How2qW8GVoOm_luArXMYP8dnL7gz4b30NAXPNGw=.6992d76d-21b5-45b1-8179-288bacd82ba5@github.com> On Mon, 15 Dec 2025 04:15:09 GMT, David Holmes wrote: > In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. > > The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). > > Testing: > - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug > - tiers 1-3 sanity > > Thanks This pull request has now been integrated. Changeset: 1748737b Author: David Holmes URL: https://git.openjdk.org/jdk/commit/1748737b99f283f69b4be0910b6623a27d804e68 Stats: 21 lines in 4 files changed: 5 ins; 4 del; 12 mod 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt Reviewed-by: coleenp, iklam, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/28817 From dholmes at openjdk.org Tue Dec 16 00:23:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 00:23:03 GMT Subject: RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt [v3] In-Reply-To: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> References: <5D5F_YlkNAaajq3WGzJWk_0_9PjALFZxmvt_I2hEGtk=.35dd3194-ffc0-4ede-be3a-1c8b5b8bf2a3@github.com> Message-ID: On Mon, 15 Dec 2025 21:13:26 GMT, David Holmes wrote: >> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity. >> >> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table). >> >> Testing: >> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Re-testing completed. Thanks again for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28817#issuecomment-3658134742 From dholmes at openjdk.org Tue Dec 16 01:08:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 01:08:51 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com> On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 > I do think that also entering a critical region is problematic if it is nested. Isn't nesting critical regions against the rules of using critical regions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3658251463 From qamai at openjdk.org Tue Dec 16 02:31:57 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 16 Dec 2025 02:31:57 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang 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 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/c026ba9b...67a3954f src/hotspot/share/opto/library_call.cpp line 4806: > 4804: assert(!is_virtual, "no devirtualization for constant receiver?"); > 4805: ciConstant identity_hash = t->const_oop()->identity_hash(); > 4806: if (identity_hash.is_valid()) { Is there any reason we don't calculate the identity hash right away if there is not any? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621527376 From liach at openjdk.org Tue Dec 16 02:42:59 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 02:42:59 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 02:29:05 GMT, Quan Anh Mai wrote: >> Chen Liang 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 12 additional commits since the last revision: >> >> - Move test, fix merge garbage >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Typo >> - assert >> - refactorings >> - Typo >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Cleanup >> - identity hash support in C2 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/cea24102...67a3954f > > src/hotspot/share/opto/library_call.cpp line 4806: > >> 4804: assert(!is_virtual, "no devirtualization for constant receiver?"); >> 4805: ciConstant identity_hash = t->const_oop()->identity_hash(); >> 4806: if (identity_hash.is_valid()) { > > Is there any reason we don't calculate the identity hash right away if there is not any? @iwanowww recommended not to so that we can save resources - ideally we should convert this to sort of macro node, so we can calculate the hash if the node is not eliminated in the end. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621544616 From vlivanov at openjdk.org Tue Dec 16 02:53:53 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 16 Dec 2025 02:53:53 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: <4nezat7vgHclje5N0lTXYIW49lgU1c9Fb_PXiUhffmE=.2f83013e-994e-4cec-b1ae-43e37c0b3455@github.com> On Tue, 16 Dec 2025 02:39:47 GMT, Chen Liang wrote: >> src/hotspot/share/opto/library_call.cpp line 4806: >> >>> 4804: assert(!is_virtual, "no devirtualization for constant receiver?"); >>> 4805: ciConstant identity_hash = t->const_oop()->identity_hash(); >>> 4806: if (identity_hash.is_valid()) { >> >> Is there any reason we don't calculate the identity hash right away if there is not any? > > @iwanowww recommended not to so that we can save resources - ideally we should convert this to sort of macro node, so we can calculate the hash if the node is not eliminated in the end. My main concern is possible interference with application, not performance. One example is CDS where archive dumping is performed in a single thread with a fixed random generator seed. If identity hash computation can be triggered from JIT-compiler thread (with a different seed), it will break deterministic behavior. Another case to illustrate another type of issues is biased locking: the optimization was disabled for objects with identity hash code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621562185 From iklam at openjdk.org Tue Dec 16 04:19:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Dec 2025 04:19:32 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v5] In-Reply-To: References: Message-ID: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra review comment - more fix on tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28796/files - new: https://git.openjdk.org/jdk/pull/28796/files/6649620a..df897c28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28796&range=03-04 Stats: 15 lines in 1 file changed: 6 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28796/head:pull/28796 PR: https://git.openjdk.org/jdk/pull/28796 From iklam at openjdk.org Tue Dec 16 04:19:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Dec 2025 04:19:35 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v4] In-Reply-To: References: <610it2ZxZyXLP_lvTgbID8hzwuS40DjQ7xcUsuQjaho=.319907f4-84c8-4691-b1fd-ec066b3d1948@github.com> Message-ID: On Mon, 15 Dec 2025 21:28:21 GMT, Ashutosh Mehra wrote: >> Ioi Lam 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 six additional commits since the last revision: >> >> - Merge branch 'master' into 8373615-improve-findclass-and-findmethod >> - Fixed regex test problems on Windows >> - Fixed test and added more test cases >> - sort includes >> - @ashu-mehra and @matias9927 review comments >> - 8373615: Improve HotSpot debug functions findclass() and findmethod > > test/hotspot/gtest/runtime/test_classPrinter.cpp line 88: > >> 86: >> 87: #ifndef PRODUCT >> 88: // These are available only in debug builds > > Sorry for nitpicking but I see `PRINT_BYTECODE` and `PRINT_BYTECODE_ADDRESS` are available in product builds, only `PRINT_METHOD_DETAILS` relies on method present in debug build. Or did I miss something? Thanks for noticing it. I've moved the `#if` around so that `PRINT_BYTECODE` and `PRINT_BYTECODE_ADDRESS` are tested in product builds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28796#discussion_r2621700468 From dholmes at openjdk.org Tue Dec 16 05:00:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 05:00:52 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 01:39:44 GMT, Kim Barrett wrote: >> Please review this change to Atomic to meet the requirements for constant >> initialization in cases where the value type provides the requisite support. >> This ensures that in such cases dynamic initialization won't even be >> considered a possibility when initialized with constant arguments. >> >> Testing: mach5 tier1 > > Kim Barrett 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 constinit-atomic > - constexpr Atomc ctors > On the surface, this looks fine to me. +1 ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28711#pullrequestreview-3581308505 From dholmes at openjdk.org Tue Dec 16 06:00:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 06:00:55 GMT Subject: RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:48:54 GMT, Serguei Spitsyn wrote: > This is a 1-liner fix of a regression. > The issue was discovered after merge with main line of this PR: https://github.com/openjdk/jdk/pull/28407 . > > It will need to be back ported to 26 as well. > > Testing: > - TBD: This was already tested in another PR repo but will submit mach5 tiers 1-3 to be completely safe. LGTM Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28805#pullrequestreview-3581443583 From rrich at openjdk.org Tue Dec 16 08:31:54 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 16 Dec 2025 08:31:54 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com> References: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com> Message-ID: On Tue, 16 Dec 2025 01:05:58 GMT, David Holmes wrote: > > I do think that also entering a critical region is problematic if it is nested. > > Isn't nesting critical regions against the rules of using critical regions? For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :) I'll see if I can implement a reproducer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3659373705 From sspitsyn at openjdk.org Tue Dec 16 09:14:16 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Dec 2025 09:14:16 GMT Subject: RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:48:54 GMT, Serguei Spitsyn wrote: > This is a 1-liner fix of a regression. > The issue was discovered after merge with main line of this PR: https://github.com/openjdk/jdk/pull/28407 . > > It will need to be back ported to 26 as well. > > Testing: > - TBD: This was already tested in another PR repo but will submit mach5 tiers 1-3 to be completely safe. Thank you for reviews, David and Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28805#issuecomment-3659534667 From jlahoda at openjdk.org Tue Dec 16 09:41:02 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 16 Dec 2025 09:41:02 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. Marked as reviewed by jlahoda (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3582185635 From tschatzl at openjdk.org Tue Dec 16 09:46:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Dec 2025 09:46:10 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Mon, 15 Dec 2025 12:50:55 GMT, Jonas Norlinder wrote: > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Changes requested by tschatzl (Reviewer). src/hotspot/os/aix/os_aix.cpp line 2475: > 2473: -1, > 2474: -1 > 2475: }; If there are no comments to the elements, I would prefer to just use a single line for the return statement. Same for below. src/hotspot/os/bsd/os_bsd.cpp line 2312: > 2310: ((jlong) tinfo.user_time.seconds * (jlong)1000000000) + ((jlong) tinfo.user_time.microseconds * (jlong)1000), > 2311: ((jlong) tinfo.system_time.seconds * (jlong)1000000000) + ((jlong)tinfo.system_time.microseconds * (jlong)1000) > 2312: }; There are several known constants for these large numbers (e.g. `NANOSECS_PER_SEC`) already defined. I would prefer to use them. src/hotspot/os/linux/os_linux.hpp line 2: > 1: /* > 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. The copyright change seems to be the only change in this file, and should be reverted. src/hotspot/os/windows/os_windows.cpp line 4909: > 4907: return { > 4908: FT2INT64(UserTime) * 100, > 4909: FT2INT64(KernelTime) * 100 maybe create a local constant for the `100` to indicate that this is a value derived from MS API. src/hotspot/os/windows/os_windows.cpp line 4940: > 4938: return -1; > 4939: } > 4940: return user_sys_cpu_time ? cpu_time.user + cpu_time.system : cpu_time.user; All the `os::thread_cpu_time` implementation look the same now, but the BSD one. Maybe that distinction could be moved into `os::detailed_cpu_thread_time` (i.e. the `Unimplemented` bailout for that and `os::thread_cpu_time()` extracted out to avoid code duplication there? src/hotspot/share/gc/shared/gcTraceTime.hpp line 40: > 38: bool _active; // true if times will be measured and printed > 39: jlong _starting_user_time; // user time at start of measurement > 40: jlong _starting_system_time; // system time at start of measurement Suggestion: jlong _starting_user_time; // User time at start of measurement jlong _starting_system_time; // System time at start of measurement src/hotspot/share/runtime/os.hpp line 173: > 171: jlong user; > 172: jlong system; > 173: }; Fwiw, `jlong` is a "Java" long, so maybe some C type should be used here. I am aware that the OS interface traditionally uses it, but changes need to start somewhere. However the runtime team may have additional comments about this. ------------- PR Review: https://git.openjdk.org/jdk/pull/28824#pullrequestreview-3582152280 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622493322 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622504990 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622507542 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622510993 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622533968 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622515849 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622519179 From jonas.norlinder at oracle.com Tue Dec 16 09:51:00 2025 From: jonas.norlinder at oracle.com (Jonas Norlinder) Date: Tue, 16 Dec 2025 09:51:00 +0000 Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: Hi Kirk, That's an interesting point you bring up. While I agree that the current implementation may leak information that is useful for detecting system saturation, I'm not sure that means we can keep this implementation. The semantic contract of the [gc, cpu] log tag is to report GC CPU time. By including process wide noise we violate that contract. We will still report system and user time just more accurately so. For diagnosing system-level distances we have JFR (jdk.CPUload) and JMX (OperatingSystemMXBean). We should probably rely on these tools rather than using GC logs to carry a noisy signal. Best, Jonas On 2025-12-15, 22:51, "Kirk Pepperdine" wrote: Hi Jonas, I believe the assumption of ?close to 0? is based on no other processes running on that machine, not just native JNI code. In a ?clean? system I have seen that these numbers are correct enough. The interesting thing about these numbers is the tell that they give you. For example, it appears as if you are running on a 32 core machine. Additionally, there are system level disturbances that are seen with an analysis of these measures. I?m sure enabling this analysis wasn?t intentional but it can be quite useful. Kind regards, Kirk > On Dec 15, 2025, at 6:56?AM, Jonas Norlinder > wrote: > > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > ------------- > > Commit messages: > - Fix JNI bug in GCTraceCPUTime > > Changes: https://git.openjdk.org/jdk/pull/28824/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8361716 > Stats: 203 lines in 11 files changed: 150 ins; 25 del; 28 mod > Patch: https://git.openjdk.org/jdk/pull/28824.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 > > PR: https://git.openjdk.org/jdk/pull/28824 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Dec 16 10:11:29 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Dec 2025 10:11:29 GMT Subject: RFR: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. Thank you Jan for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28780#issuecomment-3659757169 From jpai at openjdk.org Tue Dec 16 10:11:30 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Dec 2025 10:11:30 GMT Subject: Integrated: 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"? > > As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option. > > tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms. This pull request has now been integrated. Changeset: 41d28c18 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/41d28c1838bcd7a69f78c9799b449af2a33c11c3 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod 8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option Reviewed-by: serb, prr, dholmes, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/28780 From sspitsyn at openjdk.org Tue Dec 16 10:31:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Dec 2025 10:31:46 GMT Subject: Integrated: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:48:54 GMT, Serguei Spitsyn wrote: > This is a 1-liner fix of a regression. > The issue was discovered after merge with main line of this PR: https://github.com/openjdk/jdk/pull/28407 . > > It will need to be back ported to 26 as well. > > Testing: > - TBD: This was already tested in another PR repo but will submit mach5 tiers 1-3 to be completely safe. This pull request has now been integrated. Changeset: 53ebcdbd Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/53ebcdbd029a1c78f8429574b78cecce70c11af2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers Reviewed-by: pchilanomate, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28805 From sspitsyn at openjdk.org Tue Dec 16 11:20:07 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Dec 2025 11:20:07 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v3] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn 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 - review: restored the assert and fixed the issue caused it to fire - 8373366: HandshakeState should disallow suspend ops for disabler threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/b51267f3..2b088a62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=01-02 Stats: 35244 lines in 491 files changed: 23171 ins; 9295 del; 2778 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From dholmes at openjdk.org Tue Dec 16 11:33:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 11:33:53 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com> Message-ID: On Tue, 16 Dec 2025 08:29:32 GMT, Richard Reingruber wrote: > > > I do think that also entering a critical region is problematic if it is nested. > > > > > > Isn't nesting critical regions against the rules of using critical regions? > > For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :) I'll see if I can implement a reproducer. Right I see that. It states: > Inside a critical region, native code must not call other JNI functions, ... but then explicitly allows the critical functions themselves to be an exception. Okay. So isn't a fix for this simply to skip blocking as per your PR: if (is_obj_deopt_suspend() && !in_critical()) { irrespective of nesting and without any need for any of the changes I proposed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660076633 From jnorlinder at openjdk.org Tue Dec 16 11:51:54 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 11:51:54 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Tue, 16 Dec 2025 09:34:41 GMT, Thomas Schatzl wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > src/hotspot/os/linux/os_linux.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. > > The copyright change seems to be the only change in this file, and should be reverted. File was recently edited but didn't update copyright year. I can file a separate JBS and PR for that line if you prefer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2622956887 From rrich at openjdk.org Tue Dec 16 13:01:50 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 16 Dec 2025 13:01:50 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com> Message-ID: On Tue, 16 Dec 2025 11:31:11 GMT, David Holmes wrote: > So isn't a fix for this simply to skip blocking as per your PR: > > ``` > if (is_obj_deopt_suspend() && !in_critical()) { > ``` > > irrespective of nesting and without any need for any of the changes I proposed? Yes, I currently think so. Testing so far is good. Don't have a reproducer yet for the deadlock. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660407119 From jnorlinder at openjdk.org Tue Dec 16 13:38:44 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 13:38:44 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v2] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/588e1b33..d3692c7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=00-01 Stats: 105 lines in 11 files changed: 10 ins; 57 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From jnorlinder at openjdk.org Tue Dec 16 14:01:53 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 14:01:53 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v2] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Tue, 16 Dec 2025 13:38:44 GMT, Jonas Norlinder wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix review comments Thanks for the review Thomas! Also fixed some comments from @kstefanj. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28824#issuecomment-3660658872 From jnorlinder at openjdk.org Tue Dec 16 14:01:55 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 14:01:55 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v2] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Tue, 16 Dec 2025 09:38:29 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix review comments > > src/hotspot/share/runtime/os.hpp line 173: > >> 171: jlong user; >> 172: jlong system; >> 173: }; > > Fwiw, `jlong` is a "Java" long, so maybe some C type should be used here. I am aware that the OS interface traditionally uses it, but changes need to start somewhere. However the runtime team may have additional comments about this. I think such change should start at the source i.e. os::thread_cpu_time, but will await what runtime team says... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2623391522 From jsjolen at openjdk.org Tue Dec 16 14:55:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Dec 2025 14:55:02 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM Message-ID: Hi, `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. A regression test has been added. Thanks! ------------- Commit messages: - Untabify - Spelling mistake - Add a recursion limit Changes: https://git.openjdk.org/jdk/pull/28674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28674&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364655 Stats: 90 lines in 2 files changed: 84 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28674/head:pull/28674 PR: https://git.openjdk.org/jdk/pull/28674 From sjohanss at openjdk.org Tue Dec 16 14:56:54 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 16 Dec 2025 14:56:54 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v2] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Tue, 16 Dec 2025 13:38:44 GMT, Jonas Norlinder wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix review comments Looks good in general, some more comments. src/hotspot/share/gc/shared/gcTraceTime.cpp line 86: > 84: cpu_time_t cpu_time_stringdedup = CPUTimeUsage::GC::detailed_stringdedup(); > 85: _starting_user_time = cpu_time_vm.user + cpu_time_gc.user + cpu_time_stringdedup.user; > 86: _starting_system_time = cpu_time_vm.system + cpu_time_gc.system + cpu_time_stringdedup.system; As I mentioned offline, maybe extract this to a helper that can also be used in the destructor. If you like the idea to use `cpu_time_t` to store the start measurement the helper could return a `cpu_time_t` as well. src/hotspot/share/gc/shared/gcTraceTime.cpp line 101: > 99: cpu_time_t cpu_time_stringdedup = CPUTimeUsage::GC::detailed_stringdedup(); > 100: > 101: double real_time = os::elapsedTime() - _starting_real_time; You are subtracting the start time here and also in the if-statement below, I guess one of them should be removed. src/hotspot/share/gc/shared/gcTraceTime.hpp line 40: > 38: bool _active; // True if times will be measured and printed > 39: jlong _starting_user_time; // User time at start of measurement > 40: jlong _starting_system_time; // System time at start of measurement What do you think about just using `cpu_time_t` here? src/hotspot/share/runtime/os.hpp line 175: > 173: }; > 174: typedef struct cpu_time cpu_time_t; > 175: I looked a bit closer at this now, I could make sense to use a more common Hotspot type here since this is nothing that we expect the JDK will use. I think that is the main reason we use `jlong` in `os::thread_cpu_time()`. The new `detailed_thread_cpu_time()` is a Hotspot API and could then use Hotspot types, like `uint64_t`. But then we likely want to change this in the users of this class as well, for example `DetailedCPUTimeThreadClosure`, and I'm not sure how big the fan-out would be. Maybe we can change the type as a follow-up if more people agree with this. ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28824#pullrequestreview-3583442358 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2623595381 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2623604120 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2623570439 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2623553450 From jsjolen at openjdk.org Tue Dec 16 15:00:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Dec 2025 15:00:58 GMT Subject: RFR: 8372246: LogOutputList gtests should not use LogConfiguration LogOutputs [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 13:16:28 GMT, Axel Boldt-Christmas wrote: >> A handful of `LogOutputList` tests uses `LogConfiguration::Std[out|err]Log` LogOutputs in its tests. >> However these are not setup unless we run the tests in VM mode. >> >> I suggest we add some dummy `LogOutputs` for `StdoutLog` and `StderrLog` which these tests can use, so they are not depending being a VM test. > > Axel Boldt-Christmas 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 'JDK-8372241' into JDK-8372246 > - LogOutputList gtests should not use LogConfiguration LogOutputs Seems good to me! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28416#pullrequestreview-3583537463 From asmehra at openjdk.org Tue Dec 16 15:25:11 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 16 Dec 2025 15:25:11 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v5] In-Reply-To: References: Message-ID: <7WJ-q2hb4TcWlWv6xnNm9ucNROivZwyeCQW0lO0sKmw=.64bb1e92-c520-4635-ba63-fa8d8e7a0753@github.com> On Tue, 16 Dec 2025 04:19:32 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra review comment - more fix on tests Marked as reviewed by asmehra (Committer). Update looks good. Thanks for addressing the comments. ------------- PR Review: https://git.openjdk.org/jdk/pull/28796#pullrequestreview-3583669068 PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3661098336 From liach at openjdk.org Tue Dec 16 15:48:03 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 15:48:03 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations Apparently not so: the JVM parses `@Deprecated` and `@Deprecated(forRemoval=true)` from user class files for use by JFR. We should check whether JFR is ok with dropping some of these annotations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3661203773 From jnorlinder at openjdk.org Tue Dec 16 16:26:55 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 16:26:55 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v3] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: <-ZwCTwDC7j83eJRXziZuMv0sR9v0Ae3pcz5Y9Yd22Gs=.2c1aea8f-556b-4fc1-a7f9-25234c992072@github.com> > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Fix indentation - Fix feedback etc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/d3692c7a..2106f289 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=01-02 Stats: 69 lines in 10 files changed: 23 ins; 14 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From jnorlinder at openjdk.org Tue Dec 16 16:26:57 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 16:26:57 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v2] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: <7hNafUO6Tlcyd4H5oUizBedc5nfP_J1uy6XxKs8TFLc=.ff5ac450-ebc0-43bf-972d-0b0c5120b830@github.com> On Tue, 16 Dec 2025 13:38:44 GMT, Jonas Norlinder wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix review comments Thanks for the review Stefan! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28824#issuecomment-3661366906 From jnorlinder at openjdk.org Tue Dec 16 16:54:25 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 16 Dec 2025 16:54:25 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v4] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com> > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Use portable type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/2106f289..456ec1d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From matsaave at openjdk.org Tue Dec 16 18:12:21 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 16 Dec 2025 18:12:21 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v5] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 04:19:32 GMT, Ioi Lam wrote: >> I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. >> >> https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 >> >> This REF improves these functions by: >> >> - Sorting the names of classes and methods >> - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work >> - Print the C++/Java objects that represent classes and methods. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra review comment - more fix on tests Marked as reviewed by matsaave (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28796#pullrequestreview-3584370135 From iklam at openjdk.org Tue Dec 16 18:22:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Dec 2025 18:22:32 GMT Subject: RFR: 8373615: Improve HotSpot debug functions findclass() and findmethod [v5] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:09:34 GMT, Matias Saavedra Silva wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra review comment - more fix on tests > > Marked as reviewed by matsaave (Reviewer). Thank you @matias9927 @ashu-mehra for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28796#issuecomment-3661821161 From iklam at openjdk.org Tue Dec 16 18:22:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Dec 2025 18:22:33 GMT Subject: Integrated: 8373615: Improve HotSpot debug functions findclass() and findmethod In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 16:40:24 GMT, Ioi Lam wrote: > I used the `findclass` and `findmethod` functions in debug.cpp a lot when debugging problems with class metadata. > > https://github.com/openjdk/jdk/blob/6ec36d348b1eaeedb993a905e42650242fac0918/src/hotspot/share/utilities/debug.cpp#L583-L603 > > This REF improves these functions by: > > - Sorting the names of classes and methods > - Allow "." to be used in class names. So both `findclass("java.lang.Object")` and `findclass("java/lang/Object")` would work > - Print the C++/Java objects that represent classes and methods. This pull request has now been integrated. Changeset: b0b42e7e Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/b0b42e7eb14dbe04c9c00e8d1fda139a502f2120 Stats: 186 lines in 3 files changed: 141 ins; 9 del; 36 mod 8373615: Improve HotSpot debug functions findclass() and findmethod Reviewed-by: matsaave, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/28796 From liach at openjdk.org Tue Dec 16 18:54:34 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 18:54:34 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang 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 14 additional commits since the last revision: - Recommended test tweaks - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - Jorn review - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - bracket styles - Doc tweaks - Essay - Spurious change - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - ... and 4 more: https://git.openjdk.org/jdk/compare/57f00286...567e8925 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/b20b7f5b..567e8925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=04-05 Stats: 21935 lines in 436 files changed: 14170 ins; 4911 del; 2854 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From dholmes at openjdk.org Tue Dec 16 20:09:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 20:09:52 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! That seems reasonable. Do you want to add some logging to report the bail out? EDIT: I hadn't seen @liach 's comment about JFR usage. That changes things somewhat. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28674#pullrequestreview-3584763027 From jrose at openjdk.org Tue Dec 16 20:35:17 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 16 Dec 2025 20:35:17 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang 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 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Jorn review > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - bracket styles > - Doc tweaks > - Essay > - Spurious change > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - ... and 4 more: https://git.openjdk.org/jdk/compare/384c62c9...567e8925 Excellent. It does not pay down every bit of technical debt in this area, but it is a significant installment payment. I think `constantFold` is OK as a directory name, although maybe a bit vague (folloing Jorn?s observations). Perhaps `constantFields` or `fieldFolding`. Or (most specifically) `trustedFinalFields`, but I think that is unnecessarily narrow. I suggest `fieldFolding` or `foldFields` or the like. The trusting logic is one way to fold fields, and also the forthcoming `ACC_STRICT_INIT`. There are also proposals to infer strictness in the absence of `ACC_STRICT_INIT`. All of those might have test cases associated with the tests for this feature. We could expect several tests in here eventually, validating the folding properties of various flavors of constant fields. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3584835561 From jsjolen at openjdk.org Tue Dec 16 21:26:46 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Dec 2025 21:26:46 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 20:07:40 GMT, David Holmes wrote: > That seems reasonable. Do you want to add some logging to report the bail out? > > EDIT: I hadn't seen @liach 's comment about JFR usage. That changes things somewhat. I agree. I intend to not integrate this change until that's been sorted out (by me). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3662437599 From liach at openjdk.org Tue Dec 16 21:47:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 21:47:50 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! For context, the JFR feature that uses this was added in https://bugs.openjdk.org/browse/JDK-8211238, which is so far also the only use. It may be possible for JFR to wait for early VM bootstrap and defer annotation parsing to Java core library. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3662519931 From dholmes at openjdk.org Tue Dec 16 22:17:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Dec 2025 22:17:48 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! Backing up a step what exactly is a nested annotation in this context? I assume it is an annotation applied to an annotation? If that is the case then surely no real JDK-defined annotation type will have such nesting beyond at most a couple of levels (if that) - including `@Deprecated`. ?? Or are we worried that user-defined annotations may ultimately use `@Deprecated` and that will be missed if the nesting is too deep? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3662637877 From lmesnik at openjdk.org Tue Dec 16 23:14:28 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Dec 2025 23:14:28 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 11:20:07 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn 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 > - review: restored the assert and fixed the issue caused it to fire > - 8373366: HandshakeState should disallow suspend ops for disabler threads Thank you for explanations. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3585331471 From liach at openjdk.org Tue Dec 16 23:43:47 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 23:43:47 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: <4kA3sXGV8Eey-jKlKXRftu7Q4cj4qA6ald0TX4KgfwM=.8bc7bb3d-06c5-4865-b92b-a40159d91d05@github.com> On Tue, 16 Dec 2025 22:13:46 GMT, David Holmes wrote: > Or are we worried that user-defined annotations may ultimately use `@Deprecated` and that will be missed if the nesting is too deep? Yes, unforunately the annotation format does not allow us to skip a superlong annotation. We must expand all annotations in an array completely to access any single annotation. So if a `@Deprecated` is after a super-deep annotation chain, it would be skipped by the algorithm in this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3662910014 From dholmes at openjdk.org Wed Dec 17 03:35:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Dec 2025 03:35:58 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! test/hotspot/jtreg/runtime/ClassFile/NestedAnnotations.java line 64: > 62: > 63: cw.visitEnd(); > 64: // Does not matter whether the class is hidden, used for simplicity?s sake. Check the actual character used for the apostrophe here. When I grabbed the raw file it failed to compile: `unmappable character (0x92) for encoding UTF-8` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28674#discussion_r2625475271 From dholmes at openjdk.org Wed Dec 17 03:52:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Dec 2025 03:52:50 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 07:39:00 GMT, Johan Sj?len wrote: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! Withdrawing review. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28674#pullrequestreview-3585895695 From sspitsyn at openjdk.org Wed Dec 17 05:57:24 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Dec 2025 05:57:24 GMT Subject: [jdk26] RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers Message-ID: Please, review a jdk 26 regression backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/53ebcdbd029a1c78f8429574b78cecce70c11af2 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by [Patricio Chilano Mateo](https://openjdk.org/census#pchilanomate) and [David Holmes](https://openjdk.org/census#dholmes). I've changed the bug priority to P3 as it is a regression in jdk 26. Should I request a release team approval? ------------- Commit messages: - Backport 53ebcdbd029a1c78f8429574b78cecce70c11af2 Changes: https://git.openjdk.org/jdk/pull/28860/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373627 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28860/head:pull/28860 PR: https://git.openjdk.org/jdk/pull/28860 From sjohanss at openjdk.org Wed Dec 17 07:55:57 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 17 Dec 2025 07:55:57 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v4] In-Reply-To: <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com> Message-ID: <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com> On Tue, 16 Dec 2025 16:54:25 GMT, Jonas Norlinder wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Use portable type A couple of more comments. src/hotspot/share/runtime/os.cpp line 109: > 107: user -= n.user; > 108: system -= n.system; > 109: return *this; You probably want to return a reference here to avoid a copy and `other` or `rhs` (right-hand-side) are more common names for the parameter. Suggestion: CPUTime& CPUTime::operator-=(const CPUTime &other) { user -= other.user; system -= other.system; return *this; src/hotspot/share/services/cpuTimeUsage.cpp line 116: > 114: return detailed_thread_cpu_time_or_zero((Thread*)StringDedup::_processor->_thread); > 115: } > 116: return { 0, 0 }; I would have turned this around, but that's just taste, so skip if you prefer as is: Suggestion: CPUTime CPUTimeUsage::GC::detailed_stringdedup() { if (!UseStringDeduplication) { return {0, 0}; } return detailed_thread_cpu_time_or_zero((Thread*)StringDedup::_processor->_thread); ------------- PR Review: https://git.openjdk.org/jdk/pull/28824#pullrequestreview-3586380176 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2625915649 PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2625944207 From sspitsyn at openjdk.org Wed Dec 17 08:14:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Dec 2025 08:14:41 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: replace fix with just one assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/2b088a62..d1f391b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=02-03 Stats: 13 lines in 5 files changed: 3 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Wed Dec 17 08:25:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Dec 2025 08:25:00 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: replace fix with just one assert Replaced the fix with one simple assert. It did not fire in mach5 tiers 1-6. Will do more test runs though. The suggestion is to keep this assert until we discover it ever failing. If it happens then we could return to the original fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3664195008 From azafari at openjdk.org Wed Dec 17 09:01:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:01:59 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v24] In-Reply-To: References: <-dePf4_Xx0lhAl-KTFEX3i4VAzFivobZ0Jo1vMY7zCc=.f4c0eb29-405b-4ee6-9246-090bf554dd9a@github.com> Message-ID: On Tue, 25 Nov 2025 14:21:36 GMT, Thomas Stuefe wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> pragma fix > > Hi @afshin-zafari , > > In general, I support the goal of this PR, but in its current form, it incurs too high a cost for the added complexity. > > The benefit this PR provides is that, with NMT enabled, we won't catch 1-2-byte overwriters at the end and up to 16-byte underwriters at the start of a block. Underwriters are very rare; overwriters are a lot more common. So, if someone overwrites by one or two bytes, today we only see it if the block is free'd. If someone overwrites three bytes, we already have protection. With your patch, we see also 1-2 byte overwriters. > > But there is a straightforward workaround: just disable NMT. Then, the protection extends right to the borders of the user payload. > > Considering that, the benefit of this PR is there, but it's not huge. Therefore, the complexity cost should be correspondingly low. > > As I wrote before, I don't think poisoning and unpoisoning in this fine-grained fashion is the best approach. It often makes little sense. For example, in os::malloc we have at least one poison-unpoison-poison cycle, possibly more. It would be a lot simpler to do this carefully and only where it's needed: > > - poison the malloc header and footer when we *hand out a malloc'ed block* to the user *at the end of* `os::malloc` or `os::realloc` > - unpoison the header and footer *on the entry* to `os::realloc` and `os::free` to be able to read the MST marker. > > That's it. No more poisoning should be needed. > > NMT block integrity checks should simply not run for ASAN. They make zero sense. They check header corruptions, but who is going to corrupt the canary if the header is now protected by ASAN? In fact, we should not even need to initialize the canaries. > > Basically, that means not calling either one of `check_block_integrity` or `is_valid_malloced_pointer` or `print_block_on_error` if ASAN is enabled. Resp. stubbing them out for ASAN. But I see only one call site that does this. Ideally, one would have a new define like "NMT_BLOCK_INTEGRITY_CHECKS", and guard the NMT integrity checks with that one, and switch it off for ASAN. > > That means that a large part of this PR can be simplified. Many functions can stay as they are, and there should be no need for an RAII object like `AsanPoisoningHelper`. We should only have two poison calls for the header and footer, and two unpoison calls, none of which share the same extent, so RAII can't be used. > > Other than that, there are many cosmetic changes in this PR, e.g., many accessor functions added. That ... Dear reviewers @tstuefe , @jdksjolen and @Arraying , This PR is closed and a [new](https://github.com/openjdk/jdk/pull/28503) one is made from a clean branch. Thanks in advance for your comments on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3664320129 From azafari at openjdk.org Wed Dec 17 09:02:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:02 GMT Subject: Withdrawn: 8369393: NMT: poison the canaries of malloc header under ASAN build In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 08:40:15 GMT, Afshin Zafari wrote: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Wed Dec 17 09:02:19 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:19 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: > Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. > Checking the integrity of memory blocks is off under ASAN builds. 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 eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 - removed extra newlines. - fixes. - inlining - review comments applied. - revision - jtreg test excluded when ASAN is enabled. - 8369393: NMT: poison the malloc header and footer under ASAN build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28503/files - new: https://git.openjdk.org/jdk/pull/28503/files/2bbb96f1..b452979e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=00-01 Stats: 53387 lines in 933 files changed: 33458 ins; 15670 del; 4259 mod Patch: https://git.openjdk.org/jdk/pull/28503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28503/head:pull/28503 PR: https://git.openjdk.org/jdk/pull/28503 From jsjolen at openjdk.org Wed Dec 17 09:02:23 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Dec 2025 09:02:23 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:58:42 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > 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 eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build src/hotspot/share/nmt/mallocHeader.cpp line 80: > 78: } > 79: > 80: MallocHeader* MallocHeader::kill_block(void* memblock) { Put these functions in the inline file instead, seems unnecessary to not get inlining of these calls. src/hotspot/share/nmt/mallocHeader.cpp line 83: > 81: MallocHeader* header = (MallocHeader*)memblock - 1; > 82: ASAN_UNPOISON_MEMORY_REGION(header, sizeof(MallocHeader)); > 83: ASAN_UNPOISON_MEMORY_REGION(header->footer_address(), sizeof(uint16_t)); We spread around the knowledge of the size of the footer being 16 bytes by adding this. We should have one place which tells us the size of the footer (maybe a `constexpr size_t footer_size;` stmt in the class header?) and use that only. src/hotspot/share/nmt/mallocHeader.cpp line 95: > 93: ASAN_POISON_MEMORY_REGION(header, sizeof(MallocHeader)); > 94: return header; > 95: } Here you missed that we shouldn't return the header as it's invalid. src/hotspot/share/runtime/os.cpp line 716: > 714: assert(mem_tag == header->mem_tag(), "weird NMT type mismatch (new:\"%s\" != old:\"%s\")\n", > 715: NMTUtil::tag_to_name(mem_tag), NMTUtil::tag_to_name(header->mem_tag())); > 716: bool success = false; Here's an alternative variant where `success` is assigned before branches and the conditions are given names (instead of having comments). ```c++ // Perform integrity checks on and mark the old block as dead *before* calling the real realloc(3) since it // may invalidate the old block, including its header. assert(mem_tag == header->mem_tag(), "weird NMT type mismatch (new:"%s" != old:"%s")\n", NMTUtil::tag_to_name(mem_tag), NMTUtil::tag_to_name(header->mem_tag())); bool within_malloc_limit = !((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, mem_tag)); bool success = within_malloc_limit; if (success) { void* const new_outer_ptr = permit_forbidden_function::realloc(header, new_outer_size); bool realloc_succeeded = new_outer_ptr != nullptr; success = realloc_succeeded; if (success) { // realloc(3) succeeded, variable header now points to invalid memory and we need to deaccount the old block. MemTracker::deaccount(free_info); // After a successful realloc(3), we account the resized block with its new size // to NMT. void* const new_inner_ptr = MemTracker::record_malloc(new_outer_ptr, size, mem_tag, stack); #ifdef ASSERT if (ZapCHeap && old_size < size) { // We also zap the newly extended region. ::memset((char*)new_inner_ptr + old_size, uninitBlockPad, size - old_size); } #endif rc = new_inner_ptr; } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580015707 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580013449 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580007813 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580006613 From jsjolen at openjdk.org Wed Dec 17 09:02:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Dec 2025 09:02:24 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 10:21:16 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/mallocHeader.cpp line 80: >> >>> 78: } >>> 79: >>> 80: MallocHeader* MallocHeader::kill_block(void* memblock) { >> >> Put these functions in the inline file instead, seems unnecessary to not get inlining of these calls. > > These functions are not templated. When put them in inline file, the definitions will be repeated for every cpp that include the inline file. There are 3 instances of these cpp files. Then, linker complains about duplicate definitions. Did you ensure the header declarations are declared inline? $ cat inline.hpp #ifndef header #define header inline void foo(); #endif $ cat inline.inline.hpp #include "inline.hpp" #include #ifndef inlheader #define inlheader void foo() { printf("Inline definition"); } #endif $ cat a.cpp #include "inline.inline.hpp" #include "a.hpp" void bar() { foo(); } $ cat b.cpp #include "b.hpp" #include "inline.inline.hpp" void baz() { foo(); } $ cat main.cpp #include "b.hpp" #include "a.hpp" int main() { baz(); bar(); return 0; } $ g++ -c main.cpp -o main.o $ g++ -c a.cpp -o a.o $ g++ -c b.cpp -o b.o $ g++ *.o -o myprogram $ ./myprogram Inline definitionInline definition ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2584107717 From azafari at openjdk.org Wed Dec 17 09:02:25 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:25 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 08:28:54 GMT, Johan Sj?len wrote: >> These functions are not templated. When put them in inline file, the definitions will be repeated for every cpp that include the inline file. There are 3 instances of these cpp files. Then, linker complains about duplicate definitions. > > Did you ensure the header declarations are declared inline? > > > $ cat inline.hpp > #ifndef header > #define header > inline void foo(); > #endif > $ cat inline.inline.hpp > #include "inline.hpp" > #include > > #ifndef inlheader > #define inlheader > > void foo() { > printf("Inline definition"); > } > > #endif > $ cat a.cpp > #include "inline.inline.hpp" > #include "a.hpp" > > void bar() { > foo(); > } > $ cat b.cpp > #include "b.hpp" > #include "inline.inline.hpp" > > void baz() { > foo(); > } > $ cat main.cpp > #include "b.hpp" > #include "a.hpp" > > int main() { > baz(); > bar(); > return 0; > } > $ g++ -c main.cpp -o main.o > $ g++ -c a.cpp -o a.o > $ g++ -c b.cpp -o b.o > $ g++ *.o -o myprogram > $ ./myprogram > Inline definitionInline definition Thanks for the detailed sample. The functions are now inlined and moved to inline.hpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2584145556 From azafari at openjdk.org Wed Dec 17 09:02:24 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:24 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 07:42:39 GMT, Johan Sj?len 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 eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 >> - removed extra newlines. >> - fixes. >> - inlining >> - review comments applied. >> - revision >> - jtreg test excluded when ASAN is enabled. >> - 8369393: NMT: poison the malloc header and footer under ASAN build > > src/hotspot/share/nmt/mallocHeader.cpp line 80: > >> 78: } >> 79: >> 80: MallocHeader* MallocHeader::kill_block(void* memblock) { > > Put these functions in the inline file instead, seems unnecessary to not get inlining of these calls. These functions are not templated. When put them in inline file, the definitions will be repeated for every cpp that include the inline file. There are 3 instances of these cpp files. Then, linker complains about duplicate definitions. > src/hotspot/share/nmt/mallocHeader.cpp line 83: > >> 81: MallocHeader* header = (MallocHeader*)memblock - 1; >> 82: ASAN_UNPOISON_MEMORY_REGION(header, sizeof(MallocHeader)); >> 83: ASAN_UNPOISON_MEMORY_REGION(header->footer_address(), sizeof(uint16_t)); > > We spread around the knowledge of the size of the footer being 16 bytes by adding this. We should have one place which tells us the size of the footer (maybe a `constexpr size_t footer_size;` stmt in the class header?) and use that only. Done. > src/hotspot/share/nmt/mallocHeader.cpp line 95: > >> 93: ASAN_POISON_MEMORY_REGION(header, sizeof(MallocHeader)); >> 94: return header; >> 95: } > > Here you missed that we shouldn't return the header as it's invalid. changed func to void. > src/hotspot/share/runtime/os.cpp line 716: > >> 714: assert(mem_tag == header->mem_tag(), "weird NMT type mismatch (new:\"%s\" != old:\"%s\")\n", >> 715: NMTUtil::tag_to_name(mem_tag), NMTUtil::tag_to_name(header->mem_tag())); >> 716: bool success = false; > > Here's an alternative variant where `success` is assigned before branches and the conditions are given names (instead of having comments). > ```c++ > // Perform integrity checks on and mark the old block as dead *before* calling the real realloc(3) since it > // may invalidate the old block, including its header. > assert(mem_tag == header->mem_tag(), "weird NMT type mismatch (new:"%s" != old:"%s")\n", > NMTUtil::tag_to_name(mem_tag), NMTUtil::tag_to_name(header->mem_tag())); > bool within_malloc_limit = !((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, mem_tag)); > bool success = within_malloc_limit; > if (success) { > void* const new_outer_ptr = permit_forbidden_function::realloc(header, new_outer_size); > bool realloc_succeeded = new_outer_ptr != nullptr; > success = realloc_succeeded; > if (success) { > // realloc(3) succeeded, variable header now points to invalid memory and we need to deaccount the old block. > MemTracker::deaccount(free_info); > // After a successful realloc(3), we account the resized block with its new size > // to NMT. > void* const new_inner_ptr = MemTracker::record_malloc(new_outer_ptr, size, mem_tag, stack); > > #ifdef ASSERT > if (ZapCHeap && old_size < size) { > // We also zap the newly extended region. > ::memset((char*)new_inner_ptr + old_size, uninitBlockPad, size - old_size); > } > #endif > > rc = new_inner_ptr; > } > } Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580553465 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580544542 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580542971 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2580540854 From phubner at openjdk.org Wed Dec 17 09:02:27 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 17 Dec 2025 09:02:27 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:58:42 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > 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 eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build src/hotspot/share/nmt/mallocHeader.inline.hpp line 170: > 168: ASAN_UNPOISON_MEMORY_REGION(header->footer_address(), footer_size); > 169: resolve_checked(memblock); > 170: header->mark_block_as_dead(); Unrelated to this PR: is there a reason we `mark_block_as_dead()` but `revive()` as opposed to `mark_block_as_revived()`? src/hotspot/share/runtime/os.cpp line 724: > 722: void* const new_outer_ptr = permit_forbidden_function::realloc(header, new_outer_size); > 723: bool realloc_succeeded = new_outer_ptr != nullptr; > 724: success = realloc_succeeded; Nit: `realloc_succeeded` is only used here. Got briefly confused why there were two successes while reviewing. Suggestion: success = new_outer_ptr != nullptr; // reallocation succeeded src/hotspot/share/runtime/os.cpp line 739: > 737: #endif > 738: > 739: success = true; Redundant assignment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585281027 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585259935 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585267933 From azafari at openjdk.org Wed Dec 17 09:02:28 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:28 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:11:08 GMT, Paul H?bner 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 eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 >> - removed extra newlines. >> - fixes. >> - inlining >> - review comments applied. >> - revision >> - jtreg test excluded when ASAN is enabled. >> - 8369393: NMT: poison the malloc header and footer under ASAN build > > src/hotspot/share/nmt/mallocHeader.inline.hpp line 170: > >> 168: ASAN_UNPOISON_MEMORY_REGION(header->footer_address(), footer_size); >> 169: resolve_checked(memblock); >> 170: header->mark_block_as_dead(); > > Unrelated to this PR: is there a reason we `mark_block_as_dead()` but `revive()` as opposed to `mark_block_as_revived()`? I prefer `mark_block_as_alive()` with no assertion on being already `dead`. `revive()` with assertion that it has to be `dead` already. Thoughts? > src/hotspot/share/runtime/os.cpp line 724: > >> 722: void* const new_outer_ptr = permit_forbidden_function::realloc(header, new_outer_size); >> 723: bool realloc_succeeded = new_outer_ptr != nullptr; >> 724: success = realloc_succeeded; > > Nit: `realloc_succeeded` is only used here. Got briefly confused why there were two successes while reviewing. > Suggestion: > > success = new_outer_ptr != nullptr; // reallocation succeeded Suggestion accepted. > src/hotspot/share/runtime/os.cpp line 739: > >> 737: #endif >> 738: >> 739: success = true; > > Redundant assignment? Good catch! removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585403118 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585406002 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585402949 From phubner at openjdk.org Wed Dec 17 09:02:28 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 17 Dec 2025 09:02:28 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:43:45 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/mallocHeader.inline.hpp line 170: >> >>> 168: ASAN_UNPOISON_MEMORY_REGION(header->footer_address(), footer_size); >>> 169: resolve_checked(memblock); >>> 170: header->mark_block_as_dead(); >> >> Unrelated to this PR: is there a reason we `mark_block_as_dead()` but `revive()` as opposed to `mark_block_as_revived()`? > > I prefer `mark_block_as_alive()` with no assertion on being already `dead`. `revive()` with assertion that it has to be `dead` already. Thoughts? Works for me. But I see no assertion in the current code that asserts it has to be dead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585410681 From azafari at openjdk.org Wed Dec 17 09:02:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 17 Dec 2025 09:02:29 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 14:45:35 GMT, Paul H?bner wrote: >> I prefer `mark_block_as_alive()` with no assertion on being already `dead`. `revive()` with assertion that it has to be `dead` already. Thoughts? > > Works for me. But I see no assertion in the current code that asserts it has to be dead. The asserts in revive() are removed in this PR at this [commit](https://github.com/openjdk/jdk/pull/28503/commits/4ebd70290f148e4613506605eadd05bc480a7d5f#diff-ea9fba8b125ca1dea6607148566da0913ff8f4eafbee79cb9a5a3b56801d3947:~:text=MallocHeader%3A%3Arevive()%20%7B-,assert(_canary%20%3D%3D%20_header_canary_dead_mark%2C%20%22must%20be%20dead%22)%3B,(assert(_alt_canary%20%3D%3D%20_header_alt_canary_dead_mark%2C%20%22must%20be%20dead%22))%3B,-_canary%20%3D%20_header_canary_live_mark%3B). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2585863405 From jnorlinder at openjdk.org Wed Dec 17 09:55:46 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 17 Dec 2025 09:55:46 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v5] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Overload += too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/456ec1d4..fa31b86c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=03-04 Stats: 17 lines in 3 files changed: 7 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From aturbanov at openjdk.org Wed Dec 17 10:43:54 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 17 Dec 2025 10:43:54 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: Message-ID: <9vaoIacqeQtaDtLMMicjQ5L2TqbqgPFasZBuIT7-t2M=.4ad31447-cf97-4081-bcdc-65c57baf88af@github.com> On Mon, 15 Dec 2025 14:27:14 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. > > Thanks! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 293: > 291: */ > 292: public static void removeDockerImage(String imageNameAndTag) throws Exception { > 293: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { Suggestion: if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28826#discussion_r2626526625 From tschatzl at openjdk.org Wed Dec 17 11:51:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Dec 2025 11:51:21 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v5] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Tue, 16 Dec 2025 11:48:59 GMT, Jonas Norlinder wrote: >> src/hotspot/os/linux/os_linux.hpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. >> >> The copyright change seems to be the only change in this file, and should be reverted. > > File was recently edited but didn't update copyright year. I can file a separate JBS and PR for that line if you prefer. It's okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2626734639 From tschatzl at openjdk.org Wed Dec 17 11:51:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Dec 2025 11:51:26 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v5] In-Reply-To: References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: On Wed, 17 Dec 2025 09:55:46 GMT, Jonas Norlinder wrote: >> GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. >> >> This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. >> >> A minimal example: >> >> public static void main(String[] args) { >> // Initial GC that clean up start-up garbage etc. >> System.gc(); >> >> for (int i = 1; i <= 128; i++) { >> addLoad(); // Creates 128 threads, that spins in a loop >> try { >> Thread.sleep(2000); >> } catch (InterruptedException e) {} >> System.gc(); >> } >> System.exit(0); >> } >> >> where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. >> >> In such scenario we can observe using G1 >> >> >> [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s >> [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s >> [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s >> [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s >> [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s >> ... >> [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s >> [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s >> [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s >> [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s >> >> >> Since the Java code does not do anything the time should be close to 0. >> >> # Implementation Comment >> >> Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Overload += too src/hotspot/share/runtime/os.hpp line 173: > 171: public: > 172: int64_t user; > 173: int64_t system; If everything is public in this class, consider using a `struct` instead. Also per style guidelines, even public class/struct members should use the underscore prefix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28824#discussion_r2626748257 From syan at openjdk.org Wed Dec 17 11:52:45 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 17 Dec 2025 11:52:45 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. > > Thanks! SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add an whitespace after if Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28826/files - new: https://git.openjdk.org/jdk/pull/28826/files/d66b7695..ae10ac54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28826/head:pull/28826 PR: https://git.openjdk.org/jdk/pull/28826 From alanb at openjdk.org Wed Dec 17 12:43:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Dec 2025 12:43:11 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang 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 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Jorn review > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - bracket styles > - Doc tweaks > - Essay > - Spurious change > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - ... and 4 more: https://git.openjdk.org/jdk/compare/c6348e62...567e8925 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3587543908 From mbaesken at openjdk.org Wed Dec 17 14:08:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 Dec 2025 14:08:23 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures Message-ID: In case of failures the jtreg test StackWalkNativeToJava misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . The other checks ` output.shouldNotContain` print already the diagnostic summary of output. ------------- Commit messages: - JDK-8373876 Changes: https://git.openjdk.org/jdk/pull/28871/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373876 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28871/head:pull/28871 PR: https://git.openjdk.org/jdk/pull/28871 From mdoerr at openjdk.org Wed Dec 17 14:17:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 17 Dec 2025 14:17:01 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 14:00:09 GMT, Matthias Baesken wrote: > In case of failures the jtreg test StackWalkNativeToJava misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . > The other checks ` output.shouldNotContain` print already the diagnostic summary of output. Makes sense! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java line 77: > 75: } > 76: > 77: assertTrue(res.length - 1 == 2, res.length - 1); Now, the check is duplicated. Never mind, it's just a test. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28871#pullrequestreview-3587951075 PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2627234805 From mbaesken at openjdk.org Wed Dec 17 14:21:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 Dec 2025 14:21:22 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: <783R9daANGIguTCxXuU7v7vlnjhbRgXHP5oJsNl3HAU=.9f9a4f54-f147-4ea2-9e56-5d125b8530ed@github.com> On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . @erikj79 , @dholmes-ora any comments ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28792#issuecomment-3665571403 From lmesnik at openjdk.org Wed Dec 17 15:49:02 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Dec 2025 15:49:02 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: replace fix with just one assert I think better replaces text with something non-TMP. Also, might be worth add comment for ThreadSelfSuspensionHandshakeClosure somewhere. This comment should explain the connection of this ThreadSelfSuspension handshake and SuspendThreadHandshake. Ie there shouldn't safepoint between `SuspendResumeManager::suspend_with_handshake` and processing ThreadSelfSuspensionHandshake. It should help to understand why suspended thread thread can't be in disabler now. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3588376322 From pchilanomate at openjdk.org Wed Dec 17 16:12:02 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 17 Dec 2025 16:12:02 GMT Subject: [jdk26] RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 05:47:31 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 regression backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/53ebcdbd029a1c78f8429574b78cecce70c11af2 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Patricio Chilano Mateo](https://openjdk.org/census#pchilanomate) and [David Holmes](https://openjdk.org/census#dholmes). > I've changed the bug priority to P3 as it is a regression in jdk 26. Should I request a release team approval? Marked as reviewed by pchilanomate (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28860#pullrequestreview-3588473665 From sspitsyn at openjdk.org Wed Dec 17 19:58:27 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Dec 2025 19:58:27 GMT Subject: [jdk26] RFR: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 05:47:31 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 regression backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/53ebcdbd029a1c78f8429574b78cecce70c11af2 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Patricio Chilano Mateo](https://openjdk.org/census#pchilanomate) and [David Holmes](https://openjdk.org/census#dholmes). > I've changed the bug priority to P3 as it is a regression in jdk 26. Should I request a release team approval? Thank you for review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28860#issuecomment-3666921320 From sspitsyn at openjdk.org Wed Dec 17 19:58:28 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Dec 2025 19:58:28 GMT Subject: [jdk26] Integrated: 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 05:47:31 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 regression backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/53ebcdbd029a1c78f8429574b78cecce70c11af2 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Patricio Chilano Mateo](https://openjdk.org/census#pchilanomate) and [David Holmes](https://openjdk.org/census#dholmes). > I've changed the bug priority to P3 as it is a regression in jdk 26. Should I request a release team approval? This pull request has now been integrated. Changeset: 248519db Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/248519db4a3f8bd03cf16ab385dc2a67c8c82b22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8373627: assert(!is_vthread_transition_disabler()) failed: no suspend allowed for vthread transition disablers Reviewed-by: pchilanomate Backport-of: 53ebcdbd029a1c78f8429574b78cecce70c11af2 ------------- PR: https://git.openjdk.org/jdk/pull/28860 From dholmes at openjdk.org Wed Dec 17 20:58:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Dec 2025 20:58:13 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 14:00:09 GMT, Matthias Baesken wrote: > In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . > The other checks ` output.shouldNotContain` print already the diagnostic summary of output. Not sure there isn't a better way for this test to check what it is checking but this seems okay - modulo pre-existing weirdness. test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java line 73: > 71: output.shouldNotContain("[error occurred during error reporting (printing native stack"); > 72: String[] res = output.getOutput().split("StackWalkNativeToJava\\$TestNativeToJavaNative\\.callNativeMethod\\(\\)V"); > 73: if (res.length - 1 != 2) { Pre-existing but this is a weird formulation - it should just be `res.length != 3`. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28871#pullrequestreview-3589613271 PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2628606662 From dholmes at openjdk.org Wed Dec 17 21:21:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Dec 2025 21:21:29 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . Seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28792#pullrequestreview-3589713284 From dholmes at openjdk.org Wed Dec 17 21:32:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Dec 2025 21:32:33 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: <6Suuy1lWRKVyMBTgqxecKvIoHRnZwakNswyhHR09CFs=.3addbcfb-628c-4d61-b29b-83964436cc1b@github.com> On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 I tested tiers 1-6 with the simplified fix and nothing has turned up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667274570 From liach at openjdk.org Thu Dec 18 00:03:10 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 00:03:10 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: Message-ID: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Move the test to a core library purposed directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/567e8925..16db9901 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From liach at openjdk.org Thu Dec 18 00:03:13 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 00:03:13 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: <7WM2llDmHIma5F6pRh7EIdeubuz7qI-uTqvSsqmfug4=.6ce794e4-c270-4d83-a481-5ac75a71afc9@github.com> On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang 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 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Jorn review > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - bracket styles > - Doc tweaks > - Essay > - Spurious change > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - ... and 4 more: https://git.openjdk.org/jdk/compare/0095e40a...567e8925 After offline discussion, we have decided to move this test to `compiler/corelibs`, which will become the future home for various compiler framework-based tests verifying the behavior of core library APIs once they are compiled. For example, this package may add more constant folding verifications (such as for Lazy Constants) or loop hoisting verification for FFM API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3667634659 From rrich at openjdk.org Thu Dec 18 00:14:21 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 18 Dec 2025 00:14:21 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 Thanks! Same with my testing. I doubt that I'll find the time to write a reproducer though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667664024 From dholmes at openjdk.org Thu Dec 18 01:16:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 01:16:14 GMT Subject: RFR: 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 Message-ID: If the SR signal is delivered late, there is a small window where the JavaThread destructor has run (and so the referenced assert will fail), but the Thread destructor has not yet reach the point where `is_terminated` returns true, and so we proceed to the assertion, that then fails. The simple fix is to move the assertion into the branch for an active suspension request, which guarantees we can be executing destructors yet. See JBS for gory details. Testing: tiers 1-3 (sanity) Thanks ------------- Commit messages: - 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 Changes: https://git.openjdk.org/jdk/pull/28883/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28883&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373837 Stats: 11 lines in 1 file changed: 5 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28883.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28883/head:pull/28883 PR: https://git.openjdk.org/jdk/pull/28883 From dholmes at openjdk.org Thu Dec 18 01:21:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 01:21:17 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v2] In-Reply-To: References: Message-ID: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > UPDATE: we are now employing a much simpler solution. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 David Holmes 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: - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region - Merge branch 'master' into 8369515-jni-critical - Revert "8369515" This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. - 8369515 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28779/files - new: https://git.openjdk.org/jdk/pull/28779/files/3beb23cc..b96a9bc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=00-01 Stats: 12369 lines in 431 files changed: 7742 ins; 1537 del; 3090 mod Patch: https://git.openjdk.org/jdk/pull/28779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779 PR: https://git.openjdk.org/jdk/pull/28779 From dholmes at openjdk.org Thu Dec 18 01:43:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 01:43:50 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions Message-ID: To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. The mechanism for this already exists courtesy of the virtual thread support. Testing: - tiers 1 - 6 sanity ------------- Commit messages: - 8373839: Disable JVM TI suspension during JNI critical regions Changes: https://git.openjdk.org/jdk/pull/28884/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373839 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28884/head:pull/28884 PR: https://git.openjdk.org/jdk/pull/28884 From qamai at openjdk.org Thu Dec 18 03:41:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 03:41:54 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Is this annotation just for constant folding of final fields? That seems pretty limited. Can we have it to notify that the final fields of a class can be treated as strict fields? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668189051 From liach at openjdk.org Thu Dec 18 03:54:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 03:54:53 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Yes, this is the purpose of this annotation for now. Unfortunately the JDK can only use strict after it leaves preview, so I think this is necessary to bridge the gap during this period. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668227064 From qamai at openjdk.org Thu Dec 18 04:07:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 04:07:54 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory If the JDK wants to use strict then it can, it is the user code which does not have access to strict fields, isn't it? What I mean is why isn't this annotation stronger so we can improve the accesses into currently-trusted fields, too (`MemorySegment` fields for example). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668255154 From dholmes at openjdk.org Thu Dec 18 04:36:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 04:36:54 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:14:41 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: replace fix with just one assert If all you are doing is adding an assert then the JBS issue and the PR need a considerable rewrite to explain things. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3668324985 From liach at openjdk.org Thu Dec 18 04:54:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 04:54:05 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory What do you mean by this annotation being "stronger"? This annotation uses class granularity because javac generates synthetic fields like local variable captures, which cannot be annotated by field annotations. The JDK will have to resort to an annotation, because JDK class files cannot use preview features because they need to be able to run with preview features off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668363917 From qamai at openjdk.org Thu Dec 18 05:00:56 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 05:00:56 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668379612 From syan at openjdk.org Thu Dec 18 06:30:00 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Dec 2025 06:30:00 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan wrote: >> Hi all, >> >> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. >> >> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. >> >> Thanks! > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add an whitespace after if > > Co-authored-by: Andrey Turbanov Change has been verified locally on linux-x64. This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. Verify command: j -Djdk.test.docker.image.name=jdk-build -Djdk.test.docker.image.version=11 -conc:20 $(git status -s | awk '{print $NF}' | sed "/ockerTestUtils.java/d" | xargs) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3668601523 From syan at openjdk.org Thu Dec 18 06:35:53 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Dec 2025 06:35:53 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v5] In-Reply-To: References: Message-ID: <5LBXSwk-8ojgURW0-eu4YGuTiyphcdRQPLH3ED8HVig=.00e5adac-be70-4880-b637-d23b9fd441bb@github.com> On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan wrote: >> Hi all, >> >> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: >> >> >> page_size = 64K >> _java_thread_min_stack_allowed = 72K >> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K >> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K >> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K >> >> >> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java >> >> Change has been verified locally both on linux-x64 and linux-aarch64. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java > - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes Looking for second reviewer since touch the hotspot files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3668617941 From mbaesken at openjdk.org Thu Dec 18 08:28:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Dec 2025 08:28:12 GMT Subject: Integrated: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . This pull request has now been integrated. Changeset: a31e6e0d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a31e6e0d3b806b3b1935d3b71dd0b111bc5fddf1 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp Reviewed-by: mdoerr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28792 From mbaesken at openjdk.org Thu Dec 18 08:28:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Dec 2025 08:28:11 GMT Subject: RFR: 8373593: Support latest VS2026 MSC_VER in abstract_vm_version.cpp In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 14:22:47 GMT, Matthias Baesken wrote: > VS2026 has been released recently and support in the OpenJDK build has been introduced with [JDK-8371967](https://bugs.openjdk.org/browse/JDK-8371967). The compiler has a new `_MSC_VER = 1950 ` which should be covered in abstract_vm_version.cpp . Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28792#issuecomment-3668997459 From mbaesken at openjdk.org Thu Dec 18 08:51:58 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Dec 2025 08:51:58 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: > In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . > The other checks ` output.shouldNotContain` print already the diagnostic summary of output. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust check a little as suggested by David ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28871/files - new: https://git.openjdk.org/jdk/pull/28871/files/23309329..a703276f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28871&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28871&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28871/head:pull/28871 PR: https://git.openjdk.org/jdk/pull/28871 From jnorlinder at openjdk.org Thu Dec 18 08:55:54 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 18 Dec 2025 08:55:54 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v6] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Address accuracy in high freqency sampling on Linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/fa31b86c..86853846 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=04-05 Stats: 98 lines in 10 files changed: 61 ins; 16 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From jnorlinder at openjdk.org Thu Dec 18 09:05:57 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 18 Dec 2025 09:05:57 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v7] In-Reply-To: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> Message-ID: > GCTraceCPUTime is used by Serial, Parallel and G1 to estimate GC CPU time spent during safepoints. It estimates CPU time by sampling the CPU time for entire process by using `os::getTimesSecs`. > > This will not be correct if native code from e.g. JNI is used and is incurring a high load on the machine as native code is not paused during safepoints. > > A minimal example: > > public static void main(String[] args) { > // Initial GC that clean up start-up garbage etc. > System.gc(); > > for (int i = 1; i <= 128; i++) { > addLoad(); // Creates 128 threads, that spins in a loop > try { > Thread.sleep(2000); > } catch (InterruptedException e) {} > System.gc(); > } > System.exit(0); > } > > where addLoad() is a native call to a C++ program that create 128 pthreads that busy-spin forever with the largest nice value allowed. > > In such scenario we can observe using G1 > > > [0.026s][info][gc,cpu] GC(0) User=0.00s Sys=0.00s Real=0.01s > [2.103s][info][gc,cpu] GC(1) User=0.89s Sys=0.00s Real=0.03s > [4.129s][info][gc,cpu] GC(2) User=0.51s Sys=0.00s Real=0.01s > [6.195s][info][gc,cpu] GC(3) User=1.72s Sys=0.00s Real=0.06s > [8.244s][info][gc,cpu] GC(4) User=1.46s Sys=0.00s Real=0.05s > ... > [201.191s][info][gc,cpu] GC(76) User=37.91s Sys=0.00s Real=1.19s > [205.064s][info][gc,cpu] GC(77) User=52.44s Sys=0.00s Real=1.64s > [208.068s][info][gc,cpu] GC(78) User=23.49s Sys=0.00s Real=0.74s > [211.795s][info][gc,cpu] GC(79) User=46.96s Sys=0.00s Real=1.47s > > > Since the Java code does not do anything the time should be close to 0. > > # Implementation Comment > > Total CPU time for GC operations on the VM thread is obtained by cumulatively adding to a counter. Since system time is calculated (on Linux) with `total - user` is value contains a small error delta. If we continuously increment a value this error would grow to an unacceptable level. Therefore, the implementation will rely on the fact that no other VM operation may run during GC safepoint, making it safe to query the VM thread for it's detailed CPU time at the start and end of GC pause. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28824/files - new: https://git.openjdk.org/jdk/pull/28824/files/86853846..a4af8042 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28824&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28824/head:pull/28824 PR: https://git.openjdk.org/jdk/pull/28824 From jnorlinder at openjdk.org Thu Dec 18 09:08:44 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 18 Dec 2025 09:08:44 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v4] In-Reply-To: <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com> <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com> Message-ID: <2zEeF741Ieu8YahSZftq_p7HC83GZ8iB0o_7xiRg4Uo=.85ee53e9-87e9-4093-b4c9-96af1f70a32c@github.com> On Wed, 17 Dec 2025 07:53:28 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Use portable type > > A couple of more comments. Huge thanks to @kstefanj that found that values could appear as <0 where GC runs very frequent. I tracked the error down due to the technical limitations of how we can get system time on Linux for a thread. Since it requires two calls and taking the difference (total - user), there is a risk that these are out of sync. This can be resolved by using getrusage which values are in sync. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28824#issuecomment-3669221571 From aph at openjdk.org Thu Dec 18 09:14:00 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Dec 2025 09:14:00 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 [v5] In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan wrote: >> Hi all, >> >> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: >> >> >> page_size = 64K >> _java_thread_min_stack_allowed = 72K >> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K >> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K >> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K >> >> >> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java >> >> Change has been verified locally both on linux-x64 and linux-aarch64. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java > - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3591597450 From fbredberg at openjdk.org Thu Dec 18 09:22:39 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 18 Dec 2025 09:22:39 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v2] In-Reply-To: References: Message-ID: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com> On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes wrote: >> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. >> >> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes 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: > > - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region > - Merge branch 'master' into 8369515-jni-critical > - Revert "8369515" > > This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. > - 8369515 Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you! ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3591638468 From fbredberg at openjdk.org Thu Dec 18 13:44:25 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 18 Dec 2025 13:44:25 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity This is a nice fix, regardless of my opinion about pre/post-decrement. Thank you David. src/hotspot/share/runtime/javaThread.hpp line 966: > 964: void exit_critical() { > 965: assert(Thread::current() == this, "this must be current thread"); > 966: if (_jni_active_critical-- == 1) { Suggestion: if (--_jni_active_critical == 0) { I know my suggested line really does the same as yours, but this way I feel it's easier to see that we re-enable suspension when the number of active critical regions are down to 0. I.e. I prefer pre-decrement and compare to 0, vs. post-decrement and compare to 1. ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28884#pullrequestreview-3593033724 PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2631125115 From fbredberg at openjdk.org Thu Dec 18 15:36:26 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 18 Dec 2025 15:36:26 GMT Subject: RFR: 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 In-Reply-To: References: Message-ID: <_o8wSy7me_O7l46tV7QxL6Xsxj-KoJn_zTULx13yWQY=.cce76820-56e4-4da2-808c-34b4ae0fe684@github.com> On Thu, 18 Dec 2025 01:09:24 GMT, David Holmes wrote: > If the SR signal is delivered late, there is a small window where the JavaThread destructor has run (and so the referenced assert will fail), but the Thread destructor has not yet reached the point where `is_terminated` returns true, and so we proceed to the assertion, that then fails. The simple fix is to move the assertion into the branch for an active suspension request, which guarantees we **can't** be executing destructors yet. See JBS for gory details. > > EDIT: s/can/can't/ > > Testing: tiers 1-3 (sanity) > > Thanks Looks good to me. ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28883#pullrequestreview-3593613685 From lmesnik at openjdk.org Thu Dec 18 16:13:44 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Dec 2025 16:13:44 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity The fix looks good. Do you think it makes a sense to add regression test? ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28884#pullrequestreview-3593771798 From liach at openjdk.org Thu Dec 18 16:28:36 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 16:28:36 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 04:58:38 GMT, Quan Anh Mai wrote: > So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. No. We currently cannot enforce such final fields to be all written before the `Object::` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::` either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671092060 From qamai at openjdk.org Thu Dec 18 16:49:25 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 16:49:25 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 16:25:29 GMT, Chen Liang wrote: >> What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. > >> So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. > > No. We currently cannot enforce such final fields to be all written before the `Object::` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::` either. @liach I don't think we need such a condition, we only need to ensure that the fields are not read from and the object does not escape to memory before the termination of ``. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671176336 From mbaesken at openjdk.org Thu Dec 18 16:56:54 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Dec 2025 16:56:54 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 08:51:58 GMT, Matthias Baesken wrote: >> In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . >> The other checks ` output.shouldNotContain` print already the diagnostic summary of output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust check a little as suggested by David Hi, seems I need a re review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28871#issuecomment-3671210618 From liach at openjdk.org Thu Dec 18 18:12:59 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 18:12:59 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory We can port JDK-8354068 to mainline, but I think this is better done as a separate effort from the introduction of this annotation. This patch is more focused on the jdk implications. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671501119 From mdoerr at openjdk.org Thu Dec 18 18:27:28 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 18 Dec 2025 18:27:28 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 08:51:58 GMT, Matthias Baesken wrote: >> In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . >> The other checks ` output.shouldNotContain` print already the diagnostic summary of output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust check a little as suggested by David Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28871#pullrequestreview-3594391324 From pchilanomate at openjdk.org Thu Dec 18 19:01:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 18 Dec 2025 19:01:58 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v2] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes wrote: >> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. >> >> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes 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: > > - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region > - Merge branch 'master' into 8369515-jni-critical > - Revert "8369515" > > This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. > - 8369515 Looks good to me. FTR we are not processing this special exit condition when transitioning from `_thread_blocked` to `_thread_in_vm` already, so I would assume it should be also okay for any native->vm transition. src/hotspot/share/runtime/javaThread.cpp line 1057: > 1055: // We mustn't block for object deopt if the thread is > 1056: // currently executing in a JNI critical region, as that > 1057: // can cause deadlock because the GCLocker is held. I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"? ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3594584056 PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3671778255 PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2632288550 From pchilanomate at openjdk.org Thu Dec 18 19:29:12 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 18 Dec 2025 19:29:12 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3671897422 From dholmes at openjdk.org Thu Dec 18 21:18:25 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 21:18:25 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 13:32:53 GMT, Fredrik Bredberg wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > src/hotspot/share/runtime/javaThread.hpp line 966: > >> 964: void exit_critical() { >> 965: assert(Thread::current() == this, "this must be current thread"); >> 966: if (_jni_active_critical-- == 1) { > > Suggestion: > > if (--_jni_active_critical == 0) { > > I know my suggested line really does the same as yours, but this way I feel it's easier to see that we re-enable suspension when the number of active critical regions are down to 0. I.e. I prefer pre-decrement and compare to 0, vs. post-decrement and compare to 1. I prefer to view the transitions on the current count as being zero and one, rather than the post-count being one and zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2632659327 From dholmes at openjdk.org Thu Dec 18 21:29:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 21:29:53 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. Thanks for looking at this @pchilano > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else. > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672311790 From dholmes at openjdk.org Thu Dec 18 21:29:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 21:29:55 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 16:10:54 GMT, Leonid Mesnik wrote: > The fix looks good. Do you think it makes a sense to add regression test? Thanks for looking at this @lmesnik . It would be nice to have a regression test for this but constructing one is beyond my ability to write JVM TI programs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672320422 From dholmes at openjdk.org Thu Dec 18 21:29:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Dec 2025 21:29:56 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 13:41:21 GMT, Fredrik Bredberg wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > This is a nice fix, regardless of my opinion about pre/post-decrement. Thank you David. Thanks for looking at this @fbredber ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672324023 From pchilanomate at openjdk.org Thu Dec 18 23:27:53 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 18 Dec 2025 23:27:53 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. > Thanks for looking at this @pchilano > > > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. > > This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else. > It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead. > > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. > > So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition. > It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672704793 From coleenp at openjdk.org Thu Dec 18 23:39:32 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Dec 2025 23:39:32 GMT Subject: RFR: 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:09:24 GMT, David Holmes wrote: > If the SR signal is delivered late, there is a small window where the JavaThread destructor has run (and so the referenced assert will fail), but the Thread destructor has not yet reached the point where `is_terminated` returns true, and so we proceed to the assertion, that then fails. The simple fix is to move the assertion into the branch for an active suspension request, which guarantees we **can't** be executing destructors yet. See JBS for gory details. > > EDIT: s/can/can't/ > > Testing: tiers 1-3 (sanity) > > Thanks This is a small window for a race. The fix looks reasonable. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28883#pullrequestreview-3595688984 From kbarrett at openjdk.org Fri Dec 19 00:02:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 19 Dec 2025 00:02:01 GMT Subject: RFR: 8373208: Make Atomic class template constant initializable [v2] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 08:22:18 GMT, Stefan Karlsson wrote: >> Kim Barrett 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 constinit-atomic >> - constexpr Atomc ctors > > Marked as reviewed by stefank (Reviewer). Thanks for reviews @stefank and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/28711#issuecomment-3672788873 From kbarrett at openjdk.org Fri Dec 19 00:05:29 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 19 Dec 2025 00:05:29 GMT Subject: Integrated: 8373208: Make Atomic class template constant initializable In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 00:01:11 GMT, Kim Barrett wrote: > Please review this change to Atomic to meet the requirements for constant > initialization in cases where the value type provides the requisite support. > This ensures that in such cases dynamic initialization won't even be > considered a possibility when initialized with constant arguments. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 62316465 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/623164651cd35870aa438a3f6d546994f3d1753c Stats: 27 lines in 1 file changed: 13 ins; 1 del; 13 mod 8373208: Make Atomic class template constant initializable Reviewed-by: stefank, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28711 From dholmes at openjdk.org Fri Dec 19 01:55:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 01:55:29 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v3] In-Reply-To: References: Message-ID: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > UPDATE: we are now employing a much simpler solution. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 David Holmes has updated the pull request incrementally with one additional commit since the last revision: Exapnd comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28779/files - new: https://git.openjdk.org/jdk/pull/28779/files/b96a9bc2..9bc8a3f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779 PR: https://git.openjdk.org/jdk/pull/28779 From dholmes at openjdk.org Fri Dec 19 01:55:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 01:55:32 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v2] In-Reply-To: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com> References: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com> Message-ID: On Thu, 18 Dec 2025 09:20:06 GMT, Fredrik Bredberg wrote: >> David Holmes 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: >> >> - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region >> - Merge branch 'master' into 8369515-jni-critical >> - Revert "8369515" >> >> This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. >> - 8369515 > > Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you! Thanks for the reviews @fbredber and @pchilano ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3673102814 From dholmes at openjdk.org Fri Dec 19 01:55:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 01:55:34 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v2] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:56:19 GMT, Patricio Chilano Mateo wrote: >> David Holmes 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: >> >> - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region >> - Merge branch 'master' into 8369515-jni-critical >> - Revert "8369515" >> >> This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. >> - 8369515 > > src/hotspot/share/runtime/javaThread.cpp line 1057: > >> 1055: // We mustn't block for object deopt if the thread is >> 1056: // currently executing in a JNI critical region, as that >> 1057: // can cause deadlock because the GCLocker is held. > > I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"? I have reworded and expanded the last part. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2633282213 From dholmes at openjdk.org Fri Dec 19 01:57:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 01:57:03 GMT Subject: RFR: 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 In-Reply-To: <_o8wSy7me_O7l46tV7QxL6Xsxj-KoJn_zTULx13yWQY=.cce76820-56e4-4da2-808c-34b4ae0fe684@github.com> References: <_o8wSy7me_O7l46tV7QxL6Xsxj-KoJn_zTULx13yWQY=.cce76820-56e4-4da2-808c-34b4ae0fe684@github.com> Message-ID: On Thu, 18 Dec 2025 15:33:38 GMT, Fredrik Bredberg wrote: >> If the SR signal is delivered late, there is a small window where the JavaThread destructor has run (and so the referenced assert will fail), but the Thread destructor has not yet reached the point where `is_terminated` returns true, and so we proceed to the assertion, that then fails. The simple fix is to move the assertion into the branch for an active suspension request, which guarantees we **can't** be executing destructors yet. See JBS for gory details. >> >> EDIT: s/can/can't/ >> >> Testing: tiers 1-3 (sanity) >> >> Thanks > > Looks good to me. Thanks for the reviews @fbredber and @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28883#issuecomment-3673108331 From dholmes at openjdk.org Fri Dec 19 01:57:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 01:57:04 GMT Subject: Integrated: 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:09:24 GMT, David Holmes wrote: > If the SR signal is delivered late, there is a small window where the JavaThread destructor has run (and so the referenced assert will fail), but the Thread destructor has not yet reached the point where `is_terminated` returns true, and so we proceed to the assertion, that then fails. The simple fix is to move the assertion into the branch for an active suspension request, which guarantees we **can't** be executing destructors yet. See JBS for gory details. > > EDIT: s/can/can't/ > > Testing: tiers 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: f0add885 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/f0add8854501f13b611220804dcb54d118c43717 Stats: 11 lines in 1 file changed: 5 ins; 5 del; 1 mod 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 Reviewed-by: fbredberg, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/28883 From dholmes at openjdk.org Fri Dec 19 02:11:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 02:11:56 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity FTR I don't think "returning a copy" is an option - as I tried to point out in the other JBS issue. It would have to be based on there being a debugger attached, but with dynamic attach for the debugger you'd have to wait for an existing critical region to complete when attaching. If we have to wait for something then probably better just to wait for the thread in the critical region that we are trying to suspend. But doing a busy-wait (`while (t->in_critical()) SpinYield()`) in `SuspendThreadHandshakeClosure` seems a bit hackish. I had hoped the "disable suspend" mechanism would be simple and elegant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3673153689 From dholmes at openjdk.org Fri Dec 19 02:18:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 02:18:52 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 08:51:58 GMT, Matthias Baesken wrote: >> In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . >> The other checks ` output.shouldNotContain` print already the diagnostic summary of output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust check a little as suggested by David Changes requested by dholmes (Reviewer). test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java line 77: > 75: } > 76: > 77: assertTrue(res.length == 3, res.length - 1); Suggestion: assertTrue(res.length == 3, res.length); You need to adjust both parts ------------- PR Review: https://git.openjdk.org/jdk/pull/28871#pullrequestreview-3596332734 PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2633325747 From syan at openjdk.org Fri Dec 19 02:25:02 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 02:25:02 GMT Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 02:57:30 GMT, David Holmes wrote: >> Hi all, >> >> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: >> >> >> page_size = 64K >> _java_thread_min_stack_allowed = 72K >> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K >> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K >> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K >> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K >> >> >> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java >> >> Change has been verified locally both on linux-x64 and linux-aarch64. > > A more resilient change would be to add a WhiteBox API to obtain the minimum stack for the actual platform in use, and then exec the VM with that as an -Xss value. Is that something you can do? Thanks for the suggestions and reviews @dholmes-ora @theRealAph ------------- PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3673198106 From syan at openjdk.org Fri Dec 19 02:25:03 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 02:25:03 GMT Subject: Integrated: 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 In-Reply-To: References: Message-ID: <5qV2klAAC9h1vPTEpVJqn4-ZMTduvMI9n5ADZ3zueGk=.c49394f0-f83d-42ef-820a-b5eec7c556e8@github.com> On Mon, 17 Nov 2025 14:31:46 GMT, SendaoYan wrote: > Hi all, > > On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size: > > > page_size = 64K > _java_thread_min_stack_allowed = 72K > _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K > _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K > _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K > _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K > > > This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > Change has been verified locally both on linux-x64 and linux-aarch64. This pull request has now been integrated. Changeset: 360777c3 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f Stats: 64 lines in 5 files changed: 36 ins; 2 del; 26 mod 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 Reviewed-by: dholmes, aph ------------- PR: https://git.openjdk.org/jdk/pull/28352 From syan at openjdk.org Fri Dec 19 02:43:37 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 02:43:37 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads Message-ID: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Hi all, This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. Additional testing: - [ ] All jtreg tests by fastdebug build ------------- Commit messages: - Remove unnecessary unloadClass - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads Changes: https://git.openjdk.org/jdk/pull/28891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373945 Stats: 157 lines in 25 files changed: 73 ins; 54 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Fri Dec 19 02:43:37 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 02:43:37 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan wrote: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build GHA report jdk build fails on linux-x64-hs-optimized. Seems like environmental issue or infrastructure issue. It's unrelated to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3669059576 From syan at openjdk.org Fri Dec 19 03:25:34 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 03:25:34 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v2] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan 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 branch 'openjdk:master' into jbs8373945 - Remove unnecessary unloadClass - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/999908ea..3028bbea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=00-01 Stats: 3116 lines in 74 files changed: 2082 ins; 635 del; 399 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Fri Dec 19 03:52:51 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 03:52:51 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v2] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 03:25:34 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [ ] All jtreg tests by fastdebug build > > SendaoYan 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 branch 'openjdk:master' into jbs8373945 > - Remove unnecessary unloadClass > - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads There are other 36 tests need to be updated since the change of `unloadClass` [tests.txt](https://github.com/user-attachments/files/24250041/tests.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3673373828 From lmesnik at openjdk.org Fri Dec 19 04:52:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Dec 2025 04:52:04 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v2] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 03:25:34 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [ ] All jtreg tests by fastdebug build > > SendaoYan 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 branch 'openjdk:master' into jbs8373945 > - Remove unnecessary unloadClass > - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads Thank you for fixing this. It improves reliability of testing significantly. However more changes and testing is needed. I started discussion inline to have it in thread. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 36: > 34: import nsk.share.test.ExecutionController; > 35: import nsk.share.test.Stresser; > 36: import jdk.test.whitebox.WhiteBox; This change impacts a lot of tests in vmTestbase. They are going to be broken if are using classunloading. Si it requires testing of ALL vmTestbase tests to ensure that all test are fixed, not only monitoring. ------------- Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3596794660 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2633597452 From dholmes at openjdk.org Fri Dec 19 06:16:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 06:16:28 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity David Holmes has updated the pull request incrementally with two additional commits since the last revision: - Delay suspender whilst target is in-critical - Revert "8373839: Disable JVM TI suspension during JNI critical regions" This reverts commit 7723275e4495cc1f514c531afe752210209617cc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28884/files - new: https://git.openjdk.org/jdk/pull/28884/files/7723275e..2df50e50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28884&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28884&range=00-01 Stats: 24 lines in 3 files changed: 12 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28884/head:pull/28884 PR: https://git.openjdk.org/jdk/pull/28884 From dholmes at openjdk.org Fri Dec 19 06:16:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 06:16:29 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:25:17 GMT, Patricio Chilano Mateo wrote: >> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. > >> Thanks for looking at this @pchilano >> >> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. >> >> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else. >> > It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead. > >> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. >> >> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition. >> > It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions). @pchilano is the latest proposal more what you were thinking? It has an obvious flaw if the critical region is badly behaved, but perhaps we just live with that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3673697095 From syan at openjdk.org Fri Dec 19 06:17:53 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 06:17:53 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v2] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 04:48:26 GMT, Leonid Mesnik wrote: >> SendaoYan 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 branch 'openjdk:master' into jbs8373945 >> - Remove unnecessary unloadClass >> - 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 36: > >> 34: import nsk.share.test.ExecutionController; >> 35: import nsk.share.test.Stresser; >> 36: import jdk.test.whitebox.WhiteBox; > > This change impacts a lot of tests in vmTestbase. They are going to be broken if are using classunloading. > Si it requires testing of ALL vmTestbase tests to ensure that all test are fixed, not only monitoring. Thanks. I am also noticed that some other test need to be updated after the change of classunloading. I will do it later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2633807610 From syan at openjdk.org Fri Dec 19 06:43:36 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 06:43:36 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v3] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects 5 tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/3028bbea..7e67804f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=01-02 Stats: 18 lines in 5 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From mbaesken at openjdk.org Fri Dec 19 08:29:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Dec 2025 08:29:56 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 02:16:01 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust check a little as suggested by David > > test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java line 77: > >> 75: } >> 76: >> 77: assertTrue(res.length == 3, res.length - 1); > > Suggestion: > > assertTrue(res.length == 3, res.length); > > You need to adjust both parts not sure, in one of our failures with added output it says this `java.lang.RuntimeException: Count error: count was 3` and indeed, 3 times the pattern we check for is in the output StackWalkNativeToJava$TestNativeToJavaNative.callNativeMethod()V But anyway , nowhere is defined what 'count' really means. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2634168850 From syan at openjdk.org Fri Dec 19 08:36:46 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 08:36:46 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v4] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Fix other tests except CompiledMethodUnload/compmethunload001/TestDescription.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/7e67804f..47c508a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=02-03 Stats: 178 lines in 31 files changed: 92 ins; 29 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Fri Dec 19 08:45:37 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Dec 2025 08:45:37 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/47c508a5..c752a052 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From rrich at openjdk.org Fri Dec 19 09:57:40 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 19 Dec 2025 09:57:40 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v3] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes wrote: >> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. >> >> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Exapnd comment I wonder why there are no GHA tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674358347 From stefank at openjdk.org Fri Dec 19 10:40:26 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Dec 2025 10:40:26 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set Message-ID: While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: if (a->is_objArray()) { if (value_type == T_OBJECT) { ... } // what happens in the else case? here } else { assert(a->is_typeArray(), "just checking"); } And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. So, I propose that we just replace one of the ifs with an assert. ------------- Commit messages: - 8374113: Taughtological if check in Reflection::array_set Changes: https://git.openjdk.org/jdk/pull/28921/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28921&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374113 Stats: 10 lines in 1 file changed: 1 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28921.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28921/head:pull/28921 PR: https://git.openjdk.org/jdk/pull/28921 From jnorlinder at openjdk.org Fri Dec 19 10:55:14 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Fri, 19 Dec 2025 10:55:14 GMT Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during high load from JNI code [v4] In-Reply-To: <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com> References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com> <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com> <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com> Message-ID: On Wed, 17 Dec 2025 07:53:28 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Use portable type > > A couple of more comments. Me and @kstefanj had a discussion about pros and cons of using getrusage. Its unclear for both of us if we should introduce a major overhaul of the threading infrastructure to support as accurate sampling of system CPU time as possible on Linux with this patch (getrusage) or if we can accept a solution that may be less accurate in a scenario with high-frequency sampling. We decided continue discussing what path to take after Christmas and new year celebrations. Happy holidays everyone! ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28824#issuecomment-3674586678 From pchilanomate at openjdk.org Fri Dec 19 11:22:33 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 19 Dec 2025 11:22:33 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:25:17 GMT, Patricio Chilano Mateo wrote: >> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. > >> Thanks for looking at this @pchilano >> >> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. >> >> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else. >> > It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead. > >> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region. >> >> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition. >> > It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions). > @pchilano is the latest proposal more what you were thinking? It has an obvious flaw if the critical region is badly behaved, but perhaps we just live with that. > Thanks David. I was thinking on having a `in_critical()` check in `HandshakeState::try_process` when the op returned by `get_op()` is `SuspendThreadHandshakeClosure` since we already have the `HandshakeSpinYield` of the operation. This avoids spinning in the closure which would block other handshakes or safepoints. And if the check fails we could pick another operation, if available, and not just return `_not_safe` to retry (to avoid stalling other handshakes once the suspend is at the front of the queue). But I guess it depends on how paranoid we are that this JNI API is being used correctly, so your simpler change could work too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3674677513 From pchilanomate at openjdk.org Fri Dec 19 11:22:37 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 19 Dec 2025 11:22:37 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Delay suspender whilst target is in-critical > - Revert "8373839: Disable JVM TI suspension during JNI critical regions" > > This reverts commit 7723275e4495cc1f514c531afe752210209617cc. src/hotspot/share/runtime/suspendResumeManager.cpp line 64: > 62: } > 63: void do_thread(Thread* thr) { > 64: assert(thr != Thread::current(), "must be"); I think the target can execute this operation. src/hotspot/share/runtime/suspendResumeManager.cpp line 70: > 68: // hang here. There is no way to time-out and abort the suspend request because > 69: // the API does not allow for that - if a thread is live then it can be suspended. > 70: if (target->in_critical_atomic()) { I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634756340 PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634771987 From pchilanomate at openjdk.org Fri Dec 19 11:46:41 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 19 Dec 2025 11:46:41 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 11:19:19 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with two additional commits since the last revision: >> >> - Delay suspender whilst target is in-critical >> - Revert "8373839: Disable JVM TI suspension during JNI critical regions" >> >> This reverts commit 7723275e4495cc1f514c531afe752210209617cc. > > src/hotspot/share/runtime/suspendResumeManager.cpp line 70: > >> 68: // hang here. There is no way to time-out and abort the suspend request because >> 69: // the API does not allow for that - if a thread is live then it can be suspended. >> 70: if (target->in_critical_atomic()) { > > I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread. And if there is a safepoint in these transitions I realized we would deadlock because this thread will never be safepoint safe. So maybe better to move the spinning out as I suggested above? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634832937 From cnorrbin at openjdk.org Fri Dec 19 11:59:39 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 19 Dec 2025 11:59:39 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v6] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 02:27:48 GMT, SendaoYan wrote: >> Hi all, >> >> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. >> >> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. >> >> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. >> >> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan 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 six additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Add synchronized lock for addClassOptions > - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails Looks good to me! ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/26605#pullrequestreview-3598332623 From stefank at openjdk.org Fri Dec 19 12:29:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Dec 2025 12:29:47 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. Tier1 testing passes ------------- PR Comment: https://git.openjdk.org/jdk/pull/28921#issuecomment-3674890773 From dholmes at openjdk.org Fri Dec 19 12:43:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 12:43:13 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v3] In-Reply-To: References: Message-ID: <6vFGKEFch604SQW5BCHD9DhoUeYGKKVBjvN8Q9ByPQ0=.605967f2-e2ed-497c-907e-55b85be2d3cb@github.com> On Fri, 19 Dec 2025 09:54:42 GMT, Richard Reingruber wrote: > I wonder why there are no GHA tests? I don't run GHA by default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674939902 From dholmes at openjdk.org Fri Dec 19 12:49:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 12:49:01 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 11:13:01 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with two additional commits since the last revision: >> >> - Delay suspender whilst target is in-critical >> - Revert "8373839: Disable JVM TI suspension during JNI critical regions" >> >> This reverts commit 7723275e4495cc1f514c531afe752210209617cc. > > src/hotspot/share/runtime/suspendResumeManager.cpp line 64: > >> 62: } >> 63: void do_thread(Thread* thr) { >> 64: assert(thr != Thread::current(), "must be"); > > I think the target can execute this operation. We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634990833 From dholmes at openjdk.org Fri Dec 19 12:53:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 12:53:12 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 12:45:27 GMT, David Holmes wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 64: >> >>> 62: } >>> 63: void do_thread(Thread* thr) { >>> 64: assert(thr != Thread::current(), "must be"); >> >> I think the target can execute this operation. > > We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this. But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual `do_thread` operation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635003209 From coleenp at openjdk.org Fri Dec 19 13:01:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Dec 2025 13:01:52 GMT Subject: RFR: 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test Message-ID: This patch replaces Locale with Calendar since Locale can be loaded during the JVMTI PRIMORDIAL phase and not be loaded with the ClassFileLoadHook. See linked bug for details. (https://bugs.openjdk.org/browse/JDK-8372686) Tested with the test on windows. ------------- Commit messages: - 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test Changes: https://git.openjdk.org/jdk/pull/28914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374052 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28914/head:pull/28914 PR: https://git.openjdk.org/jdk/pull/28914 From dholmes at openjdk.org Fri Dec 19 13:02:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 13:02:28 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 11:18:50 GMT, Patricio Chilano Mateo wrote: > I was thinking on having a in_critical() check in HandshakeState::try_process when the op returned by get_op() is `SuspendThreadHandshakeClosure` Checking the generic handshake code for a specific handshake operation seems like a horrendous hack - that code should never have to specialize based on the operation. The operation should handle any special cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3674993065 From dholmes at openjdk.org Fri Dec 19 13:02:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 13:02:30 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 11:43:41 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 70: >> >>> 68: // hang here. There is no way to time-out and abort the suspend request because >>> 69: // the API does not allow for that - if a thread is live then it can be suspended. >>> 70: if (target->in_critical_atomic()) { >> >> I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread. > > And if there is a safepoint in these transitions I realized we would deadlock because this thread will never be safepoint safe. So maybe better to move the spinning out as I suggested above? Yeah I need to re-think this whole approach. What a mess. Thanks. :( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635022382 From dholmes at openjdk.org Fri Dec 19 13:07:26 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Dec 2025 13:07:26 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: References: Message-ID: <7GITRFY7mIkVVEEHxaDzoEhYpiO2KySlGcmg6L50aqE=.f46377f0-0814-486a-b43d-293c626c5fce@github.com> On Fri, 19 Dec 2025 08:26:48 GMT, Matthias Baesken wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java line 77: >> >>> 75: } >>> 76: >>> 77: assertTrue(res.length == 3, res.length - 1); >> >> Suggestion: >> >> assertTrue(res.length == 3, res.length); >> >> You need to adjust both parts > > not sure, in one of our failures with added output it says this > `java.lang.RuntimeException: Count error: count was 3` > and indeed, 3 times the pattern we check for is in the output > StackWalkNativeToJava$TestNativeToJavaNative.callNativeMethod()V > > But anyway , nowhere is defined what 'count' really means. I am assuming that the assertTrue's first argument is the value check of a given variable, and the second is the actual value of that variable. So if we were comparing `length -1` then the actual value is `length-1`. but now we check length then the actual value is length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2635040484 From pchilanomate at openjdk.org Fri Dec 19 13:23:19 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 19 Dec 2025 13:23:19 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 12:59:39 GMT, David Holmes wrote: > > I was thinking on having a in_critical() check in HandshakeState::try_process when the op returned by get_op() is `SuspendThreadHandshakeClosure` > > Checking the generic handshake code for a specific handshake operation seems like a horrendous hack - that code should never have to specialize based on the operation. The operation should handle any special cases. > We don't need to check for a specific operation, we can make it general by defining a virtual method in `HandshakeClosure` (e.g. `needs_jni_critical_check`) that's overriden by any operation that requires this check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3675063379 From pchilanomate at openjdk.org Fri Dec 19 13:23:20 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 19 Dec 2025 13:23:20 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 12:50:12 GMT, David Holmes wrote: >> We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this. > > But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual `do_thread` operation. > We already checked for current thread in `SuspendResumeManager::suspend` and took a different path before calling this. > Right, but that's only if the thread requested to suspend itself, not when the request is from a different thread. > But I am forgetting how handshakes operate in general - I don't know whether the handshakee or the handshaker will execute the actual do_thread operation. > Except for async hanshakes, a hanshake could be executed by either one. Even from another thread trying to handshake the same target. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2635080415 From mbaesken at openjdk.org Fri Dec 19 13:28:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Dec 2025 13:28:37 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v3] In-Reply-To: References: Message-ID: > In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . > The other checks ` output.shouldNotContain` print already the diagnostic summary of output. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Follow Davids suggestion; change other test method too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28871/files - new: https://git.openjdk.org/jdk/pull/28871/files/a703276f..61811c6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28871&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28871&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28871.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28871/head:pull/28871 PR: https://git.openjdk.org/jdk/pull/28871 From mbaesken at openjdk.org Fri Dec 19 13:28:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Dec 2025 13:28:37 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v2] In-Reply-To: <7GITRFY7mIkVVEEHxaDzoEhYpiO2KySlGcmg6L50aqE=.f46377f0-0814-486a-b43d-293c626c5fce@github.com> References: <7GITRFY7mIkVVEEHxaDzoEhYpiO2KySlGcmg6L50aqE=.f46377f0-0814-486a-b43d-293c626c5fce@github.com> Message-ID: On Fri, 19 Dec 2025 13:04:33 GMT, David Holmes wrote: >> not sure, in one of our failures with added output it says this >> `java.lang.RuntimeException: Count error: count was 3` >> and indeed, 3 times the pattern we check for is in the output >> StackWalkNativeToJava$TestNativeToJavaNative.callNativeMethod()V >> >> But anyway , nowhere is defined what 'count' really means. > > I am assuming that the assertTrue's first argument is the value check of a given variable, and the second is the actual value of that variable. So if we were comparing `length -1` then the actual value is `length-1`. but now we check length then the actual value is length. Okay changed it. While looking at the test I noticed that we should do the same adjustments in the other method too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28871#discussion_r2635093558 From rrich at openjdk.org Fri Dec 19 13:52:18 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 19 Dec 2025 13:52:18 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v3] In-Reply-To: References: Message-ID: <1NnXP_p6_XPsKO0kPmmColRPJZBTmtcl9x0TdRAPjfI=.e4920b21-6c57-455e-89cb-59456a9da863@github.com> On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes wrote: >> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. >> >> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Exapnd comment Looks good. Thanks, Richard. A deadlock can still occur if the debugger suspends the thread in the critical region, e.g. to read a local variable. After [JDK-8373839](https://bugs.openjdk.org/browse/JDK-8373839) this shouldn't be possible anymore. ------------- Marked as reviewed by rrich (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3598687723 PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3675155037 From fparain at openjdk.org Fri Dec 19 15:34:14 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 19 Dec 2025 15:34:14 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. LGTM ------------- Marked as reviewed by fparain (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28921#pullrequestreview-3599037076 From liach at openjdk.org Fri Dec 19 15:51:15 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 15:51:15 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. This one seems safe because this seems only used by `Array.set` and the primitive overloads. I checked `JVM_SetArrayElement` and `JVM_SetPrimitiveArrayElement` callers in `Array.c`. However note that `java.lang.reflect.Array` is poorly tested/covered, so please help check if there are other sites that can pass in inconsistent array oop + value type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28921#issuecomment-3675557830 From stefank at openjdk.org Fri Dec 19 16:34:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Dec 2025 16:34:52 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 15:48:05 GMT, Chen Liang wrote: > This one seems safe because this seems only used by `Array.set` and the primitive overloads. I checked `JVM_SetArrayElement` and `JVM_SetPrimitiveArrayElement` callers in `Array.c`. However note that `java.lang.reflect.Array` is poorly tested/covered, so please help check if there are other sites that can pass in inconsistent array oop + value type. Thanks for taking a look at this! There are no other callers to Reflection::array_set. And if there are future additions that are problematic then those should be found by the added assert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28921#issuecomment-3675719259 From liach at openjdk.org Fri Dec 19 16:41:11 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 16:41:11 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. Looks good from core reflection POV. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28921#pullrequestreview-3599268895 From sgehwolf at openjdk.org Fri Dec 19 17:27:59 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 19 Dec 2025 17:27:59 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v6] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 02:27:48 GMT, SendaoYan wrote: >> Hi all, >> >> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. >> >> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. >> >> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. >> >> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan 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 six additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Merge branch 'openjdk:master' into jbs8362087 > - Add synchronized lock for addClassOptions > - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails OK. One tiny nit. test/hotspot/jtreg/containers/docker/ShareTmpDir.java line 106: > 104: > 105: while (!started1.exists() || !started2.exists()) { > 106: System.out.println("Waiting for all the two JVM started"); Suggestion: System.out.println("Waiting for all two JVMs to start"); ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26605#pullrequestreview-3599421093 PR Review Comment: https://git.openjdk.org/jdk/pull/26605#discussion_r2635771175 From iklam at openjdk.org Fri Dec 19 17:41:20 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Dec 2025 17:41:20 GMT Subject: RFR: 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:33:45 GMT, Coleen Phillimore wrote: > This patch replaces Locale with Calendar since Locale can be loaded during the JVMTI PRIMORDIAL phase and not be loaded with the ClassFileLoadHook. See linked bug for details. (https://bugs.openjdk.org/browse/JDK-8372686) > Tested with the test on windows. Looks good and trivial ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28914#pullrequestreview-3599481912 From coleenp at openjdk.org Fri Dec 19 17:48:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Dec 2025 17:48:49 GMT Subject: RFR: 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:33:45 GMT, Coleen Phillimore wrote: > This patch replaces Locale with Calendar since Locale can be loaded during the JVMTI PRIMORDIAL phase and not be loaded with the ClassFileLoadHook. See linked bug for details. (https://bugs.openjdk.org/browse/JDK-8372686) > Tested with the test on windows. Thanks Ioi! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28914#issuecomment-3675963635 From coleenp at openjdk.org Fri Dec 19 17:48:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Dec 2025 17:48:50 GMT Subject: Integrated: 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test In-Reply-To: References: Message-ID: <6iHei8u3nYegivv2XaQb3kKs4yO0oEBRpaHi9LkHDGQ=.58f13dfa-d751-4577-ae97-1bdbb53ed795@github.com> On Thu, 18 Dec 2025 23:33:45 GMT, Coleen Phillimore wrote: > This patch replaces Locale with Calendar since Locale can be loaded during the JVMTI PRIMORDIAL phase and not be loaded with the ClassFileLoadHook. See linked bug for details. (https://bugs.openjdk.org/browse/JDK-8372686) > Tested with the test on windows. This pull request has now been integrated. Changeset: 23fc21a3 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/23fc21a3e2db11e24568d4c47e52efc6947e956b Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test Reviewed-by: iklam ------------- PR: https://git.openjdk.org/jdk/pull/28914 From cjplummer at openjdk.org Fri Dec 19 18:46:02 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Dec 2025 18:46:02 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 08:45:37 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [ ] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154: > 152: > 153: // Drop all references to the class and try to unload it > 154: WhiteBox.getWhiteBox().fullGC(); Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below. test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71: > 69: * -transport.address=dynamic > 70: * -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. > 71: * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before. test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50: > 48: "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; > 49: > 50: private final static int MAX_ITERATIONS = 50; Can you explain the need for this change. ------------- PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3599556766 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635960204 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635889453 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635893925 From syan at openjdk.org Sat Dec 20 00:56:30 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 00:56:30 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v7] In-Reply-To: References: Message-ID: <5h0H88T94IL0wqziVkv_Oz0e8MCBH14HDMNqOxGrmaE=.0281b797-2f05-4caa-b944-60211ac37f6c@github.com> > Hi all, > > The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. > > If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. > > This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. > > The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. > > Change has been verified locally, test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: System.out.println("Waiting for all two JVMs to start"); Co-authored-by: Severin Gehwolf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26605/files - new: https://git.openjdk.org/jdk/pull/26605/files/19095aae..d83eed06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26605/head:pull/26605 PR: https://git.openjdk.org/jdk/pull/26605 From syan at openjdk.org Sat Dec 20 02:15:31 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 02:15:31 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v6] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add indent for jdi tests in debugee.vmkeys line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/c752a052..5de8cc8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=04-05 Stats: 26 lines in 25 files changed: 1 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Dec 20 02:15:32 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 02:15:32 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 18:08:56 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71: > >> 69: * -transport.address=dynamic >> 70: * -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. >> 71: * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin > > In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before. Thanks. The indent has been added for jni tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636700458 From syan at openjdk.org Sat Dec 20 04:43:08 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 04:43:08 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v7] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update the comments for gc/gctests/LargeObjects/large001/large001.java related tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/5de8cc8c..a5eaf607 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05-06 Stats: 25 lines in 5 files changed: 17 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Dec 20 04:50:54 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 04:50:54 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 18:41:58 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java > > test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154: > >> 152: >> 153: // Drop all references to the class and try to unload it >> 154: WhiteBox.getWhiteBox().fullGC(); > > Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below. It seems that, the references is non null at the first time. So it will not unload the classes actually, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636777045 From syan at openjdk.org Sat Dec 20 04:59:07 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 04:59:07 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v8] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update comments about "using memory stressing techique" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/a5eaf607..567c7623 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Dec 20 04:59:09 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Dec 2025 04:59:09 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 18:42:44 GMT, Chris Plummer wrote: > There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. > > I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3677383218 From swen at openjdk.org Sat Dec 20 12:44:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 20 Dec 2025 12:44:22 GMT Subject: RFR: 8371431: Warning message when turning off CompactStrings [v2] In-Reply-To: References: Message-ID: > A warning message should be given before removing the CompactStrings off option. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into compact_str_warn_2510 - Merge branch 'master' into compact_str_warn_2510 - from @liach - add warnings ------------- Changes: https://git.openjdk.org/jdk/pull/27995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27995&range=01 Stats: 12 lines in 2 files changed: 0 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27995/head:pull/27995 PR: https://git.openjdk.org/jdk/pull/27995 From jiefu at openjdk.org Sun Dec 21 15:49:32 2025 From: jiefu at openjdk.org (Jie Fu) Date: Sun, 21 Dec 2025 15:49:32 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 Message-ID: Hi all, Please review this tiny fix of missing include in systemDictionary.cpp. For how to reproduce the error, please see the JBS. Thanks. ------------- Commit messages: - 8374178: Missing include in systemDictionary.cpp after JDK-8365526 Changes: https://git.openjdk.org/jdk/pull/28946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374178 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28946/head:pull/28946 PR: https://git.openjdk.org/jdk/pull/28946 From jiefu at openjdk.org Sun Dec 21 15:52:11 2025 From: jiefu at openjdk.org (Jie Fu) Date: Sun, 21 Dec 2025 15:52:11 GMT Subject: RFR: 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null [v7] In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 13:40:44 GMT, Coleen Phillimore wrote: >> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field. >> >> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable. The key to this table is {ConstantPool, cp-index}. In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed. In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure. In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message. Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields. The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too). >> >> Add a null check before calling ResolutionErrorEntry add entry. Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again. >> >> Tested with submitted reproducer and tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/classfile/systemDictionary.cpp src/hotspot/share/classfile/systemDictionary.cpp line 1871: > 1869: // constant pool index. In this case resolution succeeded but there's an error in this nest host > 1870: // that we use the table to record. > 1871: assert(pool->resolved_klass_at(which) != nullptr, "klass should be resolved if there is no entry"); Missing an include for `resolved_klass_at`? Please see https://github.com/openjdk/jdk/pull/28946 . Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2637911628 From iklam at openjdk.org Sun Dec 21 17:02:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Dec 2025 17:02:54 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. src/hotspot/share/classfile/systemDictionary.cpp line 92: > 90: #ifdef ASSERT > 91: #include "oops/constantPool.inline.hpp" > 92: #endif There's no need to put this in an `#if`, or else the includes will become cluttered over time. You can just put it in the regular include lines above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28946#discussion_r2637958036 From duke at openjdk.org Sun Dec 21 19:49:51 2025 From: duke at openjdk.org (khanbilal732) Date: Sun, 21 Dec 2025 19:49:51 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3601937539 From duke at openjdk.org Sun Dec 21 19:59:51 2025 From: duke at openjdk.org (khanbilal732) Date: Sun, 21 Dec 2025 19:59:51 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: <1Yi03rTRPRlUgDjptJxx41WVkNjyWZfKqQj76EUepJI=.ef02713f-275f-4e62-b36b-6609ce5f6d2d@github.com> On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3601949758 PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3601950401 PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3601950796 From kbarrett at openjdk.org Sun Dec 21 19:59:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 21 Dec 2025 19:59:52 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3601949360 From kbarrett at openjdk.org Sun Dec 21 19:59:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 21 Dec 2025 19:59:56 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 16:58:49 GMT, Ioi Lam wrote: >> Hi all, >> >> Please review this tiny fix of missing include in systemDictionary.cpp. >> For how to reproduce the error, please see the JBS. >> >> Thanks. > > src/hotspot/share/classfile/systemDictionary.cpp line 92: > >> 90: #ifdef ASSERT >> 91: #include "oops/constantPool.inline.hpp" >> 92: #endif > > There's no need to put this in an `#if`, or else the includes will become cluttered over time. You can just put it in the regular include lines above. +1 - we generally conditionalize includes based on optional features or (rarely (never?) in shared code) platforms, not on build type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28946#discussion_r2638067766 From dholmes at openjdk.org Sun Dec 21 21:40:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Dec 2025 21:40:51 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v3] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 13:28:37 GMT, Matthias Baesken wrote: >> In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . >> The other checks ` output.shouldNotContain` print already the diagnostic summary of output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Follow Davids suggestion; change other test method too Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28871#pullrequestreview-3602011452 From dholmes at openjdk.org Mon Dec 22 00:30:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 00:30:05 GMT Subject: RFR: 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null [v2] In-Reply-To: References: <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com> Message-ID: On Thu, 27 Nov 2025 00:10:48 GMT, David Holmes wrote: >> I made a ticket for this: [8372373](https://bugs.openjdk.org/browse/JDK-8372373) > > @jdksjolen just to clarify one thing. There is a reason we defined the second constructor to not have to strdup. Given we start with a `stringStream` we have to first convert that to a `char*` representation, which is done via a C-heap array allocation. If the constructor then `strdup`'d that then we'd be copying the string twice. So instead we expect to get the C-heap version (which should also get freed when needed, but I think we missed that part). Note the free'ing was incorrect - see [JDK-8372988](https://bugs.openjdk.org/browse/JDK-8372988) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2638249749 From jiefu at openjdk.org Mon Dec 22 01:14:37 2025 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 22 Dec 2025 01:14:37 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 [v2] In-Reply-To: References: Message-ID: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28946/files - new: https://git.openjdk.org/jdk/pull/28946/files/a7789200..b3d9eece Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28946&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28946&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28946/head:pull/28946 PR: https://git.openjdk.org/jdk/pull/28946 From jiefu at openjdk.org Mon Dec 22 01:14:37 2025 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 22 Dec 2025 01:14:37 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: <8rylWdoY8NQKkKnpaYTa30pEx1jjR6OLKupN_eUldEA=.4c2a7b0f-a596-4332-80c3-c3e2a0f2661d@github.com> On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. Thanks @iklam and @kimbarrett for the comments. Updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28946#issuecomment-3679894360 From dholmes at openjdk.org Mon Dec 22 01:30:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 01:30:29 GMT Subject: RFR: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical [v3] In-Reply-To: References: Message-ID: <1wh7XkntsNC-F398ebv89gGlyYSZC58blKrA-oRqb8c=.54dfaa49-e5fa-4193-b276-6784cd9b47c9@github.com> On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes wrote: >> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. >> >> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Exapnd comment Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3679915216 From dholmes at openjdk.org Mon Dec 22 01:30:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 01:30:30 GMT Subject: Integrated: 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes wrote: > As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check. > > The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. > > UPDATE: we are now employing a much simpler solution. > > There is no regression test as this has only been seen in long running stress tests. > > Testing: > -tiers 1-6 This pull request has now been integrated. Changeset: 25e87144 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/25e87144c20fcf5aca99b92f061a0051096c2605 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical Co-authored-by: Richard Reingruber Reviewed-by: rrich, fbredberg, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/28779 From dholmes at openjdk.org Mon Dec 22 01:34:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 01:34:55 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com> On Fri, 19 Dec 2025 13:19:22 GMT, Patricio Chilano Mateo wrote: > We don't need to check for a specific operation, we can make it general by defining a virtual method in `HandshakeClosure` (e.g. `needs_jni_critical_check`) that's overriden by any operation that requires this check. That isn't really any better to me. The general purpose handshake code should not have to be JNI-critical aware. That aside I'm also struggling to see how we make the originator thread block when the target thread executes the handshake operation code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3679933261 From dholmes at openjdk.org Mon Dec 22 02:01:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 02:01:55 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 [v2] In-Reply-To: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> References: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> Message-ID: On Mon, 22 Dec 2025 01:14:37 GMT, Jie Fu wrote: >> Hi all, >> >> Please review this tiny fix of missing include in systemDictionary.cpp. >> For how to reproduce the error, please see the JBS. >> >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Trivially fine. Just to reiterate what has been said in the past, we are not too concerned about making all possible combinations of enabled/disabled services work. If a "full" VM works and the Minimal VM works then that is normally sufficient. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3602291662 From cjplummer at openjdk.org Mon Dec 22 03:20:01 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Dec 2025 03:20:01 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 20 Dec 2025 04:47:44 GMT, SendaoYan wrote: >> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154: >> >>> 152: >>> 153: // Drop all references to the class and try to unload it >>> 154: WhiteBox.getWhiteBox().fullGC(); >> >> Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below. > > It seems that, the references is non null at the first time. So it will not unload the classes actually, I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638494890 From cjplummer at openjdk.org Mon Dec 22 03:20:04 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Dec 2025 03:20:04 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v8] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 20 Dec 2025 04:59:07 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [ ] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update comments about "using memory stressing techique" test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52: > 50: * The test loads the classes with nsk.share.gc.GCClassUnloader class that > 51: * extends nsk.share. * The test loads the classes with nsk.share.gc.GCClassUnloader class. > 52: * As soon as a class is loaded, the test creates an instance of There seems to have been a copy-n-paste error here, and it was replicated in a few test cases below. test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71: > 69: * -transport.address=dynamic > 70: * -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. > 71: * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin I think ./bin should be moved to a newline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638499254 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638506867 From kbarrett at openjdk.org Mon Dec 22 06:12:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 22 Dec 2025 06:12:05 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 [v2] In-Reply-To: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> References: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> Message-ID: On Mon, 22 Dec 2025 01:14:37 GMT, Jie Fu wrote: >> Hi all, >> >> Please review this tiny fix of missing include in systemDictionary.cpp. >> For how to reproduce the error, please see the JBS. >> >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3602797278 From syan at openjdk.org Mon Dec 22 06:17:56 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 22 Dec 2025 06:17:56 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v8] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 03:12:17 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments about "using memory stressing techique" > > test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52: > >> 50: * The test loads the classes with nsk.share.gc.GCClassUnloader class that >> 51: * extends nsk.share. * The test loads the classes with nsk.share.gc.GCClassUnloader class. >> 52: * As soon as a class is loaded, the test creates an instance of > > There seems to have been a copy-n-paste error here, and it was replicated in a few test cases below. Sorry... Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638795405 From syan at openjdk.org Mon Dec 22 06:41:53 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 22 Dec 2025 06:41:53 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v8] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 03:16:11 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments about "using memory stressing techique" > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71: > >> 69: * -transport.address=dynamic >> 70: * -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. >> 71: * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin > > I think ./bin should be moved to a newline. Fixed for all the releated tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638834843 From syan at openjdk.org Mon Dec 22 07:20:07 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 22 Dec 2025 07:20:07 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Fri, 19 Dec 2025 18:11:10 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50: > >> 48: "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; >> 49: >> 50: private final static int MAX_ITERATIONS = 50; > > Can you explain the need for this change. Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`. After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time. Number of unloaded events 12 number of iterations 25 Number of unloaded events 1 number of iterations 36 Number of unloaded events 4 number of iterations 30 Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly. This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638907204 From mbaesken at openjdk.org Mon Dec 22 08:00:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 22 Dec 2025 08:00:12 GMT Subject: RFR: 8373876: StackWalkNativeToJava print more output in case of failures [v3] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 13:28:37 GMT, Matthias Baesken wrote: >> In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . >> The other checks ` output.shouldNotContain` print already the diagnostic summary of output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Follow Davids suggestion; change other test method too Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28871#issuecomment-3680903701 From mbaesken at openjdk.org Mon Dec 22 08:00:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 22 Dec 2025 08:00:14 GMT Subject: Integrated: 8373876: StackWalkNativeToJava print more output in case of failures In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 14:00:09 GMT, Matthias Baesken wrote: > In case of failures the jtreg test StackWalkNativeToJava sometimes misses to print the 'bad' output we check. This makes analyzing errors hard, so better enhance the output . > The other checks ` output.shouldNotContain` print already the diagnostic summary of output. This pull request has now been integrated. Changeset: 3579c752 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/3579c752bcf2c160de47ec748c8b649b0028826a Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod 8373876: StackWalkNativeToJava print more output in case of failures Reviewed-by: dholmes, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/28871 From syan at openjdk.org Mon Dec 22 08:46:55 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 22 Dec 2025 08:46:55 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 07:16:49 GMT, SendaoYan wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50: >> >>> 48: "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; >>> 49: >>> 50: private final static int MAX_ITERATIONS = 50; >> >> Can you explain the need for this change. > > Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`. > > After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time. > > > Number of unloaded events 12 number of iterations 25 > Number of unloaded events 1 number of iterations 36 > Number of unloaded events 4 number of iterations 30 > > > Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly. > > This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change. Another solution is make some sleep after call `unloadClass()` diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java index 13058ec7864..15120d3cad6 100644 --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java @@ -47,7 +47,7 @@ public class compmethunload001 { private final static String CLS_TO_BE_UNLOADED = "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; - private final static int MAX_ITERATIONS = 50; + private final static int MAX_ITERATIONS = 5; static { try { @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception { boolean clsUnloaded = clsUnLoader.unloadClass(); clsUnLoader = null; + Thread.sleep(5000); System.gc(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2639101290 From stefank at openjdk.org Mon Dec 22 09:58:01 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Dec 2025 09:58:01 GMT Subject: RFR: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28921#issuecomment-3681303306 From stefank at openjdk.org Mon Dec 22 09:58:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Dec 2025 09:58:02 GMT Subject: Integrated: 8374113: Taughtological if check in Reflection::array_set In-Reply-To: References: Message-ID: <0OwSP3iYHiT0B8aPy6vr15kOckYwA3cV5FxK0kLIvfs=.8a41e592-f015-4b3d-9df3-115daf8826a2@github.com> On Fri, 19 Dec 2025 10:32:43 GMT, Stefan Karlsson wrote: > While reviewing code in the Valhalla repository I saw that Reflection::array_set has this funny-looking code: > > if (a->is_objArray()) { > if (value_type == T_OBJECT) { > ... > } // what happens in the else case? here > } else { > assert(a->is_typeArray(), "just checking"); > } > > And wondered what would happen if the `value_type == T_OBJECT` check failed, and how is this handled with flattened arrays, given that we have T_FLAT_ELEMENT there. > > It turns out that the calling code passes down T_OBJECT even for flat arrays so they do take the `value_type == T_OBJECT` path, so that's fine. > > So, I propose that we just replace one of the ifs with an assert. This pull request has now been integrated. Changeset: 551e6562 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/551e656218f18fa815d42e6035f85e907c6d66a4 Stats: 10 lines in 1 file changed: 1 ins; 2 del; 7 mod 8374113: Taughtological if check in Reflection::array_set Reviewed-by: fparain, liach ------------- PR: https://git.openjdk.org/jdk/pull/28921 From jiefu at openjdk.org Mon Dec 22 10:37:53 2025 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 22 Dec 2025 10:37:53 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 [v2] In-Reply-To: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> References: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> Message-ID: On Mon, 22 Dec 2025 01:14:37 GMT, Jie Fu wrote: >> Hi all, >> >> Please review this tiny fix of missing include in systemDictionary.cpp. >> For how to reproduce the error, please see the JBS. >> >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thank you all for the review. The linux-x64 build failure in the CI/CD was caused by `System.IO.IOException: No space left on device : '/home/runner/actions-runner/cached/_diag/Worker_20251222-010841-utc.log'`, which shouldn't be caused by the change. So will integrate it later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28946#issuecomment-3681489755 From jiefu at openjdk.org Mon Dec 22 15:18:10 2025 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 22 Dec 2025 15:18:10 GMT Subject: Integrated: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 15:42:50 GMT, Jie Fu wrote: > Hi all, > > Please review this tiny fix of missing include in systemDictionary.cpp. > For how to reproduce the error, please see the JBS. > > Thanks. This pull request has now been integrated. Changeset: 9715e6da Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8374178: Missing include in systemDictionary.cpp after JDK-8365526 Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28946 From jiefu at openjdk.org Mon Dec 22 15:38:44 2025 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 22 Dec 2025 15:38:44 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics Message-ID: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Hi all, `jdk/internal/platform/cgroup/TestCgroupMetrics.java` fails on machines with common prefix metrics. For example, the cpu.stat may be usage_usec 5111148455 user_usec 4457755664 system_usec 653392790 core_sched.force_idle_usec 0 nr_periods 0 nr_throttled 0 throttled_usec 0 nr_burst 0 burst_usec 0 nr_throttled_bt 0 throttled_usec_bt 0 `nr_throttled` and `nr_throttled_bt` are metrics with common prefix. In this case, the test fails since it only matches the starting metric string. The fix just adds one more filter `.filter(l -> l.split("\\s+")[0].equals(metric))`, which would match the metric exactly. ------------- Commit messages: - 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics Changes: https://git.openjdk.org/jdk/pull/28956/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28956&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374200 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28956/head:pull/28956 PR: https://git.openjdk.org/jdk/pull/28956 From iklam at openjdk.org Mon Dec 22 18:05:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 18:05:44 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Message-ID: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. ------------- Commit messages: - 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Changes: https://git.openjdk.org/jdk/pull/28938/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28938&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373983 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28938.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28938/head:pull/28938 PR: https://git.openjdk.org/jdk/pull/28938 From duke at openjdk.org Mon Dec 22 18:05:44 2025 From: duke at openjdk.org (khanbilal732) Date: Mon, 22 Dec 2025 18:05:44 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600847786 PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600867977 From naoto at openjdk.org Mon Dec 22 18:09:11 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Dec 2025 18:09:11 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. Looks fine ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3605159944 From cjplummer at openjdk.org Mon Dec 22 19:05:19 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Dec 2025 19:05:19 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 08:44:39 GMT, SendaoYan wrote: >> Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`. >> >> After I change the value of MAX_ITERATIONS to 50, The test run passed, and the test log shows that the number of unloaded enents is different every time. >> >> >> Number of unloaded events 12 number of iterations 25 >> Number of unloaded events 1 number of iterations 36 >> Number of unloaded events 4 number of iterations 30 >> >> >> Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly. >> >> Maybe that's why after this PR we need more try loop count to get the unload enent. >> >> And if I add Thread.sleep(5000) after unloadClass() call also make this test pass without change the value of MAX_ITERATIONS. >> >> And I found that the vaule of MAX_ITERATIONS set to 50 seems do not enough. This will intermittent fails when run this test serially many times. So I change it to 500. > > Another solution is make some sleep after call `unloadClass()` > > > diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java > index 13058ec7864..15120d3cad6 100644 > --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java > +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java > @@ -47,7 +47,7 @@ public class compmethunload001 { > private final static String CLS_TO_BE_UNLOADED = > "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; > > - private final static int MAX_ITERATIONS = 50; > + private final static int MAX_ITERATIONS = 5; > > static { > try { > @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception { > > boolean clsUnloaded = clsUnLoader.unloadClass(); > clsUnLoader = null; > + Thread.sleep(5000); > System.gc(); > } It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2640938897 From duke at openjdk.org Mon Dec 22 19:28:18 2025 From: duke at openjdk.org (khanbilal732) Date: Mon, 22 Dec 2025 19:28:18 GMT Subject: RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 [v2] In-Reply-To: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> References: <9eE6qTey4DNAQpqhMRr123pY0fefRNg3Yz3KxYKyZHs=.e186c669-8d37-467f-accf-57c9526f9666@github.com> Message-ID: <_3sW01mqLZU9Pp3EoyOH1Oib8gDA7DK7KcsCRU_-UGQ=.3a7e2817-5003-45cd-aeb3-52bf2979111b@github.com> On Mon, 22 Dec 2025 01:14:37 GMT, Jie Fu wrote: >> Hi all, >> >> Please review this tiny fix of missing include in systemDictionary.cpp. >> For how to reproduce the error, please see the JBS. >> >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28946#pullrequestreview-3605427017 From iklam at openjdk.org Mon Dec 22 19:47:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 19:47:07 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> Message-ID: On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato wrote: >> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. >> >> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. > > Looks fine Thanks @naotoj for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3683897935 From iklam at openjdk.org Mon Dec 22 19:47:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 19:47:09 GMT Subject: Integrated: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. This pull request has now been integrated. Changeset: 4b8eda30 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/28938 From sspitsyn at openjdk.org Mon Dec 22 21:33:57 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 22 Dec 2025 21:33:57 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Delay suspender whilst target is in-critical > - Revert "8373839: Disable JVM TI suspension during JNI critical regions" > > This reverts commit 7723275e4495cc1f514c531afe752210209617cc. I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections: HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) { assert(_handshakee == Thread::current(), "Must be called by self"); assert(_lock.owned_by_self(), "Lock must be held"); assert(allow_suspend || !check_async_exception, "invalid case"); #if INCLUDE_JVMTI if (allow_suspend && _handshakee->is_disable_suspend()) { <== !!! // filter out suspend operations while JavaThread is in disable_suspend mode allow_suspend = false; } #endif if (!allow_suspend) { return _queue.peek(no_suspend_no_async_exception_filter); } else if (check_async_exception && !_async_exceptions_blocked) { return _queue.peek(); } else { return _queue.peek(no_async_exception_filter); } } The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684247689 From dholmes at openjdk.org Mon Dec 22 22:03:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Dec 2025 22:03:00 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 21:30:50 GMT, Serguei Spitsyn wrote: >> David Holmes has updated the pull request incrementally with two additional commits since the last revision: >> >> - Delay suspender whilst target is in-critical >> - Revert "8373839: Disable JVM TI suspension during JNI critical regions" >> >> This reverts commit 7723275e4495cc1f514c531afe752210209617cc. > > I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections: > > HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) { > assert(_handshakee == Thread::current(), "Must be called by self"); > assert(_lock.owned_by_self(), "Lock must be held"); > assert(allow_suspend || !check_async_exception, "invalid case"); > #if INCLUDE_JVMTI > if (allow_suspend && _handshakee->is_disable_suspend()) { <== !!! > // filter out suspend operations while JavaThread is in disable_suspend mode > allow_suspend = false; > } > #endif > if (!allow_suspend) { > return _queue.peek(no_suspend_no_async_exception_filter); > } else if (check_async_exception && !_async_exceptions_blocked) { > return _queue.peek(); > } else { > return _queue.peek(no_async_exception_filter); > } > } > > > The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead. > > Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section. @sspitsyn The use of `is_disable_suspend` is what was originally proposed but it does not work as it does not do what might be expected. Further none of these suggestions deep in the handshake code deal with the problem that the thread requesting the suspend has to block as long as any target is "in critical". I cannot see a relatively simple solution to this, but rather we would need a new (and complex) protocol for trying to deal with this. One possible approach may be to use a Dekker-style dual check and also permit JNI-critical to be blocked if a suspend request is pending. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684317025 From sspitsyn at openjdk.org Mon Dec 22 22:15:08 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 22 Dec 2025 22:15:08 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 22:00:40 GMT, David Holmes wrote: >> I've not look deep into this issue yet but it seems the approach below can be used to avoid suspends in JNI critical sections: >> >> HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception) { >> assert(_handshakee == Thread::current(), "Must be called by self"); >> assert(_lock.owned_by_self(), "Lock must be held"); >> assert(allow_suspend || !check_async_exception, "invalid case"); >> #if INCLUDE_JVMTI >> if (allow_suspend && _handshakee->is_disable_suspend()) { <== !!! >> // filter out suspend operations while JavaThread is in disable_suspend mode >> allow_suspend = false; >> } >> #endif >> if (!allow_suspend) { >> return _queue.peek(no_suspend_no_async_exception_filter); >> } else if (check_async_exception && !_async_exceptions_blocked) { >> return _queue.peek(); >> } else { >> return _queue.peek(no_async_exception_filter); >> } >> } >> >> >> The `_handshakee->in_critical_atomic()` can be checked directly in the `HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()` can be set instead. >> >> Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section. > > @sspitsyn The use of `is_disable_suspend` is what was originally proposed but it does not work as it does not do what might be expected. Further none of these suggestions deep in the handshake code deal with the problem that the thread requesting the suspend has to block as long as any target is "in critical". I cannot see a relatively simple solution to this, but rather we would need a new (and complex) protocol for trying to deal with this. One possible approach may be to use a Dekker-style dual check and also permit JNI-critical to be blocked if a suspend request is pending. @dholmes-ora Probably, you missed this update at the end of my comment: > Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684354390 From sspitsyn at openjdk.org Mon Dec 22 23:55:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 22 Dec 2025 23:55:56 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com> References: <3VRUzXw52l8eab2wzhOQmFeiZhfQR2OlflJ_EjuNmJ0=.2e617604-90d0-477b-bb32-0514f4864e9d@github.com> Message-ID: On Mon, 22 Dec 2025 01:32:19 GMT, David Holmes wrote: > That isn't really any better to me. The general purpose handshake code should not have to be JNI-critical aware. Agreed. It is not easy to track what was already discussed in this chat. Most likely, you already touched this but just wanted to double check. This issue is not fixable on the handshake code side. At the time the `SuspendThreadHandshakeClosure` op is executed, the target thread can be in native but not executing JNI critical region yet. However, after the `SuspendThreadHandshakeClosure` op has been finished (the suspend has been completed from the suspender point of view) the target thread can enter a JNI critical region while still in native and before having any chance to be self-suspended with the`ThreadSelfSuspensionHandshakeClosure`. In opposite, the JNI-critical code can to be JVMTI suspend aware. It can block on entering JNI critical region while the thread is suspended. However, this approach can cause new deadlocks. Good news is that the debug agent does not use JNI critical regions (AFAIKS). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684572911 From sspitsyn at openjdk.org Tue Dec 23 00:05:17 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Dec 2025 00:05:17 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 04:33:53 GMT, David Holmes wrote: > If all you are doing is adding an assert then the JBS issue and the PR need a considerable rewrite to explain things. Agreed. We had a private slack discussion with Patricio and decided to construct a test case to catch this situation. I've decided to postpone JBS and PR description changes while I'm working on test coverage. I had to place a comment about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3684586748 From dholmes at openjdk.org Tue Dec 23 00:59:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Dec 2025 00:59:03 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics In-Reply-To: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: On Mon, 22 Dec 2025 15:31:37 GMT, Jie Fu wrote: > Hi all, > > `jdk/internal/platform/cgroup/TestCgroupMetrics.java` fails on machines with common prefix metrics. > > For example, the cpu.stat may be > > usage_usec 5111148455 > user_usec 4457755664 > system_usec 653392790 > core_sched.force_idle_usec 0 > nr_periods 0 > nr_throttled 0 > throttled_usec 0 > nr_burst 0 > burst_usec 0 > nr_throttled_bt 0 > throttled_usec_bt 0 > > > `nr_throttled` and `nr_throttled_bt` are metrics with common prefix. > In this case, the test fails since it only matches the starting metric string. > > The fix just adds one more filter `.filter(l -> l.split("\\s+")[0].equals(metric))`, which would match the metric exactly. test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java line 126: > 124: String strVal = Files.lines(filePath) > 125: .filter(l -> l.startsWith(metric)) > 126: .filter(l -> l.split("\\s+")[0].equals(metric)) I'm not a regex expert but it seems odd to me to perform an inexact match first, then split that line to perform an exact match. Can't you check if it "starts with" the metric as a full word? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28956#discussion_r2641625287 From jiefu at openjdk.org Tue Dec 23 01:47:30 2025 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 23 Dec 2025 01:47:30 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics [v2] In-Reply-To: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: > Hi all, > > `jdk/internal/platform/cgroup/TestCgroupMetrics.java` fails on machines with common prefix metrics. > > For example, the cpu.stat may be > > usage_usec 5111148455 > user_usec 4457755664 > system_usec 653392790 > core_sched.force_idle_usec 0 > nr_periods 0 > nr_throttled 0 > throttled_usec 0 > nr_burst 0 > burst_usec 0 > nr_throttled_bt 0 > throttled_usec_bt 0 > > > `nr_throttled` and `nr_throttled_bt` are metrics with common prefix. > In this case, the test fails since it only matches the starting metric string. > > The fix just adds one more filter `.filter(l -> l.split("\\s+")[0].equals(metric))`, which would match the metric exactly. Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add a new regex to filter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28956/files - new: https://git.openjdk.org/jdk/pull/28956/files/cbe82ca7..905dad8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28956&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28956&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28956/head:pull/28956 PR: https://git.openjdk.org/jdk/pull/28956 From jiefu at openjdk.org Tue Dec 23 01:47:32 2025 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 23 Dec 2025 01:47:32 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics [v2] In-Reply-To: References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: On Tue, 23 Dec 2025 00:56:10 GMT, David Holmes wrote: > I'm not a regex expert but it seems odd to me to perform an inexact match first, then split that line to perform an exact match. This is because I just want to keep the logic to be simple not to introduce a regex. > Can't you check if it "starts with" the metric as a full word? Yes, I think so. Please see the updated version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28956#discussion_r2641684363 From dholmes at openjdk.org Tue Dec 23 02:09:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Dec 2025 02:09:05 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics [v2] In-Reply-To: References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: On Tue, 23 Dec 2025 01:47:30 GMT, Jie Fu wrote: >> Hi all, >> >> `jdk/internal/platform/cgroup/TestCgroupMetrics.java` fails on machines with common prefix metrics. >> >> For example, the cpu.stat may be >> >> usage_usec 5111148455 >> user_usec 4457755664 >> system_usec 653392790 >> core_sched.force_idle_usec 0 >> nr_periods 0 >> nr_throttled 0 >> throttled_usec 0 >> nr_burst 0 >> burst_usec 0 >> nr_throttled_bt 0 >> throttled_usec_bt 0 >> >> >> `nr_throttled` and `nr_throttled_bt` are metrics with common prefix. >> In this case, the test fails since it only matches the starting metric string. >> >> The fix just adds one more filter `.filter(l -> l.split("\\s+")[0].equals(metric))`, which would match the metric exactly. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add a new regex to filter That looks good to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28956#pullrequestreview-3606284595 From syan at openjdk.org Tue Dec 23 04:04:22 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Dec 2025 04:04:22 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 19:01:54 GMT, Chris Plummer wrote: >> Another solution is make some sleep after call `unloadClass()` >> >> >> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java >> index 13058ec7864..15120d3cad6 100644 >> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java >> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java >> @@ -47,7 +47,7 @@ public class compmethunload001 { >> private final static String CLS_TO_BE_UNLOADED = >> "nsk.jvmti.CompiledMethodUnload.compmethunload001u"; >> >> - private final static int MAX_ITERATIONS = 50; >> + private final static int MAX_ITERATIONS = 5; >> >> static { >> try { >> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception { >> >> boolean clsUnloaded = clsUnLoader.unloadClass(); >> clsUnLoader = null; >> + Thread.sleep(5000); >> System.gc(); >> } > > It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens. The code "wait on a monitor and notify from JNI" seems too complex for me. So I just limit the loop to no more than 10 seconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2641853242 From syan at openjdk.org Tue Dec 23 06:18:11 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Dec 2025 06:18:11 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v9] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <57mV8My9uVrRQwWkkizAkRt0U_XKsOTwGYjvSRGoP6c=.3e83f7a9-977f-43a3-bf35-c4fb1e86a9b0@github.com> > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/567c7623..e8d128e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07-08 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Tue Dec 23 06:56:44 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Dec 2025 06:56:44 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v10] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <1SRvteO27ODfuUPUyovzjAHeTA_BH0-wcc5ODyiSJIo=.1fe140cf-239f-4303-8cbe-d4f884c4ffc6@github.com> > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Fix the copy-n-paste error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/e8d128e6..349ae833 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08-09 Stats: 24 lines in 4 files changed: 0 ins; 20 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Tue Dec 23 07:32:47 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Dec 2025 07:32:47 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update commnets for ClassUnloader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/349ae833..6c144309 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From alanb at openjdk.org Tue Dec 23 08:33:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Dec 2025 08:33:10 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> Message-ID: On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato wrote: >> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. >> >> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. > > Looks fine @naotoj java.locale.useOldISOCodes was added as a compatibility switch in JDK 17. Do you have any sense as to whether it is used? I'm just wondering if if the "no longer supported" warning when the property is specified on the command line is worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3685715503 From kevinw at openjdk.org Tue Dec 23 09:55:09 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 09:55:09 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp Message-ID: Comment-only cleanup, didn't spot during previous review. Trivial, no code affected. ------------- Commit messages: - 8374232: Comment cleanup in diagnosticCommand.cpp Changes: https://git.openjdk.org/jdk/pull/28962/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374232 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28962.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28962/head:pull/28962 PR: https://git.openjdk.org/jdk/pull/28962 From kevinw at openjdk.org Tue Dec 23 12:30:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 12:30:02 GMT Subject: RFR: 8374296: Comment clean up in os_linux.cpp Message-ID: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> In src/hotspot/os/linux/os_linux.cpp this comment no longer shows where there is time support code: //////////////////////////////////////////////////////////////////////////////// // time support Orphaned since JDK-8372625, trivially remove. ------------- Commit messages: - 8374296: Comment clean up in os_linux.cpp Changes: https://git.openjdk.org/jdk/pull/28963/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374296 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28963.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28963/head:pull/28963 PR: https://git.openjdk.org/jdk/pull/28963 From jiefu at openjdk.org Tue Dec 23 12:37:22 2025 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 23 Dec 2025 12:37:22 GMT Subject: RFR: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics [v2] In-Reply-To: References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: On Tue, 23 Dec 2025 02:05:57 GMT, David Holmes wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a new regex to filter > > That looks good to me. Thanks Thanks @dholmes-ora for the review. The linux-x64/build debug failure was caused by `No space left on device`, which should not be related to this change. So will integrate it later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28956#issuecomment-3686494064 From jaromir.hamala at gmail.com Tue Dec 23 13:36:28 2025 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Tue, 23 Dec 2025 14:36:28 +0100 Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] In-Reply-To: References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com> <5jiZvlBoKaZj1ju-iRHmvncU94Jliq9Ln1d_5GtxEiQ=.68fba04c-beba-49c1-b154-b49671bb73d2@github.com> Message-ID: On Wed, Dec 3, 2025 at 10:35?AM Kevin Walls wrote: > On Tue, 2 Dec 2025 20:59:41 GMT, Jonas Norlinder > wrote: > > >> Since kernel v2.6.12 the Linux ABI have had support for encoding the > clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will > result in the kernel returning only user time. POSIX compliant > implementations of pthread_getcpuclockid for the Linux kernel defaults to > construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return > system+user time, which is what the POSIX standard mandates, see > POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of > glibc, musl etc. that utilities this bit pattern. > >> > >> This PR also results in improved performance and thus a reduced > observer effect, especially for the 100th percentile (max). > >> > >> Before patch: > >> > >> Benchmark Mode Cnt Score Error Units > >> CPUTime.execute sample 7506555 0.008 ? 0.001 ms/op > >> CPUTime.execute:p0.00 sample 0.008 ms/op > >> CPUTime.execute:p0.50 sample 0.008 ms/op > >> CPUTime.execute:p0.90 sample 0.008 ms/op > >> CPUTime.execute:p0.95 sample 0.008 ms/op > >> CPUTime.execute:p0.99 sample 0.012 ms/op > >> CPUTime.execute:p0.999 sample 0.015 ms/op > >> CPUTime.execute:p0.9999 sample 0.021 ms/op > >> CPUTime.execute:p1.00 sample 1.030 ms/op > >> > >> > >> After patch: > >> > >> Benchmark Mode Cnt Score Error Units > >> CPUTime.execute sample 8984189 ? 10?? ms/op > >> CPUTime.execute:p0.00 sample ? 10?? ms/op > >> CPUTime.execute:p0.50 sample ? 10?? ms/op > >> CPUTime.execute:p0.90 sample ? 10?? ms/op > >> CPUTime.execute:p0.95 sample ? 10?? ms/op > >> CPUTime.execute:p0.99 sample 0.001 ms/op > >> CPUTime.execute:p0.999 sample 0.001 ms/op > >> CPUTime.execute:p0.9999 sample 0.006 ms/op > >> CPUTime.execute:p1.00 sample 0.054 ms/op > >> > >> > >> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and > the added microbenchmark. > > > > Jonas Norlinder has updated the pull request incrementally with one > additional commit since the last revision: > > > > Align signature to standard > > Looks good - I remember that fix for parsing the program binary name > containing brackets, good to have it gone. > > ------------- > > Marked as reviewed by kevinw (Reviewer). > > PR Review: > https://git.openjdk.org/jdk/pull/28556#pullrequestreview-3534064399 > Apologies for reviving an old treat. I was experimenting with this change, and I believe there is a further optimisation opportunity: When clockid has TID set to 0, then the kernel treats it as 'the current task' (=which is what getCurrentThreadUserTime() requires) and avoids a radix lookup required for an arbitrary TID. The change: https://github.com/jerrinot/jdk/compare/master...jerrinot:jdk:jh_faster_getCurrentThreadUserTime The benchmark from https://github.com/openjdk/jdk/pull/28556 (switched to nanos + more iterations + fork count): Before: Benchmark Mode Cnt Score Error Units ThreadMXBeanBench.getCurrentThreadUserTime sample 4347067 81.746 ? 0.510 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.00 sample 69.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.50 sample 80.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.90 sample 90.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.95 sample 90.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.99 sample 90.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.999 sample 230.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.9999 sample 1980.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p1.00 sample 653312.000 ns/op After: Benchmark Mode Cnt Score Error Units ThreadMXBeanBench.getCurrentThreadUserTime sample 5081223 70.813 ? 0.325 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.00 sample 59.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.50 sample 70.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.90 sample 70.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.95 sample 70.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.99 sample 80.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.999 sample 170.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p0.9999 sample 1830.000 ns/op ThreadMXBeanBench.getCurrentThreadUserTime:p1.00 sample 425472.000 ns/op There is around 13% latency improvement on average. It increases coupling to kernel internals a bit further, but the original patch already does that by poking the lower bits + Linux has a strong policy on ABI stability. Would you be interested in merging a similar patch? Cheers, Jaromir Hamala -- ?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 jiefu at openjdk.org Tue Dec 23 14:36:17 2025 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 23 Dec 2025 14:36:17 GMT Subject: Integrated: 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics In-Reply-To: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> References: <0cljjvBEXDSmaw_Z-l6WwObWlkW-lFXeadEoK73DNc8=.1e947dd3-88ab-4643-a46c-1e8020c09d64@github.com> Message-ID: <48_h7SneNGaRukjRuz8C7HipCcCDLcVZgK9TqV5dr3I=.99ddf431-a110-4547-9ef3-3842ec2a4348@github.com> On Mon, 22 Dec 2025 15:31:37 GMT, Jie Fu wrote: > Hi all, > > `jdk/internal/platform/cgroup/TestCgroupMetrics.java` fails on machines with common prefix metrics. > > For example, the cpu.stat may be > > usage_usec 5111148455 > user_usec 4457755664 > system_usec 653392790 > core_sched.force_idle_usec 0 > nr_periods 0 > nr_throttled 0 > throttled_usec 0 > nr_burst 0 > burst_usec 0 > nr_throttled_bt 0 > throttled_usec_bt 0 > > > `nr_throttled` and `nr_throttled_bt` are metrics with common prefix. > In this case, the test fails since it only matches the starting metric string. > > The fix just adds one more filter `.filter(l -> l.split("\\s+")[0].equals(metric))`, which would match the metric exactly. This pull request has now been integrated. Changeset: f1c50412 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/f1c50412f0ded30f88720e9489e3ff4dd347ffa3 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28956 From cjplummer at openjdk.org Tue Dec 23 15:49:09 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 23 Dec 2025 15:49:09 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [ ] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update commnets for ClassUnloader Something strange is going on with this PR. I just get 3 separate emails for each of the following commits that were done in the past day: - [Fix the copy-n-paste error](https://github.com/openjdk/jdk/pull/28891/changes/349ae833fb600ab9136ab4f43749d1e5f2c84ca0) - [Update commnets for ClassUnloader](https://github.com/openjdk/jdk/pull/28891/changes/6c144309a091038aaed1d698bd12323f3672c7b9) - [Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java](https://github.com/openjdk/jdk/pull/28891/changes/e8d128e666ee0a8cbbf6d9dc273636b62bd3fb96) However, the PR claims that these commits were all done on Nov 22, not Dec. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3687093047 From cjplummer at openjdk.org Tue Dec 23 15:59:14 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 23 Dec 2025 15:59:14 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 09:47:02 GMT, Kevin Walls wrote: > Comment-only cleanup, didn't spot during previous review. > > Trivial, no code affected. src/hotspot/share/services/diagnosticCommand.cpp line 97: > 95: // Registration of the diagnostic commands. > 96: // Argument specifies to which interfaces a command is made available, > 97: // can also specify if hidden from jcmd help. I kind a liked the "first argument, second argument" approach a bit more. // First argument specifies on which interfaces a command is made available. // Optional second argument specifies if hidden from jcmd help. Default is false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643629971 From kevinw at openjdk.org Tue Dec 23 17:16:53 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 17:16:53 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 15:56:05 GMT, Chris Plummer wrote: >> Comment-only cleanup, didn't spot during previous review. >> >> Trivial, no code affected. > > src/hotspot/share/services/diagnosticCommand.cpp line 97: > >> 95: // Registration of the diagnostic commands. >> 96: // Argument specifies to which interfaces a command is made available, >> 97: // can also specify if hidden from jcmd help. > > I kind a liked the "first argument, second argument" approach a bit more. > > // First argument specifies on which interfaces a command is made available. > // Optional second argument specifies if hidden from jcmd help. Default is false. OK thanks. I was thinking as all the usages here only use one argument, the numbering seems irrelevant. The flags/mask of sources is maybe unusual enough that it's worth keeping the comment. I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed. Any thoughts on if it's worth mentioning? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643824988 From sspitsyn at openjdk.org Tue Dec 23 17:18:07 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Dec 2025 17:18:07 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Message-ID: Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. Testing: - TBD: run mach5 tiers 1-6 ------------- Commit messages: - 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Changes: https://git.openjdk.org/jdk/pull/28965/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28965&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374233 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28965.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28965/head:pull/28965 PR: https://git.openjdk.org/jdk/pull/28965 From naoto at openjdk.org Tue Dec 23 17:39:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Dec 2025 17:39:14 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. AFAIK, Google has been using the system property (cf. comments in https://bugs.openjdk.org/browse/JDK-8267069). So I would rather be on the safer side to emit the warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3687445514 From mdoerr at openjdk.org Tue Dec 23 18:00:55 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 23 Dec 2025 18:00:55 GMT Subject: RFR: 8374296: Comment clean up in os_linux.cpp In-Reply-To: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> References: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> Message-ID: On Tue, 23 Dec 2025 12:21:55 GMT, Kevin Walls wrote: > In src/hotspot/os/linux/os_linux.cpp this comment no longer shows where there is time support code: > > //////////////////////////////////////////////////////////////////////////////// > // time support > > > Orphaned since JDK-8372625, trivially remove. Looks good and trivial. Thanks for cleaning it up! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28963#pullrequestreview-3608872121 From cjplummer at openjdk.org Tue Dec 23 18:03:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 23 Dec 2025 18:03:45 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 17:14:33 GMT, Kevin Walls wrote: >> src/hotspot/share/services/diagnosticCommand.cpp line 97: >> >>> 95: // Registration of the diagnostic commands. >>> 96: // Argument specifies to which interfaces a command is made available, >>> 97: // can also specify if hidden from jcmd help. >> >> I kind a liked the "first argument, second argument" approach a bit more. >> >> // First argument specifies on which interfaces a command is made available. >> // Optional second argument specifies if hidden from jcmd help. Default is false. > > OK thanks. > I was thinking as all the usages here only use one argument, the numbering seems irrelevant. > The flags/mask of sources is maybe unusual enough that it's worth keeping the comment. > > I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed. > Any thoughts on if it's worth mentioning? Yeah, before adding my comment I had to first go digging for that `bool hidden = false` reference. At first it was unclear to me what the comment was even trying to describe. I think if you wanted to delete the comment that would be ok. I don't think we have a comment like this is any of the other numerous sections that register dcmds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2643913760 From cjplummer at openjdk.org Tue Dec 23 19:03:06 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 23 Dec 2025 19:03:06 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn wrote: > Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. > This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. > > The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. > > Testing: > - TBD: run mach5 tiers 1-6 Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28965#pullrequestreview-3609036916 From kevinw at openjdk.org Tue Dec 23 19:24:03 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 19:24:03 GMT Subject: RFR: 8374296: Comment clean up in os_linux.cpp In-Reply-To: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> References: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> Message-ID: On Tue, 23 Dec 2025 12:21:55 GMT, Kevin Walls wrote: > In src/hotspot/os/linux/os_linux.cpp this comment no longer shows where there is time support code: > > //////////////////////////////////////////////////////////////////////////////// > // time support > > > Orphaned since JDK-8372625, trivially remove. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28963#issuecomment-3687701196 From kevinw at openjdk.org Tue Dec 23 19:24:03 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 19:24:03 GMT Subject: Integrated: 8374296: Comment clean up in os_linux.cpp In-Reply-To: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> References: <-2DL8dH2EQ7FfjJ1kn0DyBgFdy9EPolktjsJJ1hwQOM=.dcdb71ce-2c38-4716-a72b-2662771c3002@github.com> Message-ID: On Tue, 23 Dec 2025 12:21:55 GMT, Kevin Walls wrote: > In src/hotspot/os/linux/os_linux.cpp this comment no longer shows where there is time support code: > > //////////////////////////////////////////////////////////////////////////////// > // time support > > > Orphaned since JDK-8372625, trivially remove. This pull request has now been integrated. Changeset: 8d80bac1 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/8d80bac1ec2f5eb66619c9e269d7c44612e1d04c Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8374296: Comment clean up in os_linux.cpp Reviewed-by: mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/28963 From kevinw at openjdk.org Tue Dec 23 19:27:26 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 19:27:26 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2] In-Reply-To: References: Message-ID: > Comment-only cleanup, didn't spot during previous review. > > Trivial, no code affected. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28962/files - new: https://git.openjdk.org/jdk/pull/28962/files/d2f0eff1..7d2bab91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28962&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28962.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28962/head:pull/28962 PR: https://git.openjdk.org/jdk/pull/28962 From kevinw at openjdk.org Tue Dec 23 19:31:53 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 19:31:53 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2] In-Reply-To: References: Message-ID: <63brWTy_pL7Vwh_KV1G6sxwlWSdXQJDEkegRRTzf0yM=.f19c9114-a3e8-4f63-84fa-d83ab7f7043d@github.com> On Tue, 23 Dec 2025 18:00:06 GMT, Chris Plummer wrote: >> OK thanks. >> I was thinking as all the usages here only use one argument, the numbering seems irrelevant. >> The flags/mask of sources is maybe unusual enough that it's worth keeping the comment. >> >> I almost didn't even mention the hidden flag, you go and find the constructor DCmdFactoryImpl(uint32_t flags, bool hidden = false) when clarification is needed. >> Any thoughts on if it's worth mentioning? > > Yeah, before adding my comment I had to first go digging for that `bool hidden = false` reference. At first it was unclear to me what the comment was even trying to describe. I think if you wanted to delete the comment that would be ok. I don't think we have a comment like this is any of the other numerous sections that register dcmds. Yes, so removing the obscure hidden flag from the comment, it can just be: void DCmd::register_dcmds() { // Registration of the diagnostic commands. // Argument specifies on which interfaces a command is made available. But as it is called register_dcmds, commenting that we do "Registration of the diagnostic commands." on the next line is obvious/unnecessary. Updated! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28962#discussion_r2644095159 From cjplummer at openjdk.org Tue Dec 23 19:38:54 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 23 Dec 2025 19:38:54 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 19:27:26 GMT, Kevin Walls wrote: >> Comment-only cleanup, didn't spot during previous review. >> >> Trivial, no code affected. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > update Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28962#pullrequestreview-3609126842 From amenkov at openjdk.org Tue Dec 23 19:59:05 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 23 Dec 2025 19:59:05 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: <8jO_5ZBuZntbryhgJDID8t9BiwXpI78-h3UvXqLYmuI=.0636a3e1-7ad0-44ba-a742-da04643b5b4d@github.com> On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn wrote: > Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. > This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. > > The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. > > Testing: > - TBD: run mach5 tiers 1-6 Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28965#pullrequestreview-3609181295 From iklam at openjdk.org Tue Dec 23 20:14:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Dec 2025 20:14:51 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 20:00:24 GMT, Naoto Sato wrote: > Removing the test from AOT Problem List. The test `java/lang/IO/IO.java` had a dependency on `jdk.internal.le` module, but it was removed in JDK26(https://bugs.openjdk.org/browse/JDK-8361613). Apart from that, the test case itself has been modified to not emit AOT/CDS logging messages in order for the output comparing test to succeed. looks good ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28967#pullrequestreview-3609220658 From kevinw at openjdk.org Tue Dec 23 20:51:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 20:51:02 GMT Subject: RFR: 8374232: Comment cleanup in diagnosticCommand.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 19:27:26 GMT, Kevin Walls wrote: >> Comment-only cleanup, didn't spot during previous review. >> >> Trivial, no code affected. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > update Thanks Chris! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28962#issuecomment-3687923851 From kevinw at openjdk.org Tue Dec 23 20:51:03 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Dec 2025 20:51:03 GMT Subject: Integrated: 8374232: Comment cleanup in diagnosticCommand.cpp In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 09:47:02 GMT, Kevin Walls wrote: > Comment-only cleanup, didn't spot during previous review. > > Trivial, no code affected. This pull request has now been integrated. Changeset: 61cb6d74 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/61cb6d740807f8ef356d88c0328d05be1a33a8c1 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8374232: Comment cleanup in diagnosticCommand.cpp Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/28962 From sspitsyn at openjdk.org Tue Dec 23 22:25:03 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Dec 2025 22:25:03 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn wrote: > Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. > This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. > > The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. > > Testing: > - TBD: run mach5 tiers 1-6 Chris and Alex, thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28965#issuecomment-3688117415 From sspitsyn at openjdk.org Tue Dec 23 22:25:04 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Dec 2025 22:25:04 GMT Subject: Integrated: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: <-9c16Gg2MQ28f9y2sR-Qg5uTHWNx-W2kFB7fSnnPfGE=.02487445-5580-4e1e-bb13-f27a7d67ba00@github.com> On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn wrote: > Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. > This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. > > The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. > > Testing: > - TBD: run mach5 tiers 1-6 This pull request has now been integrated. Changeset: f5249db9 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/28965 From sspitsyn at openjdk.org Tue Dec 23 22:45:03 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Dec 2025 22:45:03 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Message-ID: Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). ------------- Commit messages: - Backport f5249db9c566f87f7fc4f3ed70114a8168babd8b Changes: https://git.openjdk.org/jdk/pull/28968/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28968&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374233 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28968.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28968/head:pull/28968 PR: https://git.openjdk.org/jdk/pull/28968 From amenkov at openjdk.org Wed Dec 24 01:24:09 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 24 Dec 2025 01:24:09 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3609655483 From syan at openjdk.org Wed Dec 24 01:41:12 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 01:41:12 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer wrote: > However, the PR claims that these commits were all done on Nov 22, not Dec. Sorry. I seted the wrong data/time to 2025-11 on mine local machine by mistake. This cause this strange phenomenon ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688364502 From jpai at openjdk.org Wed Dec 24 02:13:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 24 Dec 2025 02:13:02 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 20:00:24 GMT, Naoto Sato wrote: > Removing the test from AOT Problem List. The test `java/lang/IO/IO.java` had a dependency on `jdk.internal.le` module, but it was removed in JDK26(https://bugs.openjdk.org/browse/JDK-8361613). Apart from that, the test case itself has been modified to not emit AOT/CDS logging messages in order for the output comparing test to succeed. test/jdk/java/lang/IO/IO.java line 53: > 51: /* > 52: * @test > 53: * @bug 8305457 8342936 8351435 8344706 8361613 8374217 Hello Naoto, the changes look OK to me. However, the guidelines of using `@bug` for tests https://openjdk.org/guide/#jtreg say: > These bug ids refer to product bugs for which a fix is verified by this test. JBS issues that track changes to the test itself are not listed here. So I think we shouldn't add this bug id here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28967#discussion_r2644619880 From duke at openjdk.org Wed Dec 24 02:59:08 2025 From: duke at openjdk.org (duke) Date: Wed, 24 Dec 2025 02:59:08 GMT Subject: Withdrawn: 8369392: Safepoint sync should suspend GC and Java threads concurrently In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 20:00:15 GMT, Xiaolong Peng wrote: > As @shipilev mentioned in the description description of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), we could rearrange the code and ask GC to suspend after announcing safepoint, GC threads and Java threads will sync simultaneously. [The other option](https://github.com/openjdk/jdk/pull/27739/files) I have test is to split STS synchronize into `synchronize_begin` and `synchronize`, which makes GC thread suspension fully aysnc(same Java threads), but I didn't see big performance difference, therefore I chose the simple solution suggested by Aleksey. > > > Test: > - [x] tier1 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27924 From syan at openjdk.org Wed Dec 24 03:41:26 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 03:41:26 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied Message-ID: Hi all, Test containers/docker/TestMemoryWithSubgroups.java fails on some docker images. If the default user inside docker is non root user, test will report fails "mkdir: cannot create directory '/sys/fs/cgroup/memory': Permission denied". I think it's better to throw SkippedException rather than report failure when it's do not have root permission inside docker. Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. ------------- Commit messages: - 8374322: TestMemoryWithSubgroups.java fails Permission denied Changes: https://git.openjdk.org/jdk/pull/28975/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374322 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28975/head:pull/28975 PR: https://git.openjdk.org/jdk/pull/28975 From cjplummer at openjdk.org Wed Dec 24 06:11:53 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Dec 2025 06:11:53 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3610020463 From sspitsyn at openjdk.org Wed Dec 24 06:11:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Dec 2025 06:11:54 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Thank you for review, Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3688786608 From alanb at openjdk.org Wed Dec 24 06:45:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Dec 2025 06:45:13 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 17:06:30 GMT, Serguei Spitsyn wrote: > Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. > This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. > > The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. > > Testing: > - TBD: run mach5 tiers 1-6 src/hotspot/share/runtime/mountUnmountDisabler.hpp line 59: > 57: > 58: public: > 59: MountUnmountDisabler(bool exlusive = false); In passing, exlusive -> exclusive ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28965#discussion_r2644936219 From syan at openjdk.org Wed Dec 24 07:04:54 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 07:04:54 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v12] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecesary System.gc() and add sleep 1s to wait unload event happen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/6c144309..6fc4bb95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10-11 Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Wed Dec 24 07:25:42 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 07:25:42 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v13] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [ ] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Move the "./bin" after vmekys to new line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/6fc4bb95..fc2e144d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11-12 Stats: 44 lines in 22 files changed: 22 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Wed Dec 24 07:30:53 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 07:30:53 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 20 Dec 2025 04:55:02 GMT, SendaoYan wrote: > The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. All the comments in touched tests has been checked. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688934784 From syan at openjdk.org Wed Dec 24 08:15:39 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 08:15:39 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v14] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <6KN1kYB5JbzGX63M6tumdsgF435oXtobOFFVB39eWVg=.ca762d8a-f728-462b-9d69-ff2d10830883@github.com> > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Use WhiteBox.fulllGC() both for test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/fc2e144d..6610f776 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12-13 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Wed Dec 24 08:15:41 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 08:15:41 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Mon, 22 Dec 2025 03:10:42 GMT, Chris Plummer wrote: >> It seems that, the references is non null at the first time. So it will not unload the classes actually, > > I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made. I have changed the test always use WhiteBox.fullGC() instead of call unloadClass(). This test has been verified locally, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2645091951 From syan at openjdk.org Wed Dec 24 08:22:58 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Dec 2025 08:22:58 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Change the copyright year from 2025 to 2026 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/6610f776..f72866e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13-14 Stats: 61 lines in 61 files changed: 0 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From sspitsyn at openjdk.org Wed Dec 24 08:44:52 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Dec 2025 08:44:52 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Thank you for review, Chris! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3689112049 From sspitsyn at openjdk.org Wed Dec 24 08:50:04 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Dec 2025 08:50:04 GMT Subject: RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: <_OzG6u0Cu6kUO4FJBU8hrntbHMbL28PQKZxj9WDhm70=.4072e357-2828-4fe1-b5ff-0d1e6249f3b9@github.com> On Wed, 24 Dec 2025 06:41:51 GMT, Alan Bateman wrote: >> Please, review a simple fix for a jdk 26 regression: [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343). It will be pushed to 27 first and then back ported to 26. >> This issue impacts JVM TI scalability. The [JDK-8364343](https://bugs.openjdk.org/browse/JDK-8364343) replaced the overloaded ctor `MountUnmountDisabler(jthread thread)` with `MountUnmountDisabler(oop thread_oop)`. This caused the most common JVM TI pattern `MountUnmountDisabler disabler(thread)` (where thread is a jthread) to be resolved to `MountUnmountDisabler(bool exclusive)`. It makes the instantiated `MountUnmountDisabler` to disable `mount/unmount` transitions for all virtual thread instead of the specific one. This problem was identified with a minor tracing. >> >> The fix restores the original ctor `MountUnmountDisabler(jthread thread)`. >> >> Testing: >> - TBD: run mach5 tiers 1-6 > > src/hotspot/share/runtime/mountUnmountDisabler.hpp line 59: > >> 57: >> 58: public: >> 59: MountUnmountDisabler(bool exlusive = false); > > In passing, exlusive -> exclusive Sorry, I've already integrated this PR and missed chance to correct line 59. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28965#discussion_r2645158235 From bulasevich at openjdk.org Wed Dec 24 16:13:22 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 24 Dec 2025 16:13:22 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable Message-ID: The JVM crashes with a SIGSEGV during startup if the runtime image (lib/modules) exists but is unreadable. In this scenario, ClassLoader::get_jrt_entry() returns nullptr, leading to a crash. This change adds a null check to avoid the dereference and bail out gracefully. ------------- Commit messages: - 8374343: Fix SIGSEGV when lib/modules is unreadable Changes: https://git.openjdk.org/jdk/pull/28982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374343 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28982/head:pull/28982 PR: https://git.openjdk.org/jdk/pull/28982 From lmesnik at openjdk.org Thu Dec 25 05:18:02 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 25 Dec 2025 05:18:02 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28968#pullrequestreview-3611860274 From alanb at openjdk.org Thu Dec 25 07:29:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Dec 2025 07:29:57 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 16:06:30 GMT, Boris Ulasevich wrote: > if the runtime image (lib/modules) exists but is unreadable. AOT aside, does this scenario cause problems elsewhere? The JDK has to work with both images and interim exploded builds. I'm wondering if other parts of the runtime will assume an exploded build (and fail) if lib/modules is not accessile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3691068978 From bulasevich at openjdk.org Thu Dec 25 18:21:50 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 25 Dec 2025 18:21:50 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: <_9lQ3JeE8bhYiNuYZc8NASXeKYWPeL4reO86qkcI_KU=.ee3a84af-7dfa-4a6c-ac66-74432c76bd71@github.com> On Wed, 24 Dec 2025 16:06:30 GMT, Boris Ulasevich wrote: > The JVM crashes with a SIGSEGV during startup if the runtime image (lib/modules) exists but is unreadable. In this scenario, ClassLoader::get_jrt_entry() returns nullptr, leading to a crash. This change adds a null check to avoid the dereference and bail out gracefully. > > if the runtime image (lib/modules) exists but is unreadable. > > AOT aside, does this scenario cause problems elsewhere? The JDK has to work with both images and interim exploded builds. I'm wondering if other parts of the runtime will assume an exploded build (and fail) if lib/modules is not accessile. > The JDK has to work with both images and interim exploded builds. I'm wondering if other parts of the runtime will assume an exploded build (and fail) if lib/modules is not accessile. The change is fail-fast: when lib/modules exists but is unreadable, we now report a clear error and exit cleanly instead of crashing: ``` $ ./build/macosx-aarch64-server-release/images/jdk/bin/java [0.032s][warning][class,path] Runtime image (modules) is unreadable or missing - validation failed Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I checked also the interim exploded build case. With broken permissions on lib/modules, there is no SIGSEGV or undefined behavior; the runtime reports an error and exits cleanly. Let me know if you have a concrete failure scenario in mind. I will check it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3691652229 From sspitsyn at openjdk.org Thu Dec 25 23:59:03 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Dec 2025 23:59:03 GMT Subject: [jdk26] RFR: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). Thank you for review, Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28968#issuecomment-3691828495 From sspitsyn at openjdk.org Thu Dec 25 23:59:04 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Dec 2025 23:59:04 GMT Subject: [jdk26] Integrated: 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 22:38:34 GMT, Serguei Spitsyn wrote: > Please, review a jdk 26 backport. This pull request contains a clean backport of simple changeset https://github.com/openjdk/jdk/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > This changeset was reviewed by [Chris Plummer](https://openjdk.org/census#cjplummer) and [Alex Menkov](https://openjdk.org/census#amenkov). This pull request has now been integrated. Changeset: 646037dd Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/646037dd92bac5d3fec94c019830c010c86d101c Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Reviewed-by: amenkov, cjplummer, lmesnik Backport-of: f5249db9c566f87f7fc4f3ed70114a8168babd8b ------------- PR: https://git.openjdk.org/jdk/pull/28968 From serb at openjdk.org Fri Dec 26 03:18:25 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Dec 2025 03:18:25 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28997/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28997&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374365 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/28997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28997/head:pull/28997 PR: https://git.openjdk.org/jdk/pull/28997 From syan at openjdk.org Fri Dec 26 06:44:38 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 06:44:38 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable [v2] In-Reply-To: References: Message-ID: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with two additional commits since the last revision: - Fix year - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/9411a6e7..fe094b55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From syan at openjdk.org Fri Dec 26 06:44:38 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 06:44:38 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable In-Reply-To: References: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com> Message-ID: On Fri, 26 Dec 2025 06:15:21 GMT, Jie Fu wrote: > That's why I would suggest adding it in the place where it requires docker directly, not the place indirectly. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692264918 From jiefu at openjdk.org Fri Dec 26 07:13:50 2025 From: jiefu at openjdk.org (Jie Fu) Date: Fri, 26 Dec 2025 07:13:50 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable [v2] In-Reply-To: References: Message-ID: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> On Fri, 26 Dec 2025 06:44:38 GMT, SendaoYan wrote: >> Hi all, >> >> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. >> >> Change has been verified locally. Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - Fix year > - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86: > 84: > 85: public static void main(String[] args) throws Exception { > 86: DockerTestUtils.checkCanTestDocker(); Thanks for the update. Can you explain why here requires docker service directly? >From the logs in JBS, I guess the places should be where the following docker files are required? Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2647686625 From phh at openjdk.org Fri Dec 26 22:58:54 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Dec 2025 22:58:54 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569 From serb at openjdk.org Sat Dec 27 07:07:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:07:04 GMT Subject: Integrated: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 9512a43e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk/pull/28997 From serb at openjdk.org Sat Dec 27 07:30:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:30:59 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137 From syan at openjdk.org Mon Dec 29 08:38:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:38:51 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v3] In-Reply-To: References: Message-ID: <_nWN7E-jJuR_2ZhDZdsSgfLWtlBpUI5R1qAxjOLx3yo=.eb153abc-a164-434e-96ac-4a892b79ac2f@github.com> > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Check cpu period and cpuset avaialable before test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/fe094b55..1be8d17a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01-02 Stats: 12 lines in 2 files changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From syan at openjdk.org Mon Dec 29 08:40:56 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:40:56 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v2] In-Reply-To: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> References: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> Message-ID: On Fri, 26 Dec 2025 07:10:03 GMT, Jie Fu wrote: >> SendaoYan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix year >> - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester > > test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86: > >> 84: >> 85: public static void main(String[] args) throws Exception { >> 86: DockerTestUtils.checkCanTestDocker(); > > Thanks for the update. > > Can you explain why here requires docker service directly? > > From the logs in JBS, I guess the places should be where the following docker files are required? > > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat I think this test fails because the cpuset in unmounted. So I updated the JBS titile and comments. And I added check 'cpu period' and 'cpu set' available or not before subtest, rather than check the docker service. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2650463886 From syan at openjdk.org Mon Dec 29 08:48:15 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:48:15 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/1be8d17a..068b1591 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From jwaters at openjdk.org Tue Dec 30 16:34:13 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 30 Dec 2025 16:34:13 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: <2ZSG4oArv4YV6JQdpH66cvyzqpyX8UWpjm2MlOq6CVg=.d5584943-9238-4aeb-90f6-dcab8d5d2b28@github.com> On Mon, 18 Nov 2024 06:08:08 GMT, Julian Waters wrote: >> SpinPause is currently not implemented on any Windows platforms, due to a lack of access to assembly in the Microsoft compiler. The YieldProcessor macro can act as a stand in for this purpose, as it compiles down to a single pause instruction on x64 (Which seems to be all that one needs to implement SpinPause in HotSpot). I am less certain about the Windows/ARM64 implementation. There, YieldProcessor compiles down to dmb ishst; yield and I am unsure whether that is a correct SpinPause implementation. If need be, I can retract the ARM64 implementation and only have this for x86 > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'openjdk:master' into patch-13 > - Merge branch 'master' into patch-13 > - Swap to handwritten assembly to implement SpinPause in os_windows_aarch64.cpp > - YieldProcessor in os_windows_aarch64.cpp > - 8343249 I'm still not sure how to test this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3699881032