From aboldtch at openjdk.org Fri Jan 2 04:26:57 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 2 Jan 2026 04:26:57 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v4] 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 four additional commits since the last revision: - Merge tag 'jdk-27+3' into JDK-8371762 Added tag jdk-27+3 for changeset 4f283f18 - 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/77e0abdf..5842ae15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=02-03 Stats: 71581 lines in 1436 files changed: 45436 ins; 18779 del; 7366 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 kbarrett at openjdk.org Fri Jan 2 07:26:08 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 07:26:08 GMT Subject: RFR: 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp Message-ID: Please review this simple change to a recently added gtest to avoid triggering -Wzero-as-null-pointer-constant warnings when that warning is enabled. There are two parts to the change. One is just an obvious replacement of 0 with nullptr. The other is the removal of a gtest assertion. That assertion's predicate is attempting to verify the CompressedKlassPointers state has been initialized. But the test being used (null pointer <= base pointer) is technically invalid; ordered comparisons between a pointer and null are UB. And even ignoring that, the compiler may decide the comparison is tautologially true, or it may always be true at runtime, because pointer comparison is treated as unsigned by at least some compilers. It would be better done via an is_initialized() function in CompressedKlassPointers, or use == with the initial "uninitialized" value of -1. But we're already asserting initialization in the implementation of the base() function, so at least in debug builds we've already verified initialization. It doesn't seem worthwhile adding is_initialized() or breaking through the abstraction and using -1. Testing: mach5 tier1 ------------- Commit messages: - fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp Changes: https://git.openjdk.org/jdk/pull/29016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374446 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29016/head:pull/29016 PR: https://git.openjdk.org/jdk/pull/29016 From naoto at openjdk.org Fri Jan 2 18:27:34 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Jan 2026 18:27:34 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: > 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. Naoto Sato 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: - Reverted bugid in the test - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28967/files - new: https://git.openjdk.org/jdk/pull/28967/files/44f2fff4..b98b83a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28967&range=00-01 Stats: 4448 lines in 1946 files changed: 965 ins; 390 del; 3093 mod Patch: https://git.openjdk.org/jdk/pull/28967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28967/head:pull/28967 PR: https://git.openjdk.org/jdk/pull/28967 From naoto at openjdk.org Fri Jan 2 18:27:36 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Jan 2026 18:27:36 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 02:09:57 GMT, Jaikiran Pai wrote: >> Naoto Sato 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: >> >> - Reverted bugid in the test >> - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList >> - initial commit > > 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. You're right. Reverted the bug ID in the test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28967#discussion_r2658200576 From kbarrett at openjdk.org Fri Jan 2 20:00:04 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Jan 2026 20:00:04 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v4] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 04:26:57 GMT, Axel Boldt-Christmas wrote: >> [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). >> >> * Testin... > > 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 four additional commits since the last revision: > > - Merge tag 'jdk-27+3' into JDK-8371762 > > Added tag jdk-27+3 for changeset 4f283f18 > - 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 src/hotspot/share/runtime/arguments.cpp line 1219: > 1217: > 1218: int c_or_eof = getc(stream); > 1219: while (c_or_eof != EOF && pos < (int)(sizeof(token) - 1)) { [pre-existing] We wouldn't need the cast if `pos` were correctly typed as `size_t`. src/hotspot/share/runtime/arguments.cpp line 1225: > 1223: // below (which would be incorrect if we ever compared to a non-ascii char), > 1224: // and the int to char conversions we would otherwise do in the assignments. > 1225: const char c = checked_cast(checked_cast(c_or_eof)); Why is this using `checked_cast` at all? Just assume `getc` correctly implements its documented behavior, and use `static_cast(c_or_eof)` to silence (hopefully eventual) `-Wconversion` warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28283#discussion_r2658318458 PR Review Comment: https://git.openjdk.org/jdk/pull/28283#discussion_r2658316948 From jpai at openjdk.org Sun Jan 4 01:41:09 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Jan 2026 01:41:09 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:27:34 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. > > Naoto Sato 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: > > - Reverted bugid in the test > - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList > - initial commit Thank you for the update, Naoto. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28967#pullrequestreview-3624625183 From dholmes at openjdk.org Mon Jan 5 05:32:00 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 5 Jan 2026 05:32:00 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: <3bgbu2vKZ7JhDWvuBPVTIpUFA45cwvoO3ew-x2-2Ipk=.26dde9f2-c47b-458f-ae79-64dc6c15489c@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. To get to the point where we crash this way a lot of stuff under lib has to exist and be readable (e.g. native libs), so why is modules not readable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3708991647 From dholmes at openjdk.org Mon Jan 5 07:03:46 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 5 Jan 2026 07:03:46 GMT Subject: RFR: 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount Message-ID: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> Please review this trivial fix to add a `range(0,1024)` to the develop flag `PreallocatedOutOfMemoryErrorCount` to avoid absurdly large values from causing a crash. Anyone who needs an even larger value can easily change it directly. Testing: manual (no regression test warranted) Thanks ------------- Commit messages: - 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount Changes: https://git.openjdk.org/jdk/pull/29027/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374456 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29027/head:pull/29027 PR: https://git.openjdk.org/jdk/pull/29027 From jonas.norlinder at oracle.com Mon Jan 5 09:38:01 2026 From: jonas.norlinder at oracle.com (Jonas Norlinder) Date: Mon, 5 Jan 2026 09:38:01 +0000 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: Hi Jaromir, That sounds interesting :), as long as we are confident that your observation is part of the user ABI. Feel free to submit a PR and I will happily review it. Also add a link or reasoning to confirm that it is part of the user ABI. Thank you, Jonas From: hotspot-runtime-dev on behalf of Jaromir Hamala Date: Tuesday, 23 December 2025 at 14:36 To: Kevin Walls Cc: hotspot-runtime-dev at openjdk.org Subject: Re: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU time with clock_gettime [v7] 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 jwaters at openjdk.org Mon Jan 5 10:03:05 2026 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Jan 2026 10:03:05 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: 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 Paging for anyone to come look at this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3709741017 From coleenp at openjdk.org Mon Jan 5 13:31:31 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 Jan 2026 13:31:31 GMT Subject: RFR: 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount In-Reply-To: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> References: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> Message-ID: On Mon, 5 Jan 2026 06:56:26 GMT, David Holmes wrote: > Please review this trivial fix to add a `range(0,1024)` to the develop flag `PreallocatedOutOfMemoryErrorCount` to avoid absurdly large values from causing a crash. Anyone who needs an even larger value can easily change it directly. > > Testing: manual (no regression test warranted) > > Thanks Looks good and trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29027#pullrequestreview-3626845317 From naoto at openjdk.org Mon Jan 5 17:20:31 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Jan 2026 17:20:31 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: <1wIcRHdAvCGaMY6HiHewDAdCHFUi0mJgJN0PKY4rb4s=.18fcee6b-d667-42de-9934-a4c759feefcf@github.com> On Fri, 2 Jan 2026 18:27:34 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. > > Naoto Sato 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: > > - Reverted bugid in the test > - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList > - initial commit Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28967#issuecomment-3711344510 From naoto at openjdk.org Mon Jan 5 17:20:32 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Jan 2026 17:20:32 GMT Subject: Integrated: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: <32_4HTHwNl9_7aQxovrEdXjNjObYm3WM7FShxoZrl1g=.ce491b24-57c7-4055-a0a8-d7bbcd972c4a@github.com> 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. This pull request has now been integrated. Changeset: 27dbdec2 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/27dbdec297fc8030812f7290a7601b6a99defb46 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod 8374217: Remove IO.java test from AOT ProblemList Reviewed-by: jpai, iklam ------------- PR: https://git.openjdk.org/jdk/pull/28967 From dholmes at openjdk.org Mon Jan 5 20:13:38 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 5 Jan 2026 20:13:38 GMT Subject: RFR: 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount In-Reply-To: References: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> Message-ID: On Mon, 5 Jan 2026 13:27:22 GMT, Coleen Phillimore wrote: >> Please review this trivial fix to add a `range(0,1024)` to the develop flag `PreallocatedOutOfMemoryErrorCount` to avoid absurdly large values from causing a crash. Anyone who needs an even larger value can easily change it directly. >> >> Testing: manual (no regression test warranted) >> >> Thanks > > Looks good and trivial. Thanks for the review @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29027#issuecomment-3711926173 From dholmes at openjdk.org Mon Jan 5 20:13:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 5 Jan 2026 20:13:40 GMT Subject: Integrated: 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount In-Reply-To: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> References: <7JXShatpcubyIkXrEyJNxcycGkvqXd-CDsEmIoJmwho=.5dea46fa-acd4-4d5a-a3ea-9a46c66c632d@github.com> Message-ID: On Mon, 5 Jan 2026 06:56:26 GMT, David Holmes wrote: > Please review this trivial fix to add a `range(0,1024)` to the develop flag `PreallocatedOutOfMemoryErrorCount` to avoid absurdly large values from causing a crash. Anyone who needs an even larger value can easily change it directly. > > Testing: manual (no regression test warranted) > > Thanks This pull request has now been integrated. Changeset: de81d389 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/de81d38995356a2e8528a419ebd445e79cd136d1 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/29027 From dholmes at openjdk.org Tue Jan 6 02:11:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:11:14 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 03:34:05 GMT, SendaoYan wrote: > 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. I think this has been discussed in the past and it was considered a test environment configuration error and so should be reported rather than being silently ignored. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3712817189 From dholmes at openjdk.org Tue Jan 6 02:24:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:24:41 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 08:48:15 GMT, SendaoYan wrote: >> 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 A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 87: > 85: public static void main(String[] args) throws Exception { > 86: Metrics m = Metrics.systemMetrics(); > 87: // If cgroups is not configured, report success Suggestion: // If cgroups is not configured, the test is skipped. test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > 371: long oldVal = metrics.getCpuPeriod(); > 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { > 373: System.out.println("Get cpu period fails, test skipped."); Note sure this indicates a "fail" as such. ------------- PR Review: https://git.openjdk.org/jdk/pull/28996#pullrequestreview-3629079111 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663353307 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663359000 From syan at openjdk.org Tue Jan 6 02:41:57 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 02:41:57 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:07:54 GMT, David Holmes wrote: > I think this has been discussed in the past and it was considered a test environment configuration error and so should be reported rather than being silently ignored. Okey. Thanks David. I will close this issue as 'not a issue' ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3712878108 From syan at openjdk.org Tue Jan 6 02:41:59 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 02:41:59 GMT Subject: Withdrawn: 8374322: TestMemoryWithSubgroups.java fails Permission denied In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 03:34:05 GMT, SendaoYan wrote: > 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28975 From dholmes at openjdk.org Tue Jan 6 02:47:09 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:47:09 GMT Subject: RFR: 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 07:18:06 GMT, Kim Barrett wrote: > Please review this simple change to a recently added gtest to avoid triggering > -Wzero-as-null-pointer-constant warnings when that warning is enabled. > > There are two parts to the change. One is just an obvious replacement of 0 > with nullptr. > > The other is the removal of a gtest assertion. That assertion's predicate is > attempting to verify the CompressedKlassPointers state has been initialized. > But the test being used (null pointer <= base pointer) is technically invalid; > ordered comparisons between a pointer and null are UB. And even ignoring that, > the compiler may decide the comparison is tautologially true, or it may always > be true at runtime, because pointer comparison is treated as unsigned by at > least some compilers. It would be better done via an is_initialized() function > in CompressedKlassPointers, or use == with the initial "uninitialized" value > of -1. But we're already asserting initialization in the implementation of the > base() function, so at least in debug builds we've already verified > initialization. It doesn't seem worthwhile adding is_initialized() or breaking > through the abstraction and using -1. > > Testing: mach5 tier1 Fix seems trivially fine. Removal of the assertion sounds reasonable based on your explanation Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29016#pullrequestreview-3629124068 From syan at openjdk.org Tue Jan 6 02:52:18 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 02:52:18 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v5] 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 comment "If cgroups is not configured, the test is skipped." which suggestion from @dholmes-ora Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/068b1591..8e2ee419 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03-04 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 syan at openjdk.org Tue Jan 6 03:04:21 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:04:21 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: <5qxuuuhHvgrHEPlLUV-O8Ngykq5lufQ5n_IbmXxeu0k=.65dc5916-245b-412b-a60f-1c0058464051@github.com> On Tue, 6 Jan 2026 02:19:32 GMT, David Holmes wrote: >> 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 > > test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > >> 371: long oldVal = metrics.getCpuPeriod(); >> 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { >> 373: System.out.println("Get cpu period fails, test skipped."); > > Note sure this indicates a "fail" as such. The `getCpuPeriod` call `getLongValue` to read property value from file /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us. The `getLongValue` will return CgroupSubsystem.LONG_RETVAL_UNLIMITED if it can not open the file. So I think it's better to skip this sub-test when there is no /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663425108 From syan at openjdk.org Tue Jan 6 03:08:51 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:08:51 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:21:44 GMT, David Holmes wrote: > A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. This PR use SkippedException instead of report test pass. It's unrelated to the subject, It just fix it by the way ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3712926235 From syan at openjdk.org Tue Jan 6 07:33:12 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 07:33:12 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v2] In-Reply-To: References: 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. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Revert "8374322: TestMemoryWithSubgroups.java fails Permission denied" This reverts commit be21ae5d78e63673cfaaa79be70d47f7331f5298. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28975/files - new: https://git.openjdk.org/jdk/pull/28975/files/be21ae5d..0c8f3101 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 7 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 syan at openjdk.org Tue Jan 6 07:39:19 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 07:39:19 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v3] In-Reply-To: References: 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. > > Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add --user root when start docker container ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28975/files - new: https://git.openjdk.org/jdk/pull/28975/files/0c8f3101..865add95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 syan at openjdk.org Tue Jan 6 08:00:32 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 08:00:32 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:38:31 GMT, SendaoYan wrote: > I will close this issue as 'not a issue' I reopen this PR, since [JDK-8374322](https://bugs.openjdk.org/browse/JDK-8374322) and [JDK-8351382](https://bugs.openjdk.org/browse/JDK-8351382) are the different issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3713576050 From dholmes at openjdk.org Tue Jan 6 09:09:03 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 09:09:03 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 07:39:19 GMT, SendaoYan wrote: >> 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. >> >> Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add --user root when start docker container test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2: > 1: /* > 2: * Copyright (C) 2025, 2026, BELLSOFT. All rights reserved. Unless you work for Bellsoft, or have been requested by them to update their copyright then you should not modify it. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28975#discussion_r2664194350 From syan at openjdk.org Tue Jan 6 09:15:53 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 09:15:53 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v4] In-Reply-To: References: Message-ID: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> > 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. > > Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Revert the copyright change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28975/files - new: https://git.openjdk.org/jdk/pull/28975/files/865add95..b1b2a482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 dholmes at openjdk.org Tue Jan 6 09:15:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 09:15:56 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 07:39:19 GMT, SendaoYan wrote: >> 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. >> >> Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add --user root when start docker container I am running this through our tier5 testing ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3713824902 From syan at openjdk.org Tue Jan 6 09:15:58 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 09:15:58 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 09:05:32 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Add --user root when start docker container > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2: > >> 1: /* >> 2: * Copyright (C) 2025, 2026, BELLSOFT. All rights reserved. > > Unless you work for Bellsoft, or have been requested by them to update their copyright then you should not modify it. Thanks Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28975#discussion_r2664211020 From dholmes at openjdk.org Tue Jan 6 12:20:01 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 12:20:01 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v4] In-Reply-To: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> References: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> Message-ID: On Tue, 6 Jan 2026 09:15:53 GMT, SendaoYan wrote: >> 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. >> >> Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Revert the copyright change Test passed. Fix seems fine for our CI. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28975#pullrequestreview-3630694329 From syan at openjdk.org Tue Jan 6 12:50:27 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 12:50:27 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v4] In-Reply-To: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> References: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> Message-ID: On Tue, 6 Jan 2026 09:15:53 GMT, SendaoYan wrote: >> 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". This PR add docker run parameter `--user root` to force use root user inside docker containter. >> >> Change has been verified locally on ubuntu22(cgroup v2). Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Revert the copyright change Thanks David for the reviews and verify. Looking for 2rd reviewer since touch the hotspot files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3714576436 From bulasevich at openjdk.org Tue Jan 6 14:14:54 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Tue, 6 Jan 2026 14:14:54 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: > 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. Right. The asymmetric permission model can occur in hardened, policy-driven customer deployments, where native libraries and runtime images end up being subject to different access rules. We don?t have full details of the original customer setup; however, we can reproduce the same crash by denying access to lib/modules, and we think it?s worth fixing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3714845621 From kbarrett at openjdk.org Tue Jan 6 15:06:45 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Jan 2026 15:06:45 GMT Subject: RFR: 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:43:41 GMT, David Holmes wrote: >> Please review this simple change to a recently added gtest to avoid triggering >> -Wzero-as-null-pointer-constant warnings when that warning is enabled. >> >> There are two parts to the change. One is just an obvious replacement of 0 >> with nullptr. >> >> The other is the removal of a gtest assertion. That assertion's predicate is >> attempting to verify the CompressedKlassPointers state has been initialized. >> But the test being used (null pointer <= base pointer) is technically invalid; >> ordered comparisons between a pointer and null are UB. And even ignoring that, >> the compiler may decide the comparison is tautologially true, or it may always >> be true at runtime, because pointer comparison is treated as unsigned by at >> least some compilers. It would be better done via an is_initialized() function >> in CompressedKlassPointers, or use == with the initial "uninitialized" value >> of -1. But we're already asserting initialization in the implementation of the >> base() function, so at least in debug builds we've already verified >> initialization. It doesn't seem worthwhile adding is_initialized() or breaking >> through the abstraction and using -1. >> >> Testing: mach5 tier1 > > Fix seems trivially fine. > > Removal of the assertion sounds reasonable based on your explanation > > Thanks Thanks for reviewing @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/29016#issuecomment-3715047709 From kbarrett at openjdk.org Tue Jan 6 15:09:28 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Jan 2026 15:09:28 GMT Subject: Integrated: 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp In-Reply-To: References: Message-ID: <2Qm-bzvqWFBJz2mZi-MOt8oplhT7Qi9PU0OTzn8GZmQ=.e15c3ebc-5a50-4b26-b373-4348bc6395a3@github.com> On Fri, 2 Jan 2026 07:18:06 GMT, Kim Barrett wrote: > Please review this simple change to a recently added gtest to avoid triggering > -Wzero-as-null-pointer-constant warnings when that warning is enabled. > > There are two parts to the change. One is just an obvious replacement of 0 > with nullptr. > > The other is the removal of a gtest assertion. That assertion's predicate is > attempting to verify the CompressedKlassPointers state has been initialized. > But the test being used (null pointer <= base pointer) is technically invalid; > ordered comparisons between a pointer and null are UB. And even ignoring that, > the compiler may decide the comparison is tautologially true, or it may always > be true at runtime, because pointer comparison is treated as unsigned by at > least some compilers. It would be better done via an is_initialized() function > in CompressedKlassPointers, or use == with the initial "uninitialized" value > of -1. But we're already asserting initialization in the implementation of the > base() function, so at least in debug builds we've already verified > initialization. It doesn't seem worthwhile adding is_initialized() or breaking > through the abstraction and using -1. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 32144282 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/3214428203642e986c47eabc29ebdea93016b2c5 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29016 From dholmes at openjdk.org Tue Jan 6 21:02:45 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 21:02:45 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: > 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. My concern is that we cannot test all possible behaviours for all permutations of making some files accessible and others not. I do not think it makes any sense to have different access rules for files that form part of the same application. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3716324921 From dholmes at openjdk.org Tue Jan 6 23:27:05 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 23:27:05 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: > This change adds a null check to avoid the dereference and bail out gracefully. Note however that it need not actually lead to a failure, and in the process could cause a startup delay while AOT retries the archive loading. So a customer with this unexpected configuration may still not be happy about what they observe happen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3716709862