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