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 From iklam at openjdk.org Wed Jan 7 04:49:42 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 Jan 2026 04:49:42 GMT Subject: RFR: 8374662: Remove unused type check functions from javaClasses.hpp Message-ID: Please review this trivial patch. These functions are never used and should be removed. ------------- Commit messages: - 8374662: Remove unused type check functions from javaClasses.hpp Changes: https://git.openjdk.org/jdk/pull/29077/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29077&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374662 Stats: 24 lines in 2 files changed: 0 ins; 22 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29077/head:pull/29077 PR: https://git.openjdk.org/jdk/pull/29077 From iklam at openjdk.org Wed Jan 7 07:15:44 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 Jan 2026 07:15:44 GMT Subject: RFR: 8374662: Remove unused type check functions from javaClasses.hpp [v2] In-Reply-To: References: Message-ID: > Please review this trivial patch. > > These functions are never used and should be removed. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8374662-remove-unused-type-check-functions-from-javaClasses-hpp - 8374662: Remove unused type check functions from javaClasses.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29077/files - new: https://git.openjdk.org/jdk/pull/29077/files/bbf4858d..4efcfcac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29077&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29077&range=00-01 Stats: 16474 lines in 468 files changed: 3268 ins; 1863 del; 11343 mod Patch: https://git.openjdk.org/jdk/pull/29077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29077/head:pull/29077 PR: https://git.openjdk.org/jdk/pull/29077 From jsjolen at openjdk.org Wed Jan 7 08:08:45 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 7 Jan 2026 08:08:45 GMT Subject: RFR: 8374662: Remove unused type check functions from javaClasses.hpp [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 07:15:44 GMT, Ioi Lam wrote: >> Please review this trivial patch. >> >> These functions are never used and should be removed. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8374662-remove-unused-type-check-functions-from-javaClasses-hpp > - 8374662: Remove unused type check functions from javaClasses.hpp OK and trivial, but: Were you able to track down where these were used previously? ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29077#pullrequestreview-3633756349 From sgehwolf at openjdk.org Wed Jan 7 11:05:55 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 7 Jan 2026 11:05:55 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v7] In-Reply-To: <5h0H88T94IL0wqziVkv_Oz0e8MCBH14HDMNqOxGrmaE=.0281b797-2f05-4caa-b944-60211ac37f6c@github.com> References: <5h0H88T94IL0wqziVkv_Oz0e8MCBH14HDMNqOxGrmaE=.0281b797-2f05-4caa-b944-60211ac37f6c@github.com> Message-ID: On Sat, 20 Dec 2025 00:56:30 GMT, SendaoYan wrote: >> Hi all, >> >> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. >> >> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. >> >> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. >> >> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > System.out.println("Waiting for all two JVMs to start"); > > Co-authored-by: Severin Gehwolf Seems fine. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26605#pullrequestreview-3634363065 From syan at openjdk.org Wed Jan 7 11:51:15 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 7 Jan 2026 11:51:15 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v7] In-Reply-To: References: <5h0H88T94IL0wqziVkv_Oz0e8MCBH14HDMNqOxGrmaE=.0281b797-2f05-4caa-b944-60211ac37f6c@github.com> Message-ID: On Wed, 7 Jan 2026 11:02:22 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> System.out.println("Waiting for all two JVMs to start"); >> >> Co-authored-by: Severin Gehwolf > > Seems fine. Thanks for the reviews and suggestions @jerboaa @fandreuz @caspernorrbin ------------- PR Comment: https://git.openjdk.org/jdk/pull/26605#issuecomment-3718510515 From syan at openjdk.org Wed Jan 7 11:54:58 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 7 Jan 2026 11:54:58 GMT Subject: Integrated: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails In-Reply-To: References: Message-ID: On Sat, 2 Aug 2025 14:48:41 GMT, SendaoYan wrote: > Hi all, > > The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. > > If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. > > This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. > > The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. > > Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: 929864b1 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/929864b1a40eb222d3b7b3451fc6d4e5316a7cc8 Stats: 15 lines in 2 files changed: 9 ins; 0 del; 6 mod 8362087: Test containers/docker/ShareTmpDir.java intermittent fails Reviewed-by: sgehwolf, cnorrbin ------------- PR: https://git.openjdk.org/jdk/pull/26605 From syan at openjdk.org Wed Jan 7 12:32:41 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 7 Jan 2026 12:32:41 GMT Subject: [jdk26] RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails Message-ID: <4vz7JguE0Ymij92ncwu2mrcEhlLiw5tuyATqo-SXHUg=.16cffc5b-2360-4bc0-8a3a-3e0cab705fb5@github.com> Hi all, This pull request contains a backport of commit [929864b1](https://github.com/openjdk/jdk/commit/929864b1a40eb222d3b7b3451fc6d4e5316a7cc8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 7 Jan 2026 and was reviewed by Severin Gehwolf and Casper Norrbin. Thanks! ------------- Commit messages: - Backport 929864b1a40eb222d3b7b3451fc6d4e5316a7cc8 Changes: https://git.openjdk.org/jdk/pull/29087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362087 Stats: 15 lines in 2 files changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29087/head:pull/29087 PR: https://git.openjdk.org/jdk/pull/29087 From syan at openjdk.org Wed Jan 7 13:13:02 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 7 Jan 2026 13:13:02 GMT Subject: [jdk26] Withdrawn: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails In-Reply-To: <4vz7JguE0Ymij92ncwu2mrcEhlLiw5tuyATqo-SXHUg=.16cffc5b-2360-4bc0-8a3a-3e0cab705fb5@github.com> References: <4vz7JguE0Ymij92ncwu2mrcEhlLiw5tuyATqo-SXHUg=.16cffc5b-2360-4bc0-8a3a-3e0cab705fb5@github.com> Message-ID: On Wed, 7 Jan 2026 12:25:11 GMT, SendaoYan wrote: > Hi all, > > This is clean backport to fix the test bug which may cause test intermittent fails. Change has been verified locally on linux-x64 by run the touched test test/hotspot/jtreg/containers/docker/ShareTmpDir.java. Test-fix only, no risk, > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29087 From mbaesken at openjdk.org Wed Jan 7 13:14:38 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 Jan 2026 13:14:38 GMT Subject: RFR: 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name Message-ID: We got the following error today on Linux Alpine : command: driver TestOptionsWithRanges 9 of 10 reason: User specified action: run driver/timeout=1800 TestOptionsWithRanges 9 of 10 java.lang.Error: Expected only "int", "intx", "size_t", "uint", "uintx", "uint64_t", or "double" option types! Got [Global type! at optionsvalidation.JVMOption.createVMOption(JVMOption.java:117) at optionsvalidation.JVMOptionsUtils.getJVMOptions(JVMOptionsUtils.java:282) at optionsvalidation.JVMOptionsUtils.getOptionsAsMap(JVMOptionsUtils.java:477) at optionsvalidation.JVMOptionsUtils.getOptionsWithRangeAsMap(JVMOptionsUtils.java:548) at TestOptionsWithRanges.main(TestOptionsWithRanges.java:213) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1516) It would be helpful to get the option name in the Error output, but this is not yet available. So we should add it. ------------- Commit messages: - JDK-8374711 Changes: https://git.openjdk.org/jdk/pull/29089/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29089&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374711 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29089.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29089/head:pull/29089 PR: https://git.openjdk.org/jdk/pull/29089 From mdoerr at openjdk.org Wed Jan 7 13:51:14 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 Jan 2026 13:51:14 GMT Subject: RFR: 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:06:49 GMT, Matthias Baesken wrote: > We got the following error today on Linux Alpine : > > > command: driver TestOptionsWithRanges 9 of 10 > reason: User specified action: run driver/timeout=1800 TestOptionsWithRanges 9 of 10 > > java.lang.Error: Expected only "int", "intx", "size_t", "uint", "uintx", "uint64_t", or "double" option types! Got [Global type! > at optionsvalidation.JVMOption.createVMOption(JVMOption.java:117) > at optionsvalidation.JVMOptionsUtils.getJVMOptions(JVMOptionsUtils.java:282) > at optionsvalidation.JVMOptionsUtils.getOptionsAsMap(JVMOptionsUtils.java:477) > at optionsvalidation.JVMOptionsUtils.getOptionsWithRangeAsMap(JVMOptionsUtils.java:548) > at TestOptionsWithRanges.main(TestOptionsWithRanges.java:213) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would be helpful to get the option name in the Error output, but this is not yet available. So we should add it. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29089#pullrequestreview-3634986608 From syan at openjdk.org Wed Jan 7 14:03:21 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 7 Jan 2026 14:03:21 GMT Subject: RFR: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 Message-ID: Hi all, Sorry for the regression issue introduced by JDK-8362087. In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two. This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters. Change has been verified locally on linux-x64 by run the test 100 times and all passed. ------------- Commit messages: - 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 Changes: https://git.openjdk.org/jdk/pull/29093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374721 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29093/head:pull/29093 PR: https://git.openjdk.org/jdk/pull/29093 From bulasevich at openjdk.org Wed Jan 7 18:54:06 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 7 Jan 2026 18:54:06 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:23:08 GMT, David Holmes wrote: > So a customer with this unexpected configuration may still not be happy about what they observe happen. I understand your concern, but the VM should not crash (producing a coredump, triggering various monitoring systems, etc.) when it can just shut down the same way as for other initialization errors -- especially if the crash can be prevented by such a small fix. Do you see a better solution? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3720283448 From iklam at openjdk.org Wed Jan 7 20:14:00 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 Jan 2026 20:14:00 GMT Subject: RFR: 8374639: Static archive with AOTClassLinking breaks dynamic archive Message-ID: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> **Bug fix** The assert happens because [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) (Array classes should be stored in dynamic CDS archive) is not compatible with `AOTClassLinking` since JDK 26. Since the benefit of [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) is small (obj array classes can be quickly created at run time), we should remove [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240). **Background** The incompatibility is caused by [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550) (Preload classes from AOT cache during VM bootstrap) added in JDK 26. [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) adds support for scenarios like this: - class `Foo` is in the static archive, but `Foo[]` is not in the static archive - class `Foo[]` is in the dynamic archive There's a pointer from the InstanceKlass of `Foo` to its array class `Foo[]` (`InstanceKlass::_array_klasses`). With [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240), we update this pointer to point to `Foo[]` right after the CDS archives are mapped. This happens before `vmClasses::resolve_all()`: https://github.com/openjdk/jdk/blob/dd20e9150666f247af61dfa524a170ef7dd96c03/src/hotspot/share/cds/aotMetaspace.cpp#L2162 With [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), if the static archive has AOT-linked classes, we will restore all of its classes inside `vmClasses::resolve_all()` -- see the callstack in the Description of [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639). The class restoration requires that all the classes (both instance classes and their array classes) must have a Java mirror. In this example, `Foo` is from the static archive and has an archived Java mirror, so we are OK. However, `Foo[]` is from the dynamic archive and doesn't have an archived mirror. Also, we are too early in the bootstrap process so we are unable to allocate a Java mirror from the heap yet. Hence the assert. ------------- Commit messages: - 8374639: Static archive with AOTClassLinking breaks dynamic archive Changes: https://git.openjdk.org/jdk/pull/29078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374639 Stats: 486 lines in 10 files changed: 95 ins; 380 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29078/head:pull/29078 PR: https://git.openjdk.org/jdk/pull/29078 From coleenp at openjdk.org Wed Jan 7 20:32:56 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Jan 2026 20:32:56 GMT Subject: RFR: 8374639: Static archive with AOTClassLinking breaks dynamic archive In-Reply-To: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> References: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> Message-ID: On Wed, 7 Jan 2026 06:10:58 GMT, Ioi Lam wrote: > **Bug fix** > > The assert happens because [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) (Array classes should be stored in dynamic CDS archive) is not compatible with `AOTClassLinking` since JDK 26. > > Since the benefit of [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) is small (obj array classes can be quickly created at run time), we should remove [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240). > > **Background** > > The incompatibility is caused by [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550) (Preload classes from AOT cache during VM bootstrap) added in JDK 26. > > [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) adds support for scenarios like this: > > - class `Foo` is in the static archive, but `Foo[]` is not in the static archive > - class `Foo[]` is in the dynamic archive > > There's a pointer from the InstanceKlass of `Foo` to its array class `Foo[]` (`InstanceKlass::_array_klasses`). With [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240), we update this pointer to point to `Foo[]` right after the CDS archives are mapped. This happens before `vmClasses::resolve_all()`: > > https://github.com/openjdk/jdk/blob/dd20e9150666f247af61dfa524a170ef7dd96c03/src/hotspot/share/cds/aotMetaspace.cpp#L2162 > > With [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), if the static archive has AOT-linked classes, we will restore all of its classes inside `vmClasses::resolve_all()` -- see the callstack in the Description of [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639). > > The class restoration requires that all the classes (both instance classes and their array classes) must have a Java mirror. In this example, `Foo` is from the static archive and has an archived Java mirror, so we are OK. However, `Foo[]` is from the dynamic archive and doesn't have an archived mirror. Also, we are too early in the bootstrap process so we are unable to allocate a Java mirror from the heap yet. Hence the assert. So for the static archive, there will still be InstanceKlass::_array_klasses saved, just not for dynamic archive? This looks really good. It is easy to recreate array classes on demand as they're needed. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29078#pullrequestreview-3636683248 From matsaave at openjdk.org Wed Jan 7 20:54:03 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 7 Jan 2026 20:54:03 GMT Subject: RFR: 8374639: Static archive with AOTClassLinking breaks dynamic archive In-Reply-To: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> References: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> Message-ID: <3cvwJ8QusXpliyINkBGdEzdDnwJVO-rmU0gusKeS1S0=.34d27518-cf22-4a28-9209-c9bd5117d688@github.com> On Wed, 7 Jan 2026 06:10:58 GMT, Ioi Lam wrote: > **Bug fix** > > The assert happens because [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) (Array classes should be stored in dynamic CDS archive) is not compatible with `AOTClassLinking` since JDK 26. > > Since the benefit of [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) is small (obj array classes can be quickly created at run time), we should remove [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240). > > **Background** > > The incompatibility is caused by [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550) (Preload classes from AOT cache during VM bootstrap) added in JDK 26. > > [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) adds support for scenarios like this: > > - class `Foo` is in the static archive, but `Foo[]` is not in the static archive > - class `Foo[]` is in the dynamic archive > > There's a pointer from the InstanceKlass of `Foo` to its array class `Foo[]` (`InstanceKlass::_array_klasses`). With [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240), we update this pointer to point to `Foo[]` right after the CDS archives are mapped. This happens before `vmClasses::resolve_all()`: > > https://github.com/openjdk/jdk/blob/dd20e9150666f247af61dfa524a170ef7dd96c03/src/hotspot/share/cds/aotMetaspace.cpp#L2162 > > With [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), if the static archive has AOT-linked classes, we will restore all of its classes inside `vmClasses::resolve_all()` -- see the callstack in the Description of [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639). > > The class restoration requires that all the classes (both instance classes and their array classes) must have a Java mirror. In this example, `Foo` is from the static archive and has an archived Java mirror, so we are OK. However, `Foo[]` is from the dynamic archive and doesn't have an archived mirror. Also, we are too early in the bootstrap process so we are unable to allocate a Java mirror from the heap yet. Hence the assert. This change looks good! It will also help in lworld considering we ran into similar problems with the array metadata refactor. Thanks! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29078#pullrequestreview-3636748558 From dholmes at openjdk.org Wed Jan 7 21:38:59 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 7 Jan 2026 21:38:59 GMT Subject: RFR: 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name In-Reply-To: References: Message-ID: <8cozABhNA_I_TlM4dPcb2c_9iBLuLSvhSw_U0PSHDPg=.6278d3fc-ac83-4161-87f1-05a48c954efe@github.com> On Wed, 7 Jan 2026 13:06:49 GMT, Matthias Baesken wrote: > We got the following error today on Linux Alpine : > > > command: driver TestOptionsWithRanges 9 of 10 > reason: User specified action: run driver/timeout=1800 TestOptionsWithRanges 9 of 10 > > java.lang.Error: Expected only "int", "intx", "size_t", "uint", "uintx", "uint64_t", or "double" option types! Got [Global type! > at optionsvalidation.JVMOption.createVMOption(JVMOption.java:117) > at optionsvalidation.JVMOptionsUtils.getJVMOptions(JVMOptionsUtils.java:282) > at optionsvalidation.JVMOptionsUtils.getOptionsAsMap(JVMOptionsUtils.java:477) > at optionsvalidation.JVMOptionsUtils.getOptionsWithRangeAsMap(JVMOptionsUtils.java:548) > at TestOptionsWithRanges.main(TestOptionsWithRanges.java:213) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would be helpful to get the option name in the Error output, but this is not yet available. So we should add it. Trivial enhancement looks good but I don't think it will help with the underlying issue as it seems to be a problem parsing the output of PrintFlagsRanges ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29089#pullrequestreview-3636887857 From iklam at openjdk.org Wed Jan 7 21:46:10 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 Jan 2026 21:46:10 GMT Subject: RFR: 8374639: Static archive with AOTClassLinking breaks dynamic archive In-Reply-To: References: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> Message-ID: On Wed, 7 Jan 2026 20:29:17 GMT, Coleen Phillimore wrote: > So for the static archive, there will still be InstanceKlass::_array_klasses saved, just not for dynamic archive? This looks really good. It is easy to recreate array classes on demand as they're needed. After this PR, we can still store **some** `ArrayKlasses` in both the static archive and the dynamic archive, and all the pointers `InstanceKlass::_array_klasses`, `ArrayKlass::_higher_dimension`, `ArrayKlass::_lower_dimension`, `ObjArrayKlass::_element_klass`, and `ObjArrayKlass::_bottom_klass` and set properly inside the archives. However, we will no longer have an `ArrayKlass` in the dynamic archive whose element type is in the static archive. Therefore, none of the above pointers will be pointing from one archive to the other. (All the code removed from this PR had to do with setting up such cross-archive pointers). E.g., if you run this app with `-XX:ArchiveClassesAtExit` class Hello { public static void main(String[] args) { System[] x = new System[0]; System.out.println(x); Hello[] y = new Hello[0]; System.out.println(y); } } - `System[]` will not be stored in the dynamic archive (because its element type `System` is in the static archive). - `Hello[]` will be stored in the dynamic archive (because its element type `Hello` is in the dynamic archive). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29078#issuecomment-3720931422 From kbarrett at openjdk.org Wed Jan 7 23:12:15 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 7 Jan 2026 23:12:15 GMT Subject: RFR: 8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast Message-ID: Please review this change to use CompressedOops::narrow_oop_cast instead of potentially UB checked_cast to convert an integer to a narrowOop. narrow_oop_cast does not have the UB problem. Testing: mach5 tier1 ------------- Commit messages: - use narrow_oop_cast Changes: https://git.openjdk.org/jdk/pull/29100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374712 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29100/head:pull/29100 PR: https://git.openjdk.org/jdk/pull/29100 From sspitsyn at openjdk.org Thu Jan 8 00:51:04 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Jan 2026 00:51:04 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v5] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge - review: replace fix with just one assert - Merge - review: restored the assert and fixed the issue caused it to fire - 8373366: HandshakeState should disallow suspend ops for disabler threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d1f391b4..f2e6d731 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=03-04 Stats: 33054 lines in 2876 files changed: 11894 ins; 4275 del; 16885 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From kvn at openjdk.org Thu Jan 8 01:11:41 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 8 Jan 2026 01:11:41 GMT Subject: RFR: 8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 23:04:43 GMT, Kim Barrett wrote: > Please review this change to use CompressedOops::narrow_oop_cast instead of > potentially UB checked_cast to convert an integer to a narrowOop. > narrow_oop_cast does not have the UB problem. > > Testing: mach5 tier1 Trivial. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29100#pullrequestreview-3637340927 From dhanalla at openjdk.org Thu Jan 8 01:17:59 2026 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Thu, 8 Jan 2026 01:17:59 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 23:56:24 GMT, Brian Stafford wrote: >> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup spaces > > LGTM @brianjstafford, could you please re?review this PR with the latest iteration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28461#issuecomment-3721493896 From dhanalla at openjdk.org Thu Jan 8 01:22:07 2026 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Thu, 8 Jan 2026 01:22:07 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 19:03:46 GMT, Dhamoder Nalla wrote: >> Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. >> >> Tests performed: jtreg tier1 & tier2 > > Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision: > > cleanup spaces @theRealAph, could you please help with the review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28461#issuecomment-3721501154 From kbarrett at openjdk.org Thu Jan 8 04:46:03 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 8 Jan 2026 04:46:03 GMT Subject: RFR: 8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 01:08:41 GMT, Vladimir Kozlov wrote: >> Please review this change to use CompressedOops::narrow_oop_cast instead of >> potentially UB checked_cast to convert an integer to a narrowOop. >> narrow_oop_cast does not have the UB problem. >> >> Testing: mach5 tier1 > > Trivial. Thanks for reviewing @vnkozlov ------------- PR Comment: https://git.openjdk.org/jdk/pull/29100#issuecomment-3721850591 From kbarrett at openjdk.org Thu Jan 8 04:46:05 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 8 Jan 2026 04:46:05 GMT Subject: Integrated: 8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 23:04:43 GMT, Kim Barrett wrote: > Please review this change to use CompressedOops::narrow_oop_cast instead of > potentially UB checked_cast to convert an integer to a narrowOop. > narrow_oop_cast does not have the UB problem. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 70669d05 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/70669d0585c708e04befe0f9ba945f6154f9afec Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/29100 From iklam at openjdk.org Thu Jan 8 05:35:13 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 Jan 2026 05:35:13 GMT Subject: RFR: 8374662: Remove unused type check functions from javaClasses.hpp [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 08:04:53 GMT, Johan Sj?len wrote: > OK and trivial, but: Were you able to track down where these were used previously? `NativeEntryPoint::is_instance()` was first called from `ciObjectFactory::create_new_object(oop o)` in here: https://github.com/openjdk/jdk/commit/0fb31dbf3a2adc0f7fb2f9924083908724dcde5a.diff The call was removed from here, and the function became an orphan: https://github.com/openjdk/jdk/commit/81e4bdbe1358b7feced08ba758ddb66415968036.diff The second changeset also added `ABIDescriptor::is_instance()` but there were no callers. I think this was due to cut-and-paste. Thanks @jdksjolen for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29077#issuecomment-3721994063 PR Comment: https://git.openjdk.org/jdk/pull/29077#issuecomment-3721995520 From iklam at openjdk.org Thu Jan 8 05:35:15 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 Jan 2026 05:35:15 GMT Subject: Integrated: 8374662: Remove unused type check functions from javaClasses.hpp In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:41:20 GMT, Ioi Lam wrote: > Please review this trivial patch. > > These functions are never used and should be removed. This pull request has now been integrated. Changeset: 95137580 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/95137580b81fb48474b0d8fb748d9d4af7a27850 Stats: 24 lines in 2 files changed: 0 ins; 22 del; 2 mod 8374662: Remove unused type check functions from javaClasses.hpp Reviewed-by: jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/29077 From dholmes at openjdk.org Thu Jan 8 06:14:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 06:14:29 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes Message-ID: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. Tested with local Linux environments, plus our CI plus GHA. Thanks. ------------- Commit messages: - 8370314: Update signals_posix with new Linux signal codes Changes: https://git.openjdk.org/jdk/pull/29105/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370314 Stats: 39 lines in 1 file changed: 38 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29105.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29105/head:pull/29105 PR: https://git.openjdk.org/jdk/pull/29105 From dholmes at openjdk.org Thu Jan 8 06:16:46 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 06:16:46 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: <1GBa_enxzjUttbpSuYIfjFu2WPvirDLK05CHwFXfd9I=.b6ecea43-3152-4b1e-8d80-8ad918ef25bf@github.com> On Wed, 7 Jan 2026 18:50:48 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. > >> So a customer with this unexpected configuration may still not be happy about what they observe happen. > > I understand your concern, but the VM should not crash (producing a coredump, triggering various monitoring systems, etc.) when it can just shut down the same way as for other initialization errors -- especially if the crash can be prevented by such a small fix. Do you see a better solution? @bulasevich I'd like to investigate how this fix behaves under different conditions but I'm going to be away for a few days - back next Tuesday. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3722196480 From dholmes at openjdk.org Thu Jan 8 06:19:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 06:19:56 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: > There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. > > The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. > > Tested with local Linux environments, plus our CI plus GHA. > > Thanks. David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8370314-posix-signals - 8370314: Update signals_posix with new Linux signal codes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29105/files - new: https://git.openjdk.org/jdk/pull/29105/files/0be67ad8..e4d76bae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29105&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29105&range=00-01 Stats: 17923 lines in 562 files changed: 3878 ins; 2403 del; 11642 mod Patch: https://git.openjdk.org/jdk/pull/29105.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29105/head:pull/29105 PR: https://git.openjdk.org/jdk/pull/29105 From shade at openjdk.org Thu Jan 8 07:33:57 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 07:33:57 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes Looks reasonable, thanks. I wish we could check the hard-coded values with the actual exported values (when available in building with newer GCC), but that is likely hard to do at preprocessor level. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29105#pullrequestreview-3638119868 From dholmes at openjdk.org Thu Jan 8 07:47:25 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 07:47:25 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 07:30:19 GMT, Aleksey Shipilev wrote: > Looks reasonable, thanks. Thanks for the review @shipilev > I wish we could check the hard-coded values with the actual exported values (when available in building with newer GCC), but that is likely hard to do at preprocessor level. `static_assert` in the else of the `#ifndef`? I can try that - though we make assumptions about these sorts of things anyway e.g. SYS_call values. And I don't think these are values that can ever be changed once glibc is exporting them, so we have captured the right value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3722524674 From shade at openjdk.org Thu Jan 8 08:04:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 08:04:41 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 07:44:39 GMT, David Holmes wrote: > `static_assert` in the else of the `#ifndef`? I can try that - though we make assumptions about these sorts of things anyway e.g. SYS_call values. Yeah, something like that. I am sure glibc would not change the constants going forwards. I am only looking for cases where we got the hard-coded value wrong for some reason; so a mechanical check would make sure we did not. Again, this is not worth doing here. It would probably be some sort of macro like `MAKE_SURE_IS_DEFINED_BUT_THINK_OF_BETTER_NAME_FOR_THIS_MACRO(name, value)` that would encapsulate both defined/undefined paths. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3722600743 From shade at openjdk.org Thu Jan 8 08:31:50 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 08:31:50 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 Message-ID: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory 33 | #include "cppstdlib/cstdlib.h" | ^~~~~~~~~~~~~~~~~~~~~ Additional testing: - [ ] GHA ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/29109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374768 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29109/head:pull/29109 PR: https://git.openjdk.org/jdk/pull/29109 From stefank at openjdk.org Thu Jan 8 08:48:43 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Jan 2026 08:48:43 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: On Thu, 8 Jan 2026 08:22:57 GMT, Aleksey Shipilev wrote: > JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: > > > /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory > 33 | #include "cppstdlib/cstdlib.h" > | ^~~~~~~~~~~~~~~~~~~~~ > > > Additional testing: > - [ ] GHA Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29109#pullrequestreview-3638388754 From shade at openjdk.org Thu Jan 8 09:21:40 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 09:21:40 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: <4AateWiPz-9egrWo7sJPcPtgcNXbYwpHiKtUiUYHeHQ=.6dacd65a-0fcb-4d72-a6e9-7df0fdfb0dd5@github.com> On Thu, 8 Jan 2026 08:43:53 GMT, Stefan Karlsson wrote: >> JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: >> >> >> /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory >> 33 | #include "cppstdlib/cstdlib.h" >> | ^~~~~~~~~~~~~~~~~~~~~ >> >> >> Additional testing: >> - [ ] GHA > > Marked as reviewed by stefank (Reviewer). Thanks for review, @stefank! Trivial, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29109#issuecomment-3722945024 From stefank at openjdk.org Thu Jan 8 09:32:07 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Jan 2026 09:32:07 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3722984718 From shade at openjdk.org Thu Jan 8 09:34:36 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 09:34:36 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81) Great! Now we "only" need to turn it into an utility macro and use it everywhere :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3723001776 From mdoerr at openjdk.org Thu Jan 8 09:35:47 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 8 Jan 2026 09:35:47 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: On Thu, 8 Jan 2026 08:22:57 GMT, Aleksey Shipilev wrote: > JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: > > > /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory > 33 | #include "cppstdlib/cstdlib.h" > | ^~~~~~~~~~~~~~~~~~~~~ > > > Additional testing: > - [ ] GHA Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29109#pullrequestreview-3638553601 From stefank at openjdk.org Thu Jan 8 09:35:48 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Jan 2026 09:35:48 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: <8W2HB3tTVPKlWF4KaP_Lon6SxjtorWX5QyEsONkqE4E=.abb307b9-6b8f-41b1-b2c7-62b57e2a400b@github.com> On Thu, 8 Jan 2026 08:43:53 GMT, Stefan Karlsson wrote: >> JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: >> >> >> /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory >> 33 | #include "cppstdlib/cstdlib.h" >> | ^~~~~~~~~~~~~~~~~~~~~ >> >> >> Additional testing: >> - [ ] GHA > > Marked as reviewed by stefank (Reviewer). > Thanks for review, @stefank! Trivial, right? Yes ------------- PR Comment: https://git.openjdk.org/jdk/pull/29109#issuecomment-3722988560 From shade at openjdk.org Thu Jan 8 09:35:49 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 09:35:49 GMT Subject: RFR: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: On Thu, 8 Jan 2026 08:22:57 GMT, Aleksey Shipilev wrote: > JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: > > > /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory > 33 | #include "cppstdlib/cstdlib.h" > | ^~~~~~~~~~~~~~~~~~~~~ > > > Additional testing: > - [ ] GHA Thanks for reviews! S390X cross-compilation jobs have succeeded, so I am integrating to unbreak GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29109#issuecomment-3722995092 From shade at openjdk.org Thu Jan 8 09:35:50 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Jan 2026 09:35:50 GMT Subject: Integrated: 8374768: S390X builds are failing after JDK-8372754 In-Reply-To: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> References: <12WYc4xxSso4PlzHdds1isoOJrimHTZuLERe5zX4a8s=.24377b48-5fb1-495e-8c89-cc1653761549@github.com> Message-ID: On Thu, 8 Jan 2026 08:22:57 GMT, Aleksey Shipilev wrote: > JDK-8372754 introduced a new include in os_linux_s390.cpp, but included a wrong file. So it readily fails in GHA and local builds: > > > /home/runner/work/jdk/jdk/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp:33:10: fatal error: cppstdlib/cstdlib.h: No such file or directory > 33 | #include "cppstdlib/cstdlib.h" > | ^~~~~~~~~~~~~~~~~~~~~ > > > Additional testing: > - [ ] GHA This pull request has now been integrated. Changeset: 067fd3cb Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/067fd3cb2fa6a4a0484a922df8efbde03325ad3d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8374768: S390X builds are failing after JDK-8372754 Reviewed-by: stefank, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/29109 From jsjolen at openjdk.org Thu Jan 8 11:21:46 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 Jan 2026 11:21:46 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily Message-ID: The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. Quote: >When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html ------------- Commit messages: - Remove dead branch Changes: https://git.openjdk.org/jdk/pull/29081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325108 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29081/head:pull/29081 PR: https://git.openjdk.org/jdk/pull/29081 From dholmes at openjdk.org Thu Jan 8 12:08:39 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 12:08:39 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: <5gqW9T9ZPuDLtDNqwXujt7QjmnjHW9SVuvly9PtU4Rw=.f01bf2a1-caab-4a33-8cbe-9f33427c4e6c@github.com> On Thu, 8 Jan 2026 09:32:33 GMT, Aleksey Shipilev wrote: > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81) Yes but in that case we knew the problem was that it did in fact have different values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3723567770 From dholmes at openjdk.org Thu Jan 8 12:08:42 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 12:08:42 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes Also static_assert would only detect an issue with the build platform. The real problem would be if the runtime value was actually different. But there is no way to ask that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3723573142 From stefank at openjdk.org Thu Jan 8 12:25:08 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Jan 2026 12:25:08 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: <5gqW9T9ZPuDLtDNqwXujt7QjmnjHW9SVuvly9PtU4Rw=.f01bf2a1-caab-4a33-8cbe-9f33427c4e6c@github.com> References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> <5gqW9T9ZPuDLtDNqwXujt7QjmnjHW9SVuvly9PtU4Rw=.f01bf2a1-caab-4a33-8cbe-9f33427c4e6c@github.com> Message-ID: On Thu, 8 Jan 2026 12:04:34 GMT, David Holmes wrote: > > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81) > > Yes but in that case we knew the problem was that it did in fact have different values. I don't see anything in the PR or JBS that supports this statement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3723627744 From mbaesken at openjdk.org Thu Jan 8 12:45:38 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Jan 2026 12:45:38 GMT Subject: RFR: 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:06:49 GMT, Matthias Baesken wrote: > We got the following error today on Linux Alpine : > > > command: driver TestOptionsWithRanges 9 of 10 > reason: User specified action: run driver/timeout=1800 TestOptionsWithRanges 9 of 10 > > java.lang.Error: Expected only "int", "intx", "size_t", "uint", "uintx", "uint64_t", or "double" option types! Got [Global type! > at optionsvalidation.JVMOption.createVMOption(JVMOption.java:117) > at optionsvalidation.JVMOptionsUtils.getJVMOptions(JVMOptionsUtils.java:282) > at optionsvalidation.JVMOptionsUtils.getOptionsAsMap(JVMOptionsUtils.java:477) > at optionsvalidation.JVMOptionsUtils.getOptionsWithRangeAsMap(JVMOptionsUtils.java:548) > at TestOptionsWithRanges.main(TestOptionsWithRanges.java:213) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would be helpful to get the option name in the Error output, but this is not yet available. So we should add it. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29089#issuecomment-3723704047 From mbaesken at openjdk.org Thu Jan 8 12:48:22 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Jan 2026 12:48:22 GMT Subject: Integrated: 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:06:49 GMT, Matthias Baesken wrote: > We got the following error today on Linux Alpine : > > > command: driver TestOptionsWithRanges 9 of 10 > reason: User specified action: run driver/timeout=1800 TestOptionsWithRanges 9 of 10 > > java.lang.Error: Expected only "int", "intx", "size_t", "uint", "uintx", "uint64_t", or "double" option types! Got [Global type! > at optionsvalidation.JVMOption.createVMOption(JVMOption.java:117) > at optionsvalidation.JVMOptionsUtils.getJVMOptions(JVMOptionsUtils.java:282) > at optionsvalidation.JVMOptionsUtils.getOptionsAsMap(JVMOptionsUtils.java:477) > at optionsvalidation.JVMOptionsUtils.getOptionsWithRangeAsMap(JVMOptionsUtils.java:548) > at TestOptionsWithRanges.main(TestOptionsWithRanges.java:213) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1516) > > > It would be helpful to get the option name in the Error output, but this is not yet available. So we should add it. This pull request has now been integrated. Changeset: 78b1ca6c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name Reviewed-by: mdoerr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29089 From cnorrbin at openjdk.org Thu Jan 8 13:04:45 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 Jan 2026 13:04:45 GMT Subject: RFR: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:53:59 GMT, SendaoYan wrote: > Hi all, > > Sorry for the regression issue introduced by JDK-8362087. > > In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two. > > This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters. > > Change has been verified locally on linux-x64 by run the test 100 times and all passed. Looks good. Thank you for the fix! ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/29093#pullrequestreview-3639319398 From sgehwolf at openjdk.org Thu Jan 8 15:39:58 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 8 Jan 2026 15:39:58 GMT Subject: RFR: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:53:59 GMT, SendaoYan wrote: > Hi all, > > Sorry for the regression issue introduced by JDK-8362087. > > In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two. > > This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters. > > Change has been verified locally on linux-x64 by run the test 100 times and all passed. Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29093#pullrequestreview-3639996873 From jsjolen at openjdk.org Thu Jan 8 18:10:19 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 Jan 2026 18:10:19 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. > > This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. This is fine! The reason that the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added. > > Thanks! Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix character ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28674/files - new: https://git.openjdk.org/jdk/pull/28674/files/c72c87d0..5cceb010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28674&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28674&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28674/head:pull/28674 PR: https://git.openjdk.org/jdk/pull/28674 From jsjolen at openjdk.org Thu Jan 8 18:10:20 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 Jan 2026 18:10:20 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 03:33:22 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix character > > test/hotspot/jtreg/runtime/ClassFile/NestedAnnotations.java line 64: > >> 62: >> 63: cw.visitEnd(); >> 64: // Does not matter whether the class is hidden, used for simplicity?s sake. > > Check the actual character used for the apostrophe here. When I grabbed the raw file it failed to compile: `unmappable character (0x92) for encoding UTF-8` I checked it with this: https://www.soscisurvey.de/tools/view-chars.php Nothing weird, it seems like the culprit is `?` in "simplicity's" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28674#discussion_r2673356359 From coleenp at openjdk.org Thu Jan 8 18:16:27 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 18:16:27 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:16:57 GMT, Johan Sj?len wrote: > The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. > > Quote: > >>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). > > https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html src/hotspot/os/posix/os_posix.cpp line 460: > 458: return nullptr; > 459: } > 460: if (base != nullptr && addr != base) { Can you turn this into an assert with a comment in the assert string why this isn't possible? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29081#discussion_r2673373919 From jsjolen at openjdk.org Thu Jan 8 18:34:08 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 Jan 2026 18:34:08 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: > The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. > > Quote: > >>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). > > https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Check for expected invariant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29081/files - new: https://git.openjdk.org/jdk/pull/29081/files/f5bf7141..55ffac69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29081&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29081/head:pull/29081 PR: https://git.openjdk.org/jdk/pull/29081 From jsjolen at openjdk.org Thu Jan 8 18:34:10 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 Jan 2026 18:34:10 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:12:47 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for expected invariant > > src/hotspot/os/posix/os_posix.cpp line 460: > >> 458: return nullptr; >> 459: } >> 460: if (base != nullptr && addr != base) { > > Can you turn this into an assert with a comment in the assert string why this isn't possible? Fixed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29081#discussion_r2673424523 From iklam at openjdk.org Thu Jan 8 18:44:49 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 Jan 2026 18:44:49 GMT Subject: RFR: 8374639: Static archive with AOTClassLinking breaks dynamic archive In-Reply-To: References: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> Message-ID: On Wed, 7 Jan 2026 20:29:17 GMT, Coleen Phillimore wrote: >> **Bug fix** >> >> The assert happens because [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) (Array classes should be stored in dynamic CDS archive) is not compatible with `AOTClassLinking` since JDK 26. >> >> Since the benefit of [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) is small (obj array classes can be quickly created at run time), we should remove [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240). >> >> **Background** >> >> The incompatibility is caused by [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550) (Preload classes from AOT cache during VM bootstrap) added in JDK 26. >> >> [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) adds support for scenarios like this: >> >> - class `Foo` is in the static archive, but `Foo[]` is not in the static archive >> - class `Foo[]` is in the dynamic archive >> >> There's a pointer from the InstanceKlass of `Foo` to its array class `Foo[]` (`InstanceKlass::_array_klasses`). With [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240), we update this pointer to point to `Foo[]` right after the CDS archives are mapped. This happens before `vmClasses::resolve_all()`: >> >> https://github.com/openjdk/jdk/blob/dd20e9150666f247af61dfa524a170ef7dd96c03/src/hotspot/share/cds/aotMetaspace.cpp#L2162 >> >> With [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), if the static archive has AOT-linked classes, we will restore all of its classes inside `vmClasses::resolve_all()` -- see the callstack in the Description of [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639). >> >> The class restoration requires that all the classes (both instance classes and their array classes) must have a Java mirror. In this example, `Foo` is from the static archive and has an archived Java mirror, so we are OK. However, `Foo[]` is from the dynamic archive and doesn't have an archived mirror. Also, we are too early in the bootstrap process so we are unable to allocate a Java mirror from the heap yet. Hence the assert. > > So for the static archive, there will still be InstanceKlass::_array_klasses saved, just not for dynamic archive? > This looks really good. It is easy to recreate array classes on demand as they're needed. Thanks @coleenp and @matias9927 for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29078#issuecomment-3725169358 From iklam at openjdk.org Thu Jan 8 18:44:51 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 Jan 2026 18:44:51 GMT Subject: Integrated: 8374639: Static archive with AOTClassLinking breaks dynamic archive In-Reply-To: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> References: <6Y9Lt170EvfKXswD_uxjIJKbcj2WAWbWw6S-NCTn4ng=.b19d17ac-803b-4c3c-97c9-f2795daff2b8@github.com> Message-ID: On Wed, 7 Jan 2026 06:10:58 GMT, Ioi Lam wrote: > **Bug fix** > > The assert happens because [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) (Array classes should be stored in dynamic CDS archive) is not compatible with `AOTClassLinking` since JDK 26. > > Since the benefit of [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) is small (obj array classes can be quickly created at run time), we should remove [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240). > > **Background** > > The incompatibility is caused by [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550) (Preload classes from AOT cache during VM bootstrap) added in JDK 26. > > [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240) adds support for scenarios like this: > > - class `Foo` is in the static archive, but `Foo[]` is not in the static archive > - class `Foo[]` is in the dynamic archive > > There's a pointer from the InstanceKlass of `Foo` to its array class `Foo[]` (`InstanceKlass::_array_klasses`). With [JDK-8309240](https://bugs.openjdk.org/browse/JDK-8309240), we update this pointer to point to `Foo[]` right after the CDS archives are mapped. This happens before `vmClasses::resolve_all()`: > > https://github.com/openjdk/jdk/blob/dd20e9150666f247af61dfa524a170ef7dd96c03/src/hotspot/share/cds/aotMetaspace.cpp#L2162 > > With [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), if the static archive has AOT-linked classes, we will restore all of its classes inside `vmClasses::resolve_all()` -- see the callstack in the Description of [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639). > > The class restoration requires that all the classes (both instance classes and their array classes) must have a Java mirror. In this example, `Foo` is from the static archive and has an archived Java mirror, so we are OK. However, `Foo[]` is from the dynamic archive and doesn't have an archived mirror. Also, we are too early in the bootstrap process so we are unable to allocate a Java mirror from the heap yet. Hence the assert. This pull request has now been integrated. Changeset: 9fd86e37 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/9fd86e37492c419fbae0837f69aab26a201c927e Stats: 486 lines in 10 files changed: 95 ins; 380 del; 11 mod 8374639: Static archive with AOTClassLinking breaks dynamic archive Reviewed-by: coleenp, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/29078 From dholmes at openjdk.org Thu Jan 8 19:47:53 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 19:47:53 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> <5gqW9T9ZPuDLtDNqwXujt7QjmnjHW9SVuvly9PtU4Rw=.f01bf2a1-caab-4a33-8cbe-9f33427c4e6c@github.com> Message-ID: On Thu, 8 Jan 2026 12:21:42 GMT, Stefan Karlsson wrote: > > > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81) > > > > > > Yes but in that case we knew the problem was that it did in fact have different values. > > I don't see anything in the PR or JBS that supports this statement. // Note that the value for MAP_FIXED_NOREPLACE differs between architectures, but all architectures // supported by OpenJDK share the same flag value. But I see we also did this for SEGV_BNDERR so I will use the same pattern. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3725474507 From coleenp at openjdk.org Thu Jan 8 19:50:35 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 19:50:35 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run Message-ID: This simple change from @requires !vm.gc.Z to @requires vm.gc != "Z" Makes the two coops version of this test run and not get: Test results: passed: 2; did not meet platform requirements: 2 Neither of these enables the test to run. @requires vm.gc.Z == false or @requires vm.opt.final.UseZGC == false This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. Tested with the test. ------------- Commit messages: - 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run Changes: https://git.openjdk.org/jdk/pull/29125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374796 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29125/head:pull/29125 PR: https://git.openjdk.org/jdk/pull/29125 From dholmes at openjdk.org Thu Jan 8 20:02:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 20:02:44 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes Though I still think this overly cautious approach is protecting against the "impossible". If the value were ever changed then no binaries compiled on a previous version would work - that is simply not a change that is going to happen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3725526238 From dholmes at openjdk.org Thu Jan 8 20:11:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 Jan 2026 20:11:17 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:34:08 GMT, Johan Sj?len wrote: >> The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. >> >> Quote: >> >>>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). >> >> https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Check for expected invariant Dead code removal seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29081#pullrequestreview-3641064195 From coleenp at openjdk.org Thu Jan 8 23:21:45 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 23:21:45 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: <5Jpa0k_mHXotl5WozMIuN4l1MQ3dPexz-Yx6ZWr0OwU=.4d83cb96-101a-4a32-ab61-a59daa37b8f8@github.com> On Thu, 8 Jan 2026 18:34:08 GMT, Johan Sj?len wrote: >> The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. >> >> Quote: >> >>>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). >> >> https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Check for expected invariant Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29081#pullrequestreview-3641698086 From coleenp at openjdk.org Thu Jan 8 23:21:47 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 23:21:47 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:29:06 GMT, Johan Sj?len wrote: >> src/hotspot/os/posix/os_posix.cpp line 460: >> >>> 458: return nullptr; >>> 459: } >>> 460: if (base != nullptr && addr != base) { >> >> Can you turn this into an assert with a comment in the assert string why this isn't possible? > > Fixed! I like the assert! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29081#discussion_r2674225286 From bstafford at openjdk.org Thu Jan 8 23:31:41 2026 From: bstafford at openjdk.org (Brian Stafford) Date: Thu, 8 Jan 2026 23:31:41 GMT Subject: RFR: 8371651: [AArch64] Populate CPU _features flag on Windows [v2] In-Reply-To: References: Message-ID: <5rAr86RI4O3uYoEMhOBvAVoEg3xS-3kwaDzM4NghVRc=.f7059778-0bf3-4882-bd8f-333a3501cf6d@github.com> On Wed, 10 Dec 2025 19:03:46 GMT, Dhamoder Nalla wrote: >> Populate CPU feature flags on Windows/AArch64 to enable CPU features CRC32, AES, SHA1, SHA2, SHA3, SHA512, PMULL, ASIMD, LSE, SVE, SVE2 and SVEBITPERM. >> >> Tests performed: jtreg tier1 & tier2 > > Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision: > > cleanup spaces LGTM ------------- Marked as reviewed by bstafford (Author). PR Review: https://git.openjdk.org/jdk/pull/28461#pullrequestreview-3641717549 From syan at openjdk.org Fri Jan 9 02:10:52 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 9 Jan 2026 02:10:52 GMT Subject: RFR: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 In-Reply-To: References: Message-ID: <3V6_wN12S3LGBoWgJqfTkI9GYTBgCD2oobw5W_MAJbA=.6cc5186d-27d0-49d3-a53a-4c79ea04d1f3@github.com> On Thu, 8 Jan 2026 15:36:17 GMT, Severin Gehwolf wrote: >> Hi all, >> >> Sorry for the regression issue introduced by JDK-8362087. >> >> In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two. >> >> This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters. >> >> Change has been verified locally on linux-x64 by run the test 100 times and all passed. > > Marked as reviewed by sgehwolf (Reviewer). Thanks for the reviews @jerboaa @caspernorrbin ------------- PR Comment: https://git.openjdk.org/jdk/pull/29093#issuecomment-3726737162 From syan at openjdk.org Fri Jan 9 02:14:03 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 9 Jan 2026 02:14:03 GMT Subject: Integrated: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:53:59 GMT, SendaoYan wrote: > Hi all, > > Sorry for the regression issue introduced by JDK-8362087. > > In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two. > > This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters. > > Change has been verified locally on linux-x64 by run the test 100 times and all passed. This pull request has now been integrated. Changeset: 368de9ff Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/368de9ff2e46e4c66ee57b5fb961804c5d25c42a Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8374721: containers/docker/ShareTmpDir.java timed out after 8362087 Reviewed-by: cnorrbin, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/29093 From shade at openjdk.org Fri Jan 9 07:21:36 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 07:21:36 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: <5SUxaW8Hq8hYv0FO9VtsU3K10I8p2kRiVnSpyoC0T_o=.91ac6446-f91e-476a-bedb-afeeab2a3e05@github.com> On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes I agree it is over-cautious. It is something we can do as a paranoid follow-up for these kind of defines. But it does not block this PR from integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3727517188 From stefank at openjdk.org Fri Jan 9 08:31:19 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 08:31:19 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This simple change from > > @requires !vm.gc.Z > to > @requires vm.gc != "Z" > > Makes the two coops version of this test run and not get: > Test results: passed: 2; did not meet platform requirements: 2 > > Neither of these enables the test to run. > @requires vm.gc.Z == false > or > @requires vm.opt.final.UseZGC == false > > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. > > Tested with the test. Looks good and trivial. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29125#pullrequestreview-3642885408 From shade at openjdk.org Fri Jan 9 10:45:53 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 10:45:53 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: <1lVTtM8jWgVTNxcUpS4ypTHwKus1SIyBMlvtDhl2CDQ=.28ba8080-5622-4b77-8d80-75b842c0829f@github.com> On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. Not a bug, it is a complicated behavior of these properties. `vm.gc.Z` means "Current VM potentially supports ZGC, so you can opt into it later with -XX:+UseZGC" `vm.gc == "Z"` means "Current VM supports ZGC *and* has it currently enabled (e.g. with -XX:+UseZGC, e.g. with additional VM test options)" So `!vm.gc.Z` effectively says "only run these tests if ZGC is not available in VM, e.g. by disabled build feature flag". Which means it is disabled pretty much everywhere. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29125#pullrequestreview-3643384080 From shade at openjdk.org Fri Jan 9 10:48:31 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 10:48:31 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This simple change from > > @requires !vm.gc.Z > to > @requires vm.gc != "Z" > > Makes the two coops version of this test run and not get: > Test results: passed: 2; did not meet platform requirements: 2 > > Neither of these enables the test to run. > @requires vm.gc.Z == false > or > @requires vm.opt.final.UseZGC == false > > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. > > Tested with the test. Looks to be a regression from [JDK-8365932](https://bugs.openjdk.org/browse/JDK-8365932), pull this into JDK 26 as well, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29125#issuecomment-3728382466 From mbaesken at openjdk.org Fri Jan 9 11:43:24 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 Jan 2026 11:43:24 GMT Subject: RFR: 8374872: Cleanup outdated SAP AG copyright header info Message-ID: We have a couple of files with outdated 'SAP AG' copyright header info, this should be fixed. ------------- Commit messages: - JDK-8374872 Changes: https://git.openjdk.org/jdk/pull/29136/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374872 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29136/head:pull/29136 PR: https://git.openjdk.org/jdk/pull/29136 From aartemov at openjdk.org Fri Jan 9 12:05:37 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 9 Jan 2026 12:05:37 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > 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 44 commits: - 8366659: Fixed year in the copyright. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Removed ClearSuccOnSuspend - 8366659: Fixed liveness problem. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed build problem. - 8366659: Fixed build issue. - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed semi-broken tests - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=19 Stats: 1331 lines in 9 files changed: 882 ins; 417 del; 32 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 aartemov at openjdk.org Fri Jan 9 12:05:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 9 Jan 2026 12:05:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v17] In-Reply-To: References: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com> Message-ID: On Mon, 24 Nov 2025 01:32:19 GMT, David Holmes wrote: >>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario? >> >> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :) >> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them. > > @sspitsyn so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes? > > We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing. The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress. > > Agreed the tests are completely artificial but there is no way to test this other than to do that. @dholmes-ora @sspitsyn Please take a look, I have re-worked a bit the logic with a hint from @pchilano. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3728629333 From shade at openjdk.org Fri Jan 9 12:10:55 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 12:10:55 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: <-NKefzToOsVdmHImbXBx2SFlaxlbRpT2pAJfOskmhHA=.8f33b7d6-36d3-456b-8552-18a304fc8b09@github.com> On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This simple change from > > @requires !vm.gc.Z > to > @requires vm.gc != "Z" > > Makes the two coops version of this test run and not get: > Test results: passed: 2; did not meet platform requirements: 2 > > Neither of these enables the test to run. > @requires vm.gc.Z == false > or > @requires vm.opt.final.UseZGC == false > > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. > > Tested with the test. GHA build failure on Linux x86_64 fastdebug likely caused by infra issues. I fixed some this week. Merge from current master if you want to see clean GHA run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29125#issuecomment-3728650591 From pminborg at openjdk.org Fri Jan 9 12:35:28 2026 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 Jan 2026 12:35:28 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: > This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. > > On multiple platforms, tested and passed: > - [x] tier1 > - [x] tier2 > - [x] tier3 > > Not tested: > - [ ] tier4 > - [ ] tier5 > - [ ] tier6 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add a real test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29084/files - new: https://git.openjdk.org/jdk/pull/29084/files/cdb2a594..898e1e41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=01-02 Stats: 81 lines in 2 files changed: 32 ins; 47 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From mbaesken at openjdk.org Fri Jan 9 12:40:48 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 Jan 2026 12:40:48 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' Message-ID: We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. Current Example output : OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: 31671 Try using the -Djava.io.tmpdir= option to select an alternate temp location. Just printing '31671' does not really help me much. And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). ------------- Commit messages: - JDK-8374875 Changes: https://git.openjdk.org/jdk/pull/29138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374875 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29138/head:pull/29138 PR: https://git.openjdk.org/jdk/pull/29138 From mbaesken at openjdk.org Fri Jan 9 12:40:49 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 Jan 2026 12:40:49 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). Btw. when looking at https://github.com/openjdk/jdk/blob/c8c6e7007aec9a568c25dcd5d4242b7911a83bfe/src/hotspot/share/cds/filemap.cpp#L1059-L1062 in case of a write failure, we remove the potentially broken/incomplete file. Should we do this here as well to avoid leftover files ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29138#issuecomment-3728735826 From pminborg at openjdk.org Fri Jan 9 13:13:13 2026 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 Jan 2026 13:13:13 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:35:28 GMT, Per Minborg wrote: >> This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. >> >> On multiple platforms, tested and passed: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> >> Not tested: >> - [ ] tier4 >> - [ ] tier5 >> - [ ] tier6 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a real test test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GeneratedInternedString.java line 48: > 46: .runAOTWorkflow(); > 47: > 48: SimpleCDSAppTester.of("GeneratedInternedString") Should this be a separate test, or is it ok to tag along on the existing one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2676146498 From coleenp at openjdk.org Fri Jan 9 13:15:18 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Jan 2026 13:15:18 GMT Subject: RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This simple change from > > @requires !vm.gc.Z > to > @requires vm.gc != "Z" > > Makes the two coops version of this test run and not get: > Test results: passed: 2; did not meet platform requirements: 2 > > Neither of these enables the test to run. > @requires vm.gc.Z == false > or > @requires vm.opt.final.UseZGC == false > > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. > > Tested with the test. Thanks for reviewing Stefan and Aleksey, and thanks for explaining the GHA failure. It seemed like an infra issue. I'd have to upgrade this bug to backport to JDK 26, but I can do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29125#issuecomment-3728863415 From coleenp at openjdk.org Fri Jan 9 13:17:28 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Jan 2026 13:17:28 GMT Subject: Integrated: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: <22N-D-ExuT0tssPbQuVd4lMXMDJfQ8-4kX0BXUzVFRQ=.d6263898-5690-4cd7-9f15-a2a306f4cd00@github.com> On Thu, 8 Jan 2026 19:44:27 GMT, Coleen Phillimore wrote: > This simple change from > > @requires !vm.gc.Z > to > @requires vm.gc != "Z" > > Makes the two coops version of this test run and not get: > Test results: passed: 2; did not meet platform requirements: 2 > > Neither of these enables the test to run. > @requires vm.gc.Z == false > or > @requires vm.opt.final.UseZGC == false > > This could be a bug in jtreg-ext/requires/VMProps.java support but I was unable to find that. > > Tested with the test. This pull request has now been integrated. Changeset: 6d1bfdf7 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/6d1bfdf7a92e44ff855307f86d1734fad909ea3d Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run Reviewed-by: stefank, shade ------------- PR: https://git.openjdk.org/jdk/pull/29125 From egahlin at openjdk.org Fri Jan 9 15:02:56 2026 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 9 Jan 2026 15:02:56 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:10:19 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. >> >> An example of Java code where we end up with nested annotations is this: >> >> >> import java.lang.annotation.*; >> >> @Retention(RetentionPolicy.RUNTIME) >> public @interface Foo { Bar value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Bar { Baz value();} >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Baz { BarBaz value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface BarBaz { End value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface End { int value(); } >> >> >> @Foo(value = @Bar(value = @Baz(value = @BarBaz(value = @End(value=1))))) >> class Lol { >> >> @Deprecated // <--- This annotation might be missed with my change, as the depth limit is 5 >> void foobar(); >> }; >> >> >> Today, it seems that Java disallows cyclic interface annotations, so each annotation depth has to be a separate class. >> >> I think that such a high nesting of annotations is likely to occur in normal Java code. The only 'public' consumer of annotations is JFR, who looks for `@Deprecated` annotations. Typically, the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. >> >> All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. >> >> A regression test has been added, where we check that the JVM does not crash when provided with a large amount of nesting. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix character It seems very unlikely that anyone will use such deeply nested annotations, so it should be fine for JFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3729262466 From jwaters at openjdk.org Fri Jan 9 16:13:34 2026 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 9 Jan 2026 16:13:34 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:57:46 GMT, David Holmes wrote: > I still remain unconvinced this achieves anything useful. Sorry. Is the concern with the YieldProcessor on x64 or is the ARM64 problematic as well? I reused the stub from Linux for Windows/ARM64, so it shouldn't really be an issue at least. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3729588996 From jwaters at openjdk.org Fri Jan 9 17:20:45 2026 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 9 Jan 2026 17:20:45 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes Looks good! ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/29105#pullrequestreview-3644851004 From lmesnik at openjdk.org Fri Jan 9 17:40:38 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 Jan 2026 17:40:38 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 The fix looks good. Thank you for this improvement. Hope it makes our testing more stable. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3644932150 From lucy at openjdk.org Fri Jan 9 18:37:39 2026 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 9 Jan 2026 18:37:39 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). This change looks helpful to me. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29138#pullrequestreview-3645125033 From sspitsyn at openjdk.org Fri Jan 9 19:34:16 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 19:34:16 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v6] In-Reply-To: References: Message-ID: <6qb1Zla4PZRbLauSfNW0K6KlsoFNpDBGVO9KhGnT1vQ=.94a66d34-a2f0-49e3-bc29-4b259afac6bb@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: keep both: assert and disallow disabler suspend ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/f2e6d731..d2b9a341 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=04-05 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Fri Jan 9 19:43:28 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 19:43:28 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v4] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 00:02:26 GMT, Serguei Spitsyn wrote: > Agreed. We had a private slack discussion with Patricio and decided to construct a test case to catch this situation. I've decided to postpone JBS and PR description changes while I'm working on test coverage. I had to place a comment about it. Update: The issue was is reproducible with the new test (will add it to this PR shortly). Thanks to @pchilano for good ideas! So, current approach is to keep the original fix and also add an assert to the function `SuspendResumeManager::do_owner_suspend()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3730324923 From cjplummer at openjdk.org Fri Jan 9 19:57:11 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:11 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: On Wed, 24 Dec 2025 08:22:58 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Change the copyright year from 2025 to 2026 Changes requested by cjplummer (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > 110: int iter = 0; > 111: while (num == 0) { > 112: // The unload is delayed because it happens asyns should be "async" ------------- PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3609731661 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2677442634 From cjplummer at openjdk.org Fri Jan 9 19:57:15 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Jan 2026 19:57:15 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Update commnets for ClassUnloader test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > 40: * using WhiteBox.fullGC technique. > 41: * > 42: *

The method unloadClass() is provided which call should be "calls" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > 236: * > 237: * @throws Failure if exception other than OutOfMemoryError > 238: * is thrown while trigger full GC should be "triggering" test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 248: > 246: customClassLoader = null; > 247: > 248: // force class unloading by trigger full GC should be "triggering" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644615480 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616395 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2644616746 From sspitsyn at openjdk.org Fri Jan 9 20:19:50 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Jan 2026 20:19:50 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v7] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: move is_vthread_transition_disabler out of DEBUG mode, update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d2b9a341..0405cb63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=05-06 Stats: 17 lines in 5 files changed: 2 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From syan at openjdk.org Sat Jan 10 03:23:52 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:52 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Fix several typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28891/files - new: https://git.openjdk.org/jdk/pull/28891/files/f72866e6..445515d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14-15 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28891/head:pull/28891 PR: https://git.openjdk.org/jdk/pull/28891 From syan at openjdk.org Sat Jan 10 03:23:54 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:54 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v15] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com> Message-ID: <9ddgWMyuGEZC-ZMrnKQkD77T8ufCwsEsbUInbL8_eIM=.87e835a9-f05b-45d4-a437-ae5e00344fa5@github.com> On Fri, 9 Jan 2026 19:51:19 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Change the copyright year from 2025 to 2026 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 112: > >> 110: int iter = 0; >> 111: while (num == 0) { >> 112: // The unload is delayed because it happens asyns > > should be "async" Sorry for the typo bug. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273418 From syan at openjdk.org Sat Jan 10 03:23:56 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 10 Jan 2026 03:23:56 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v11] In-Reply-To: <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <3to4xyHNoj9lZCwBS4HgkvRvvTTUmpYuZTnzznsGNN8=.dc847c71-f018-4845-8c24-8c1cf8cbd4dc@github.com> Message-ID: On Wed, 24 Dec 2025 02:05:21 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 42: > >> 40: * using WhiteBox.fullGC technique. >> 41: * >> 42: *

The method unloadClass() is provided which call > > should be "calls" Thanks. Fixed. > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 238: > >> 236: * >> 237: * @throws Failure if exception other than OutOfMemoryError >> 238: * is thrown while trigger full GC > > should be "triggering" Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678272674 PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2678273095 From sspitsyn at openjdk.org Sat Jan 10 08:15:59 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Jan 2026 08:15:59 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: References: Message-ID: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: add a test reproducing the bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/0405cb63..052a04cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=06-07 Stats: 251 lines in 2 files changed: 251 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From mdoerr at openjdk.org Sat Jan 10 15:34:00 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Sat, 10 Jan 2026 15:34:00 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). I think this makes sense. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29138#pullrequestreview-3646986355 From mdoerr at openjdk.org Sat Jan 10 15:34:00 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Sat, 10 Jan 2026 15:34:00 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:35:06 GMT, Matthias Baesken wrote: > Btw. when looking at > > https://github.com/openjdk/jdk/blob/c8c6e7007aec9a568c25dcd5d4242b7911a83bfe/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > > > in case of a write failure, we remove the potentially broken/incomplete file. > Should we do this here as well to avoid leftover files ? Deleting it probably makes sense. Maybe in a separate RFE? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29138#issuecomment-3733038387 From clanger at openjdk.org Sat Jan 10 19:26:30 2026 From: clanger at openjdk.org (Christoph Langer) Date: Sat, 10 Jan 2026 19:26:30 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29138#pullrequestreview-3647150736 From jnorlinder at openjdk.org Sun Jan 11 12:33:08 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Sun, 11 Jan 2026 12:33:08 GMT Subject: RFR: 8374945: Avoid fstat in os::open Message-ID: Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. ------------- Commit messages: - Remove trailing whitespace - [Linux] Avoid fstat in os::open Changes: https://git.openjdk.org/jdk/pull/29152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374945 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29152/head:pull/29152 PR: https://git.openjdk.org/jdk/pull/29152 From mbaesken at openjdk.org Mon Jan 12 07:49:27 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 12 Jan 2026 07:49:27 GMT Subject: RFR: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29138#issuecomment-3737249347 From mbaesken at openjdk.org Mon Jan 12 07:49:28 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 12 Jan 2026 07:49:28 GMT Subject: Integrated: 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:29:14 GMT, Matthias Baesken wrote: > We have a perfMemory warning about 'Insufficient space for shared memory file'; this currently prints misleading info about 'java.io.tmpdir' and misses to print the directory, so we get no clue where exactly insufficient space is. > > > Current Example output : > OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file: > 31671 > Try using the -Djava.io.tmpdir= option to select an alternate temp location. > > > Just printing '31671' does not really help me much. > And the suggestion to set `java.io.tmpdir ` seems to be wrong; it WAS set in the java - execution the output is from, but is not used in the perfMemory coding (probably intentionally). This pull request has now been integrated. Changeset: 7cf7f01f Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/7cf7f01fb339bf3c5b81d946be8afa71ec267e42 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8374875: Improve perfMemory warning about 'Insufficient space for shared memory file' Reviewed-by: lucy, mdoerr, clanger ------------- PR: https://git.openjdk.org/jdk/pull/29138 From clanger at openjdk.org Mon Jan 12 08:01:18 2026 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 12 Jan 2026 08:01:18 GMT Subject: RFR: 8374872: Cleanup outdated SAP AG copyright header info In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:35:59 GMT, Matthias Baesken wrote: > We have a couple of files with outdated 'SAP AG' copyright header info, this should be fixed. Looks good, although not sure whether the year 2026 should be added in this case. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29136#pullrequestreview-3649521757 From redestad at openjdk.org Mon Jan 12 09:25:44 2026 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 12 Jan 2026 09:25:44 GMT Subject: RFR: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 16:55:08 GMT, Jonas Norlinder wrote: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. This would skip the (weird only-once) `FD_CLOEXEC` block that would be executed on the first successful open. Also the `(...) != 0` seem redundant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3737589012 From jnorlinder at openjdk.org Mon Jan 12 09:37:45 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 12 Jan 2026 09:37:45 GMT Subject: RFR: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 16:55:08 GMT, Jonas Norlinder wrote: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. Thanks for the review, Claes! > This would skip the (weird only-once) FD_CLOEXEC block... Indeed. I will open a PR to remove that check, as it is no longer needed; support for such old kernels ceased long ago. With your comment in mind I think we should wait with this one until we have cleaned up that first. > Also the (...) != 0 seem redundant. Yes. It helped me when I was reading it out loud. Can remove if it confuses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3737635157 From mdoerr at openjdk.org Mon Jan 12 09:45:52 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 12 Jan 2026 09:45:52 GMT Subject: RFR: 8374872: Cleanup outdated SAP AG copyright header info In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:35:59 GMT, Matthias Baesken wrote: > We have a couple of files with outdated 'SAP AG' copyright header info, this should be fixed. Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29136#pullrequestreview-3649896778 From stuefe at openjdk.org Mon Jan 12 10:59:31 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 12 Jan 2026 10:59:31 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> <5gqW9T9ZPuDLtDNqwXujt7QjmnjHW9SVuvly9PtU4Rw=.f01bf2a1-caab-4a33-8cbe-9f33427c4e6c@github.com> Message-ID: On Thu, 8 Jan 2026 19:45:45 GMT, David Holmes wrote: > > > > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81) > > > > > > > > > Yes but in that case we knew the problem was that it did in fact have different values. > > > > > > I don't see anything in the PR or JBS that supports this statement. > > ``` > // Note that the value for MAP_FIXED_NOREPLACE differs between architectures, but all architectures > // supported by OpenJDK share the same flag value. > ``` > > But I see we also did this for SEGV_BNDERR so I will use the same pattern. The MAP_FIXED_NOREPLACE thing was caused by Oracle kernel devs having integrated an Oracle-only patch that later broke binary compatibility if the user program was not compiled on an Oracle machine. It was a security issue. I reported it to Oracle, and they have fixed it by now. > Though I still think this overly cautious approach is protecting against the "impossible". If the value were ever changed then no binaries compiled on a previous version would work - that is simply not a change that is going to happen. You'd think that. I thought this also for MAP_ ... constants. But downstream vendors do make errors, as we saw. But I guess these constants are probably harmless, even if they are wrong. So I am fine with omitting the check here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3737961309 From jsjolen at openjdk.org Mon Jan 12 11:05:16 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 11:05:16 GMT Subject: RFR: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:34:08 GMT, Johan Sj?len wrote: >> The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. >> >> Quote: >> >>>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). >> >> https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Check for expected invariant Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29081#issuecomment-3737978072 From jsjolen at openjdk.org Mon Jan 12 11:05:16 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 11:05:16 GMT Subject: Integrated: 8325108: POSIX map_memory_to_file calls release_memory unnecessarily In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:16:57 GMT, Johan Sj?len wrote: > The implementation of the function os::map_memory_to_file calls os::release_memory if a mmap:ing to a fixed location succeeds but is not at the requested location. A POSIX implementation of mmap is not allowed to succeed and return a different base address if `MAP_FIXED` is supplied, so this is dead code. We can remove it. > > Quote: > >>When MAP_FIXED is set in the flags argument, the implementation is informed that the value of pa shall be addr, exactly. If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to [EINVAL]. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process' pages in the range [pa,pa+len). > > https://pubs.opengroup.org/onlinepubs/009604499/functions/mmap.html This pull request has now been integrated. Changeset: d0aae04d Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/d0aae04d61c90698ab5a01b4389dc6932de63cb7 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod 8325108: POSIX map_memory_to_file calls release_memory unnecessarily Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/29081 From jsjolen at openjdk.org Mon Jan 12 11:24:17 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 11:24:17 GMT Subject: RFR: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: <81Otq5mmT6W5gvAaUju9g4EsrdKocHwCglaTAmI5fF0=.24e84cb9-1816-45bf-9b63-f296771d0d24@github.com> On Sat, 10 Jan 2026 16:55:08 GMT, Jonas Norlinder wrote: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. This patch shouldn't skip the `FD_CLOEXEC` branch, as it does now. Doing so changes the behavior of the code, right?? The comment is really just the code but in the words, I'd prefer it if it gave a hint as to why the condition let's us bail early (like "Linux doesn't let you open a directory with write privileges"). You probably want this code, but better: ```c++ fd = open(...); if (fd != -1) return; // Check whether the file is a directory. // Only needed if O_RDONLY, as you can't open directories with W or X privileges if (oflag & O_ACCMODE) == O_RDONLY) { struct stat buf; ... } #ifdef FD_CL0EXEC ... #endif return fd; ------------- PR Review: https://git.openjdk.org/jdk/pull/29152#pullrequestreview-3650284161 From jsjolen at openjdk.org Mon Jan 12 11:24:19 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 Jan 2026 11:24:19 GMT Subject: RFR: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 09:34:16 GMT, Jonas Norlinder wrote: > > This would skip the (weird only-once) FD_CLOEXEC block... > > Indeed. I will open a PR to remove that check, as it is no longer needed; support for such old kernels ceased long ago. With your comment in mind I think we should wait with this one until we have cleaned up that first. Aha, I missed this exchange during my review. Still, the remainder applies imo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3738073021 From jnorlinder at openjdk.org Mon Jan 12 13:02:12 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 12 Jan 2026 13:02:12 GMT Subject: RFR: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open Message-ID: Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. ------------- Commit messages: - Spacing - Remove obsolete checks Changes: https://git.openjdk.org/jdk/pull/29168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375006 Stats: 39 lines in 1 file changed: 0 ins; 38 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29168/head:pull/29168 PR: https://git.openjdk.org/jdk/pull/29168 From aboldtch at openjdk.org Mon Jan 12 13:12:21 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:12:21 GMT Subject: RFR: 8372246: LogOutputList gtests should not use LogConfiguration LogOutputs [v3] In-Reply-To: References: Message-ID: > A handful of `LogOutputList` tests uses `LogConfiguration::Std[out|err]Log` LogOutputs in its tests. > However these are not setup unless we run the tests in VM mode. > > I suggest we add some dummy `LogOutputs` for `StdoutLog` and `StderrLog` which these tests can use, so they are not depending being a VM test. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372246 - Merge branch 'JDK-8372241' into JDK-8372246 - LogOutputList gtests should not use LogConfiguration LogOutputs ------------- Changes: https://git.openjdk.org/jdk/pull/28416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28416&range=02 Stats: 27 lines in 2 files changed: 10 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28416.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28416/head:pull/28416 PR: https://git.openjdk.org/jdk/pull/28416 From aboldtch at openjdk.org Mon Jan 12 13:12:30 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:12:30 GMT Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init [v3] In-Reply-To: References: Message-ID: > The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait. > > I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM. > > An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372247 - Merge branch 'JDK-8372241' into JDK-8372247 - OSX: Semaphore.trywait requires os::Bsd::clock_init ------------- Changes: https://git.openjdk.org/jdk/pull/28417/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28417&range=02 Stats: 10 lines in 2 files changed: 8 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28417/head:pull/28417 PR: https://git.openjdk.org/jdk/pull/28417 From aboldtch at openjdk.org Mon Jan 12 13:15:24 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:15:24 GMT Subject: RFR: 8372243: ZGC: ZForwardingTest.find_every_other is mistaken for a other VM gtest [v3] In-Reply-To: References: Message-ID: > The current implementation of our GTest runner identifies the category of test by the suffix it adds. > This is either `_vm`, `_other_vm` or `_vm_assert`. This is problematic for `ZForwardingTest.find_every_other` which is a VM test and ends up with the final name `ZForwardingTest.find_every_other_vm` and is mistaken for an other VM test in the filters, but is run as a VM test. Currently `ZForwardingTest.find_every_other` if another VM test has been ran first. > > I propose we enhance our GTest category naming to make this thing impossible by: > 1. Change `_vm`, `_other_vm` and `_vm_assert` to `__vm`, `__other_vm` and `__vm_assert` > 2. Fail to compile tests which end in `_`, `__vm`, `__other_vm` or `__vm_assert` > > Note that this patch uses an undecided hotspot feature in the gtest launcher `std::string_view`. > It would be very unfortunate to not be able to use this feature, as without it (or a similar construction) performing static checking of strings and sub-strings is rather cumbersome. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372243 - Merge branch 'JDK-8372241' into JDK-8372243 - ZGC: ZForwardingTest.find_every_other is mistaken for a other VM gtest ------------- Changes: https://git.openjdk.org/jdk/pull/28412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28412&range=02 Stats: 42 lines in 7 files changed: 18 ins; 7 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/28412.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28412/head:pull/28412 PR: https://git.openjdk.org/jdk/pull/28412 From aboldtch at openjdk.org Mon Jan 12 13:15:35 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:15:35 GMT Subject: RFR: 8372242: Gtest LogTagSet.defaults should run in OTHER VM [v3] In-Reply-To: References: Message-ID: > LogTagSet.defaults checks some of the default `LogTagSet` properties and assumes a fresh VM. This test will fail if the other `LogTagSet` have run first. > > As this test is ment to test the defaults of the LogTagSet, it should be ran in an OTHER VM. > > We might still have problems if logging flags are given to the GTestLauncher. But all our jtreg GTest runners are `@requires vm.flagless`, so this should only occur when running very custom test invocations. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'JDK-8372241' into JDK-8372242 - Merge branch 'JDK-8372241' into JDK-8372242 - Gtest LogTagSet.defaults should run in OTHER VM ------------- Changes: https://git.openjdk.org/jdk/pull/28411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28411&range=02 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28411/head:pull/28411 PR: https://git.openjdk.org/jdk/pull/28411 From aboldtch at openjdk.org Mon Jan 12 13:28:32 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:28:32 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] 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 eight additional commits since the last revision: - Change type of pos to size_t - Use static_cast - Update copyright year - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 - 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/5842ae15..3b7372ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28283&range=03-04 Stats: 40152 lines in 2787 files changed: 17607 ins; 6529 del; 16016 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 aboldtch at openjdk.org Mon Jan 12 13:28:36 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 13:28:36 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 19:54:26 GMT, Kim Barrett wrote: >> 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 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. Seems reasonable to assume `getc` follows its documented behaviour. Changed to `static_cast`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28283#discussion_r2682270777 From jnorlinder at openjdk.org Mon Jan 12 14:57:55 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 12 Jan 2026 14:57:55 GMT Subject: RFR: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 12:50:48 GMT, Jonas Norlinder wrote: > Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. Please note that with the removal of `#ifdef O_CLOEXEC`, we will require building on a system with kernel headers >= 2.6.23 and glibc >= 2.7. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29168#issuecomment-3738952467 From dholmes at openjdk.org Mon Jan 12 20:00:31 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Jan 2026 20:00:31 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: <7bwNS4YXxuEyIbeClQk5zS-X_v1IWk8FbSr7uOyL99U=.6290e5c1-a747-48bd-8bb8-06aa181e4fae@github.com> On Thu, 8 Jan 2026 18:06:17 GMT, Johan Sj?len wrote: >> test/hotspot/jtreg/runtime/ClassFile/NestedAnnotations.java line 64: >> >>> 62: >>> 63: cw.visitEnd(); >>> 64: // Does not matter whether the class is hidden, used for simplicity?s sake. >> >> Check the actual character used for the apostrophe here. When I grabbed the raw file it failed to compile: `unmappable character (0x92) for encoding UTF-8` > > I checked it with this: https://www.soscisurvey.de/tools/view-chars.php > > Nothing weird, it seems like the culprit is `?` in "simplicity's" Yep - smart quote rather than plain ascii single-quote. I see you fixed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28674#discussion_r2683709681 From heidinga at openjdk.org Mon Jan 12 20:10:50 2026 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 12 Jan 2026 20:10:50 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:35:28 GMT, Per Minborg wrote: >> This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. >> >> On multiple platforms, tested and passed: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> >> Not tested: >> - [ ] tier4 >> - [ ] tier5 >> - [ ] tier6 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a real test test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GeneratedInternedString.java line 79: > 77: } > 78: > 79: // A variant using a bespoke record Should the record class be annotated with `@AOTSafeClassInitializer` as well? My understanding of the test framework is that it's looking for a particular error string showing bad values / objects cached in the heap archive. Without the annotation here, we're not attempting to make the record class stay initialized in the archive... Possible I'm missing something here but I don't think we're actually testing the record being saved in an initialized state yet ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2683747809 From dholmes at openjdk.org Mon Jan 12 20:28:04 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Jan 2026 20:28:04 GMT Subject: RFR: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 12:50:48 GMT, Jonas Norlinder wrote: > Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. This cleanup seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29168#pullrequestreview-3652621793 From kbarrett at openjdk.org Tue Jan 13 00:53:20 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 00:53:20 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:28:32 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 eight additional commits since the last revision: > > - Change type of pos to size_t > - Use static_cast > - Update copyright year > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 > - 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 Character constants have type `int` in C, but type `char` in C++. That makes quite a mess of code like this that is using C `getc` and `isspace` and the like. Made worse by it being implementation defined whether `char` is signed or unsigned. Sigh! With that in mind, I can't say this looks good, but I don't have any useful improvements to suggest. So approved. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28283#pullrequestreview-3653326907 From qamai at openjdk.org Tue Jan 13 03:31:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 03:31:36 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/91227712...67a3954f src/hotspot/share/ci/ciArray.cpp line 93: > 91: // Returns T_ILLEGAL if there is no element at the given index. > 92: ciConstant ciArray::element_value(int index) { > 93: assert(index >= 0, "out-of-bounds index: %d", index); IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. src/hotspot/share/ci/ciObject.cpp line 233: > 231: // Observed value is cached, so it doesn't change during compilation. > 232: ciConstant ciObject::identity_hash() { > 233: if (!is_null_object()) { Just a very small nitpick: Usually it is recommended to do an early return pattern instead. src/hotspot/share/ci/ciObject.hpp line 76: > 74: }; > 75: > 76: const int IDENTITY_HASH_OFFSET = -1; `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684670938 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684645067 PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684655292 From qamai at openjdk.org Tue Jan 13 03:31:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 03:31:36 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:16:44 GMT, Quan Anh Mai wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Move test, fix merge garbage >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Typo >> - assert >> - refactorings >> - Typo >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Cleanup >> - identity hash support in C2 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/91227712...67a3954f > > src/hotspot/share/ci/ciObject.hpp line 76: > >> 74: }; >> 75: >> 76: const int IDENTITY_HASH_OFFSET = -1; > > `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. It is also useful to note what this value is. It is not clear at first glance why offset is -1 here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2684658970 From dholmes at openjdk.org Tue Jan 13 05:53:03 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 05:53:03 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 Sorry Julian but this simply does not seem significant enough to warrant detailed review cycles from me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3742090880 From dholmes at openjdk.org Tue Jan 13 06:05:37 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:05:37 GMT Subject: RFR: 8370314: Update signals_posix with new Linux signal codes [v2] In-Reply-To: References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 06:19:56 GMT, David Holmes wrote: >> There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. >> >> The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. >> >> Tested with local Linux environments, plus our CI plus GHA. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8370314-posix-signals > - 8370314: Update signals_posix with new Linux signal codes Okay extra checks omitted - thanks for the reviews and discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3742121522 From dholmes at openjdk.org Tue Jan 13 06:05:37 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:05:37 GMT Subject: Integrated: 8370314: Update signals_posix with new Linux signal codes In-Reply-To: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> References: <5OFidVUZ9PVFUx5dhy8P5XGH_zdLxepDiEvrFq_MzMQ=.dfc87e22-6338-42fd-b098-5172e5baabda@github.com> Message-ID: On Thu, 8 Jan 2026 04:51:38 GMT, David Holmes wrote: > There are a few "new" si_codes defined on Linux that we did not support for error reporting. Some of these are only exposed in more recent glibc versions so we have to hard-wire them for older build environments. > > The changes are all conditional on Linux, except the POLL_IN addition which is conditional on SIGPOLL, which is turn only exists on Linux. > > Tested with local Linux environments, plus our CI plus GHA. > > Thanks. This pull request has now been integrated. Changeset: f4ebf958 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/f4ebf9585f63177584d8c48838ef793407ebce12 Stats: 39 lines in 1 file changed: 38 ins; 0 del; 1 mod 8370314: Update signals_posix with new Linux signal codes Reviewed-by: shade, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/29105 From dholmes at openjdk.org Tue Jan 13 06:10:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:10:36 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:28:32 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 eight additional commits since the last revision: > > - Change type of pos to size_t > - Use static_cast > - Update copyright year > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 > - 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 +1 to what Kim said. :) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28283#pullrequestreview-3653995671 From dholmes at openjdk.org Tue Jan 13 06:20:33 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:20:33 GMT Subject: RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes wrote: >> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. >> >> The mechanism for this already exists courtesy of the virtual thread support. >> >> Testing: >> - tiers 1 - 6 sanity > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Delay suspender whilst target is in-critical > - Revert "8373839: Disable JVM TI suspension during JNI critical regions" > > This reverts commit 7723275e4495cc1f514c531afe752210209617cc. Withdrawing this PR whilst a robust solution is sought. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3742167782 From dholmes at openjdk.org Tue Jan 13 06:20:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 06:20:34 GMT Subject: Withdrawn: 8373839: Disable JVM TI suspension during JNI critical regions In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 01:24:42 GMT, David Holmes wrote: > To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. > > The mechanism for this already exists courtesy of the virtual thread support. > > Testing: > - tiers 1 - 6 sanity This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28884 From kbarrett at openjdk.org Tue Jan 13 06:30:31 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 06:30:31 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:28:32 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 eight additional commits since the last revision: > > - Change type of pos to size_t > - Use static_cast > - Update copyright year > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 > - 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 I think I've changed my mind. I'm retracting my approval (by requesting changes, though right at the moment I'm not sure exactly what changes I want). I need to think about it some more... ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28283#pullrequestreview-3654060908 From dholmes at openjdk.org Tue Jan 13 07:29:05 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Jan 2026 07:29: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: > 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. Okay this seems to work in a reasonable way: > chmod -r build/linux-x64-debug-null-modules/images/jdk/lib/modules > ./build/linux-x64-debug-null-modules/images/jdk/bin/java -Xshare:off -version Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object > ./build/linux-x64-debug-null-modules/images/jdk/bin/java -Xshare:on -version [0.017s][warning][class,path] Runtime image (modules) is unreadable or missing - validation failed Error occurred during initialization of VM Unable to use shared archive. Unrecoverable archive loading error (run with -Xlog:aot,cds for details): Unable to map shared spaces > ./build/linux-x64-debug-null-modules/images/jdk/bin/java -Xshare:auto -version [0.017s][warning][class,path] Runtime image (modules) is unreadable or missing - validation failed Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I remain opposed in principle to trying to deal with parts of the JDK image not being accessible, but will approve this one case under the assumption/expectation this is as fas as it will go. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28982#pullrequestreview-3654253959 From jsjolen at openjdk.org Tue Jan 13 10:17:04 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 13 Jan 2026 10:17:04 GMT Subject: RFR: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 12:50:48 GMT, Jonas Norlinder wrote: > Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29168#pullrequestreview-3655007339 From duke at openjdk.org Tue Jan 13 10:24:27 2026 From: duke at openjdk.org (duke) Date: Tue, 13 Jan 2026 10:24:27 GMT Subject: RFR: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open In-Reply-To: References: Message-ID: <1lN2oBJV0kOQxVuAbpORuas37IOwdDljzO_XStLhFS4=.e944d386-32f8-4168-9bb7-43aab1685278@github.com> On Mon, 12 Jan 2026 12:50:48 GMT, Jonas Norlinder wrote: > Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. @JonasNorlinder Your change (at version c4ee2a9803214767fa414ab50e406abd213cbd21) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29168#issuecomment-3743513221 From cnorrbin at openjdk.org Tue Jan 13 11:03:26 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 13 Jan 2026 11:03:26 GMT Subject: RFR: 8369503: [Linux] Move machine-specific queries to the OSContainer layer Message-ID: Hi everyone, In #27470, we removed most calls up to `os::Linux` from the container/cgroup layer. This PR finishes that work by removing the last few tricky ones. We had one call in `CgroupSubsystem::active_processor_count` and two calls in `CgroupUtil::adjust_controller`. These were harder to untangle because the call in `active_processor_count` was guarded by a cache, and `adjust_controller` was called in the v1/v2 controller constructors. `CgroupSubsystem::active_processor_count` now takes a supplier function for the host CPU count, provided from `OSContainer`. The cache still decides if we call the supplied function, so we keep existing caching functionality. For hierarchy adjustments, I moved the calls out of the cgroup constructors and into `OSContainer`'s initialization, with a new used helper function `CgroupSubsystem::adjust_controllers` that adjusts all controllers. After creating the cgroup subsystem, we adjust the controllers once from `OSContainer`, instead of doing it as the last step of the creation. As a result from these changes, cgroup code no longer needs to include or call `os::Linux` functions. Testing: - Oracle tiers 1-5 - Local container tests on cgroup v1 and v2 on both Podman and Docker ------------- Commit messages: - move os::linux calls out of cgroups Changes: https://git.openjdk.org/jdk/pull/29188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369503 Stats: 45 lines in 8 files changed: 12 ins; 8 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29188/head:pull/29188 PR: https://git.openjdk.org/jdk/pull/29188 From mbaesken at openjdk.org Tue Jan 13 13:56:27 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 13:56:27 GMT Subject: RFR: 8374872: Cleanup outdated SAP AG copyright header info In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:35:59 GMT, Matthias Baesken wrote: > We have a couple of files with outdated 'SAP AG' copyright header info, this should be fixed. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29136#issuecomment-3744450535 From mbaesken at openjdk.org Tue Jan 13 13:56:28 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 13:56:28 GMT Subject: Integrated: 8374872: Cleanup outdated SAP AG copyright header info In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:35:59 GMT, Matthias Baesken wrote: > We have a couple of files with outdated 'SAP AG' copyright header info, this should be fixed. This pull request has now been integrated. Changeset: 49f72658 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/49f7265894652ea243f3a531cf3f9d0b06e53565 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod 8374872: Cleanup outdated SAP AG copyright header info Reviewed-by: clanger, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/29136 From duke at openjdk.org Tue Jan 13 15:52:48 2026 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 13 Jan 2026 15:52:48 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v10] In-Reply-To: References: Message-ID: <7n2dAGnAuj_JvE7hpe9o9-0qqsrJabpynqXIbiG5C8M=.765d9e72-9a35-4922-993d-6d601fc34582@github.com> On Mon, 15 Dec 2025 17:31:20 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into nativelibraries-fix > - add test showing loading symlinked libraries with various combinations > - revert dll_load fix > - Merge branch 'master' into nativelibraries-fix > - add cast > - use os::malloc > - Merge branch 'master' into nativelibraries-fix > - fix compilation > - fix grammar > - add dot in os::dll_load rather than NativeLibraries.java > - ... and 6 more: https://git.openjdk.org/jdk/compare/ad29642d...d03535ce Any security progress in the new year? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3745080385 From eastigeevich at openjdk.org Tue Jan 13 16:43:59 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 13 Jan 2026 16:43:59 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v3] In-Reply-To: References: Message-ID: <9cUx5KUaP2YdgxXDmJabY3oRQMXV4X4W1uf5DZfXZKA=.ac785876-da4c-4ac1-a2bb-d8d8ebc981e0@github.com> On Fri, 12 Dec 2025 23:04:29 GMT, Chad Rakoczy wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Added ded... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Add HotCodeGrouperMoveFunction test src/hotspot/share/runtime/hotCodeGrouper.cpp line 99: > 97: > 98: void HotCodeGrouper::do_grouping(ThreadSampler& sampler) { > 99: while (sampler.has_candidates()) { We need to check if HotCodeHeap has enough space. If it does not we should not relocate candidates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27858#discussion_r2687217064 From kbarrett at openjdk.org Tue Jan 13 17:57:03 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Jan 2026 17:57:03 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:28:32 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 eight additional commits since the last revision: > > - Change type of pos to size_t > - Use static_cast > - Update copyright year > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 > - 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 Never mind - the half-formed idea I had didn't pan out. Approved. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28283#pullrequestreview-3657108055 From coleenp at openjdk.org Tue Jan 13 22:08:27 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Jan 2026 22:08:27 GMT Subject: [jdk26] RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run Message-ID: This is a clean backport of a trivial test change to enable the two tests. ------------- Commit messages: - Backport 6d1bfdf7a92e44ff855307f86d1734fad909ea3d Changes: https://git.openjdk.org/jdk/pull/29209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374796 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29209/head:pull/29209 PR: https://git.openjdk.org/jdk/pull/29209 From duke at openjdk.org Tue Jan 13 22:44:52 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 13 Jan 2026 22:44:52 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v4] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Add check for full HotCodeHeap ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/3697718f..002bffab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=02-03 Stats: 40 lines in 2 files changed: 37 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From duke at openjdk.org Tue Jan 13 23:21:42 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 13 Jan 2026 23:21:42 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v5] In-Reply-To: References: Message-ID: <3ei-Gj5iRPb71kXk4a9-DP4fO8mmwJWV7jGaaAFtabI=.2cfcfdbb-90cc-4da8-8133-a33c15a4b783@github.com> > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: - Fix merge - Merge remote-tracking branch 'origin/master' into JDK-8326205 - Add check for full HotCodeHeap - Add HotCodeGrouperMoveFunction test - Add StessHotCodeGrouper test - Update blob checks - Merge fix - Merge remote-tracking branch 'origin/master' into JDK-8326205 - Clean up - New implementation - ... and 17 more: https://git.openjdk.org/jdk/compare/a5480b0b...de746482 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/002bffab..de746482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=03-04 Stats: 71388 lines in 3424 files changed: 37998 ins; 12707 del; 20683 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From dholmes at openjdk.org Wed Jan 14 01:30:51 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jan 2026 01:30:51 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> References: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> Message-ID: On Sat, 10 Jan 2026 08:15:59 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: add a test reproducing the bug The functional fix seems fine. Could you provide a brief summary in the test about its structure and exactly what scenario it is creating to be tested - thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3658499404 From duke at openjdk.org Wed Jan 14 01:33:37 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 14 Jan 2026 01:33:37 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Fix builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/de746482..9999bf7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=04-05 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From jnorlinder at openjdk.org Wed Jan 14 02:16:40 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 02:16:40 GMT Subject: Integrated: 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 12:50:48 GMT, Jonas Norlinder wrote: > Linux got support for O_CLOEXEC in 2.6.23. This version was released in October 9, 2007. OpenJDK does not support versions that old anymore so this logic can be removed. This pull request has now been integrated. Changeset: 5da70b18 Author: Jonas Norlinder Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/5da70b180461d46b1aa44f24ba3c05efdeb03f49 Stats: 39 lines in 1 file changed: 0 ins; 38 del; 1 mod 8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/29168 From cjplummer at openjdk.org Wed Jan 14 05:38:09 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 05:38:09 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v16] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Sat, 10 Jan 2026 03:23:52 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. >> >> Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. >> >> Additional testing: >> >> - [x] All jtreg tests by fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Fix several typos Looks good now. Thanks! ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3658953058 From shade at openjdk.org Wed Jan 14 06:04:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 06:04:41 GMT Subject: [jdk26] RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 21:59:04 GMT, Coleen Phillimore wrote: > This is a clean backport of a trivial test change to enable the two tests. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29209#pullrequestreview-3659002378 From iklam at openjdk.org Wed Jan 14 06:21:42 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 Jan 2026 06:21:42 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. I agree with David's earlier comment. We must limit the amount of system integrity checks. Otherwise, we would need to propagate the failure. So what do we do with this function that calls `ClassLoader::get_jrt_entry()`: https://github.com/openjdk/jdk/blob/b082a390b77fca7134000bfe631f73bfd082bfa1/src/hotspot/share/cds/aotClassLocation.cpp#L453-L458 Do we need to change it to return a boolean to indicate some sort of failure, or do we need to throw a HotSpot exception? In either way, the callers of this function will be affected and soon every function will need to return a boolean or be declared TRAPS. In HotSpot, we do the system integrity checks early and exit the VM on failures. For example, we already exit the VM if the modules file is removed from `JAVA_HOME`: $ cd images/jdk/lib $ mv modules modules.old $ ../bin/java Error occurred during initialization of VM Failed setting boot class path. The same should be done if the modules file is expected to exist but cannot be opened: --- a/src/hotspot/share/classfile/classLoader.cpp +++ b/src/hotspot/share/classfile/classLoader.cpp @@ -1418,6 +1418,10 @@ char* ClassLoader::lookup_vm_options() { jio_snprintf(modules_path, JVM_MAXPATHLEN, "%s%slib%smodules", Arguments::get_java_home(), fileSep, fileSep); JImage_file =(*JImageOpen)(modules_path, &error); if (JImage_file == nullptr) { + if (Arguments::has_jimage()) { + // The modules file exists but is unreadable or corrupt + vm_exit_during_initialization(err_msg("Unable to load %s", modules_path)); + } return nullptr; } ------------- Changes requested by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28982#pullrequestreview-3659042986 From lmesnik at openjdk.org Wed Jan 14 06:34:00 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 06:34:00 GMT Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <7kgAC4XAKsAf5OWtcoKHzLWZ9-X-7gkrSqZWlGfaswo=.60598d6d-f3a0-440d-a953-bf82de55a268@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748009565 From kbarrett at openjdk.org Wed Jan 14 07:44:42 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Jan 2026 07:44:42 GMT Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:12:30 GMT, Axel Boldt-Christmas wrote: >> The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait. >> >> I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM. >> >> An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'JDK-8372241' into JDK-8372247 > - Merge branch 'JDK-8372241' into JDK-8372247 > - OSX: Semaphore.trywait requires os::Bsd::clock_init I think a better solution would be to change `OSXSemaphore::trywait()` to not call `timedwait`, with the associated `os::javaTimeNanos` calls. Instead, call `semaphore_timedwait` directly, with a zero waitspec. `trywait` is supposed to be fairly lowlevel and "fast", and having it do clock accesses seems wrong. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28417#pullrequestreview-3659315057 From syan at openjdk.org Wed Jan 14 07:57:59 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 14 Jan 2026 07:57:59 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> On Wed, 24 Dec 2025 07:28:14 GMT, SendaoYan wrote: >>> There are references to `nsk.share.gc.GCClassUnloader` in some of the test descriptions that need updating. There are also comments like "Next, debugger forces debuggee to unload class, using memory stressing techique" that need updating. I think you need to review all the test description comments. >>> >>> I think someone from the GC team should review the GC test changes since WB.fullGC() is a very different approach to ClassUnloader. >> >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > >> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. > > All the comments in touched tests has been checked. > @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3748276900 From pminborg at openjdk.org Wed Jan 14 11:21:28 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 14 Jan 2026 11:21:28 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v4] In-Reply-To: References: Message-ID: <-_hxaf2lfkrMsp3TzRwDWlriu3UMHoSSb-uqg5wqNWo=.dcb53190-b3f8-4313-a739-5b558a78101e@github.com> > This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. > > On multiple platforms, tested and passed: > - [x] tier1 > - [x] tier2 > - [x] tier3 > > Not tested: > - [ ] tier4 > - [ ] tier5 > - [ ] tier6 Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Add annotation in test - Merge branch 'master' into record-AOTSafeClassInitializer - Add a real test - Add a test - Annotate Record with AOTSafeClassInitializer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29084/files - new: https://git.openjdk.org/jdk/pull/29084/files/898e1e41..3e9d6730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=02-03 Stats: 35171 lines in 482 files changed: 22472 ins; 8151 del; 4548 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From mbaesken at openjdk.org Wed Jan 14 11:22:32 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Jan 2026 11:22:32 GMT Subject: RFR: 8374998: Failing os::write - remove bad file Message-ID: In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 This should probably be done also in other coding. ------------- Commit messages: - JDK-8374998 Changes: https://git.openjdk.org/jdk/pull/29228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374998 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29228/head:pull/29228 PR: https://git.openjdk.org/jdk/pull/29228 From mbaesken at openjdk.org Wed Jan 14 11:50:35 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Jan 2026 11:50:35 GMT Subject: RFR: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:15:35 GMT, Matthias Baesken wrote: > In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. > https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > This should probably be done also in other coding. There are a few other places in the coding, namely in jfr, where we could consider it too to remove a written file, what do you think ? https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/jfr/writers/jfrStreamWriterHost.inline.hpp#L80-L84 Also this one maybe ? https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp#L388-L392 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29228#issuecomment-3749181032 PR Comment: https://git.openjdk.org/jdk/pull/29228#issuecomment-3749185943 From coleenp at openjdk.org Wed Jan 14 12:49:57 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Jan 2026 12:49:57 GMT Subject: [jdk26] RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 21:59:04 GMT, Coleen Phillimore wrote: > This is a clean backport of a trivial test change to enable the two tests. Thanks Aleksey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29209#issuecomment-3749400962 From coleenp at openjdk.org Wed Jan 14 12:49:58 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Jan 2026 12:49:58 GMT Subject: [jdk26] Integrated: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: <8Fz-nPgbKiZd6Kk9YN2MlDoHg_zPnASh144rxh17ykY=.c88f1a43-4826-4a3c-b62e-e88358bc515c@github.com> On Tue, 13 Jan 2026 21:59:04 GMT, Coleen Phillimore wrote: > This is a clean backport of a trivial test change to enable the two tests. This pull request has now been integrated. Changeset: 90d80f99 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/90d80f99bb86a788418fddea4134b0d388c0ff17 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run Reviewed-by: shade Backport-of: 6d1bfdf7a92e44ff855307f86d1734fad909ea3d ------------- PR: https://git.openjdk.org/jdk/pull/29209 From shade at openjdk.org Wed Jan 14 13:22:21 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Jan 2026 13:22:21 GMT Subject: [jdk26] RFR: 8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 21:59:04 GMT, Coleen Phillimore wrote: > This is a clean backport of a trivial test change to enable the two tests. Sure thing, thanks for handling this for JDK 26! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29209#issuecomment-3749532316 From redestad at openjdk.org Wed Jan 14 15:37:15 2026 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 14 Jan 2026 15:37:15 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> References: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> Message-ID: On Wed, 14 Jan 2026 15:32:36 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fixes > - Remove trailing whitespace > - [Linux] Avoid fstat in os::open Looks good to me ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29152#pullrequestreview-3661342015 From jnorlinder at openjdk.org Wed Jan 14 15:37:16 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 15:37:16 GMT Subject: RFR: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: <5B0RBVWwZQf1mrKeF-BuntESv0iiOMWedsVDLpr8Dsw=.abb50588-89dd-4476-b706-88d347456ad0@github.com> On Sat, 10 Jan 2026 16:55:08 GMT, Jonas Norlinder wrote: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. Sorry for the force-push. I rebased with latest master that included removal of the FD_CLOEXEC block. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3750101481 From jnorlinder at openjdk.org Wed Jan 14 15:37:15 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Wed, 14 Jan 2026 15:37:15 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: References: Message-ID: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Fixes - Remove trailing whitespace - [Linux] Avoid fstat in os::open ------------- Changes: https://git.openjdk.org/jdk/pull/29152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29152&range=01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29152/head:pull/29152 PR: https://git.openjdk.org/jdk/pull/29152 From sgehwolf at openjdk.org Wed Jan 14 15:51:25 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 14 Jan 2026 15:51:25 GMT Subject: RFR: 8369503: [Linux] Move machine-specific queries to the OSContainer layer In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:53:47 GMT, Casper Norrbin wrote: > Hi everyone, > > In #27470, we removed most calls up to `os::Linux` from the container/cgroup layer. This PR finishes that work by removing the last few tricky ones. We had one call in `CgroupSubsystem::active_processor_count` and two calls in `CgroupUtil::adjust_controller`. These were harder to untangle because the call in `active_processor_count` was guarded by a cache, and `adjust_controller` was called in the v1/v2 controller constructors. > > `CgroupSubsystem::active_processor_count` now takes a supplier function for the host CPU count, provided from `OSContainer`. The cache still decides if we call the supplied function, so we keep existing caching functionality. > > For hierarchy adjustments, I moved the calls out of the cgroup constructors and into `OSContainer`'s initialization, with a new used helper function `CgroupSubsystem::adjust_controllers` that adjusts all controllers. After creating the cgroup subsystem, we adjust the controllers once from `OSContainer`, instead of doing it as the last step of the creation. > > As a result from these changes, cgroup code no longer needs to include or call `os::Linux` functions. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1 and v2 on both Podman and Docker This looks OK to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29188#pullrequestreview-3661442059 From lmesnik at openjdk.org Wed Jan 14 15:56:08 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 14 Jan 2026 15:56:08 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v5] In-Reply-To: <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> <08JqY0tXW8Zh0cZ3NYDT4UqZMNIeVoiSLQWxX584aXk=.b3eccb34-5764-4c8b-adb0-ccdf3c778f25@github.com> Message-ID: On Wed, 14 Jan 2026 07:55:31 GMT, SendaoYan wrote: >>> The two kinds of incorrect commets has been updated. I think i need some more time the check all the comments for the touched tests. Thanks for your reviews. >> >> All the comments in touched tests has been checked. > >> @sendaoYan Can you please update the summary of this PR and Bug and reflect the whole scope of changes. > > I have updated to title of this PR and JBS as "Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests". If you have better concise summary, please let me known. @sendaoYan Thank you! Waiting for integration! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3750225072 From sspitsyn at openjdk.org Wed Jan 14 20:41:14 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 20:41:14 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v8] In-Reply-To: References: <-6DlwMpBWSgyfikkAZlvYc7SaqlLnxFXKaBGMliK550=.6f0ab7d4-0a88-43b7-846a-2a036072a3bf@github.com> Message-ID: On Wed, 14 Jan 2026 01:27:45 GMT, David Holmes wrote: > Could you provide a brief summary in the test about its structure and exactly what scenario it is creating to be tested - thanks. Good suggestion. Will do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3751624921 From swesonga at openjdk.org Wed Jan 14 20:43:52 2026 From: swesonga at openjdk.org (Saint Wesonga) Date: Wed, 14 Jan 2026 20:43:52 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 05:50:50 GMT, David Holmes wrote: > Sorry Julian but this simply does not seem significant enough to warrant detailed review cycles from me. I don't know if this changes your opinion here but the `-XX:OnSpinWaitInst` and `-XX:OnSpinWaitInstCount` flags are not respected on Windows AArch64 without the AArch64 change in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3751629637 From sspitsyn at openjdk.org Wed Jan 14 21:32:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 21:32:43 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v9] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: add general comment with testing scenario description for ThreadStateTest2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/052a04cd..d0f129f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=07-08 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Thu Jan 15 01:23:29 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:23:29 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v10] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: problem list new test ThreadStateTest2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/d0f129f7..3a82932c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=08-09 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Thu Jan 15 01:27:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:27:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v10] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 01:23:29 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: problem list new test ThreadStateTest2 I've problem-listed new test `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2` as it has been discovered new bug: https://bugs.openjdk.org/browse/JDK-8375362 . [PING!] This PR is ready for re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3752435240 PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3752436077 From sspitsyn at openjdk.org Thu Jan 15 01:34:28 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 01:34:28 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: References: Message-ID: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix trailing space in new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/3a82932c..00971481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From syan at openjdk.org Thu Jan 15 02:47:18 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:47:18 GMT Subject: RFR: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests [v11] In-Reply-To: References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update commnets for ClassUnloader > > Something strange is going on with this PR. I just got 3 separate emails for each of the following commits that were done in the past day: > > - [Fix the copy-n-paste error](https://github.com/openjdk/jdk/pull/28891/changes/349ae833fb600ab9136ab4f43749d1e5f2c84ca0) > - [Update commnets for ClassUnloader](https://github.com/openjdk/jdk/pull/28891/changes/6c144309a091038aaed1d698bd12323f3672c7b9) > - [Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java](https://github.com/openjdk/jdk/pull/28891/changes/e8d128e666ee0a8cbbf6d9dc273636b62bd3fb96) > > However, the PR claims that these commits were all done on Nov 22, not Dec. Thanks for the suggestions and reviews @plummercj @lmesnik. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3752622327 From syan at openjdk.org Thu Jan 15 02:50:03 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 02:50:03 GMT Subject: Integrated: 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests In-Reply-To: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com> Message-ID: On Thu, 18 Dec 2025 08:26:44 GMT, SendaoYan wrote: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `eatMemory` to grigger full GC. The OOME trigger by `eatMemory` may cause vmTestbase/nsk/monitoring/stress/classload tests intermittent fails when run those tests simultancely on some machines. The WB.fullGC() might be use for same purpose. It also reduce test execution time. > > Change has been verified locally by running tests vmTestbase/nsk/monitoring/stress/classload on linux-x64. > > Additional testing: > > - [x] All jtreg tests by fastdebug build This pull request has now been integrated. Changeset: ce5e0d8a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/ce5e0d8a48296b51c9c2eff4867e2a9a70194091 Stats: 421 lines in 62 files changed: 206 ins; 97 del; 118 mod 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/28891 From dholmes at openjdk.org Thu Jan 15 05:48:10 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 05:48:10 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:40:30 GMT, Saint Wesonga wrote: > I don't know if this changes your opinion here but the `-XX:OnSpinWaitInst` and `-XX:OnSpinWaitInstCount` flags are not respected on Windows AArch64 without the AArch64 change in this PR. AFAICS they are still respected, just not used in relation to `SpinPause`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3752996665 From dholmes at openjdk.org Thu Jan 15 05:54:49 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 05:54:49 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing space in new test test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java line 48: > 46: * - VT-2: a virtual thread: in a loop calls JVMTI InterruptThread(VT-0) and GetThreadState(VT-1) > 47: * - main: a platform thread: in a loop invokes native method testSuspendResume which suspends and resumes VT-2 > 48: * The JVMTI functionis above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). Suggestion: * The JVMTI functions above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2693081790 From aboldtch at openjdk.org Thu Jan 15 06:00:53 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:00:53 GMT Subject: RFR: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file [v5] In-Reply-To: References: Message-ID: <22GhNF5xBtuiYTm5h2cG9TwQtdOu9yQBL5VdvS1_nSQ=.cb04882a-beb4-4cd5-8264-7d87e20249ae@github.com> On Mon, 12 Jan 2026 13:28:32 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 eight additional commits since the last revision: > > - Change type of pos to size_t > - Use static_cast > - Update copyright year > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8371762 > - 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 Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28283#issuecomment-3753019956 From aboldtch at openjdk.org Thu Jan 15 06:00:54 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 15 Jan 2026 06:00:54 GMT Subject: Integrated: 8371762: Incorrect use of checked_cast in Arguments::process_settings_file In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 07:14:29 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). > > * Testing > * GHA > * Running tier 1-3 on Oracl... This pull request has now been integrated. Changeset: b6b33792 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/b6b337926d5f13ee2bca12ea94530ea59911ff2f Stats: 15 lines in 1 file changed: 6 ins; 1 del; 8 mod 8371762: Incorrect use of checked_cast in Arguments::process_settings_file Reviewed-by: dholmes, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/28283 From dholmes at openjdk.org Thu Jan 15 06:04:09 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 06:04:09 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 01:34:28 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix trailing space in new test I can't say that I understand what is happening in [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) but I do wonder if we need to get all the current VT issues resolved (in Loom repo?) before trying to update mainline. Maybe they are distinct issues but maybe there is some overlap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3753029067 From swesonga at openjdk.org Thu Jan 15 07:27:27 2026 From: swesonga at openjdk.org (Saint Wesonga) Date: Thu, 15 Jan 2026 07:27:27 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 05:45:40 GMT, David Holmes wrote: > > I don't know if this changes your opinion here but the `-XX:OnSpinWaitInst` and `-XX:OnSpinWaitInstCount` flags are not respected on Windows AArch64 without the AArch64 change in this PR. > > AFAICS they are still respected, just not used in relation to `SpinPause`. An example of a scenario of where these flags should have an effect but don't on Windows AArch64 is when [ObjectMonitor::try_spin](https://github.com/openjdk/jdk/blob/b6b337926d5f13ee2bca12ea94530ea59911ff2f/src/hotspot/share/runtime/objectMonitor.cpp#L2448) calls SpinPause. The StubRoutines::aarch64::spin_wait() stub will have the correct number of the specified instruction but won't be invoked at all without this change (unless I'm missing something). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3753222079 From fbredberg at openjdk.org Thu Jan 15 09:29:59 2026 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 15 Jan 2026 09:29:59 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:10:19 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. >> >> An example of Java code where we end up with nested annotations is this: >> >> >> import java.lang.annotation.*; >> >> @Retention(RetentionPolicy.RUNTIME) >> public @interface Foo { Bar value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Bar { Baz value();} >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Baz { BarBaz value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface BarBaz { End value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface End { int value(); } >> >> >> @Foo(value = @Bar(value = @Baz(value = @BarBaz(value = @End(value=1))))) >> class Lol { >> >> @Deprecated // <--- This annotation might be missed with my change, as the depth limit is 5 >> void foobar(); >> }; >> >> >> Today, it seems that Java disallows cyclic interface annotations, this is why in order to achieve the nesting in `Lol` we need to define multiple classes (`Foo`, `Bar`, and so on). Attempting to define a `Foo` with a `Foo value()` will fail compilation. >> >> I think that such a high nesting of annotations is unlikely to occur in normal Java code. The only 'public' consumer of annotations is JFR, who looks for `@Deprecated` annotations. Typically, the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. To quote John Rose in the JBS issue: >> >>> If a JVM-detected annotation is preceded by a toxic input, it will be masked by a bailout. So be it. JVM-detected annotations are for power users; such users can take measures that their code will not be polluted with toxic annotations. >> >> All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. >> >> A regression test has been added, where we check that the JVM does not crash when provided with a large amount of nesting. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix character Looks good to me, as long as you fix the copyright years in both files. :) ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28674#pullrequestreview-3664673977 From sspitsyn at openjdk.org Thu Jan 15 09:58:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 09:58:41 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: fix typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/00971481..31c09156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From sspitsyn at openjdk.org Thu Jan 15 09:58:43 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Jan 2026 09:58:43 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v11] In-Reply-To: References: <1b-rOp80VK6D21syHa1ROJFXyTBbO7YicH79oQkPGM4=.295595e4-33c4-4653-86a9-dddb4f7ea3ab@github.com> Message-ID: On Thu, 15 Jan 2026 06:01:39 GMT, David Holmes wrote: > I can't say that I understand what is happening in [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) but I do wonder if we need to get all the current VT issues resolved (in Loom repo?) before trying to update mainline. Maybe they are distinct issues but maybe there is some overlap We've never had sufficient test coverage for `InterruptThread` in combination with `SuspendThread`. New test introduced in this PR found this new problem which I understand. It is better/simpler to address separately. It might require more investigation and testing even though I have a potential fix in mind. > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java line 48: > >> 46: * - VT-2: a virtual thread: in a loop calls JVMTI InterruptThread(VT-0) and GetThreadState(VT-1) >> 47: * - main: a platform thread: in a loop invokes native method testSuspendResume which suspends and resumes VT-2 >> 48: * The JVMTI functionis above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). > > Suggestion: > > * The JVMTI functions above install a MountUnmountDisabler for target virtual thread (VT-0 or VT-1). Good catch, thanks! Fixed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3753828862 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2693702756 From dholmes at openjdk.org Thu Jan 15 11:45:26 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 11:45:26 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:10:19 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. >> >> An example of Java code where we end up with nested annotations is this: >> >> >> import java.lang.annotation.*; >> >> @Retention(RetentionPolicy.RUNTIME) >> public @interface Foo { Bar value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Bar { Baz value();} >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Baz { BarBaz value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface BarBaz { End value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface End { int value(); } >> >> >> @Foo(value = @Bar(value = @Baz(value = @BarBaz(value = @End(value=1))))) >> class Lol { >> >> @Deprecated // <--- This annotation might be missed with my change, as the depth limit is 5 >> void foobar(); >> }; >> >> >> Today, it seems that Java disallows cyclic interface annotations, this is why in order to achieve the nesting in `Lol` we need to define multiple classes (`Foo`, `Bar`, and so on). Attempting to define a `Foo` with a `Foo value()` will fail compilation. >> >> I think that such a high nesting of annotations is unlikely to occur in normal Java code. The only 'public' consumer of annotations is JFR, who looks for `@Deprecated` annotations. Typically, the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. To quote John Rose in the JBS issue: >> >>> If a JVM-detected annotation is preceded by a toxic input, it will be masked by a bailout. So be it. JVM-detected annotations are for power users; such users can take measures that their code will not be polluted with toxic annotations. >> >> All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. >> >> A regression test has been added, where we check that the JVM does not crash when provided with a large amount of nesting. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix character This is inline with what was proposed in JBS so seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28674#pullrequestreview-3665207346 From jsjolen at openjdk.org Thu Jan 15 12:41:25 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 15 Jan 2026 12:41:25 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v3] In-Reply-To: References: Message-ID: > Hi, > > `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. > > An example of Java code where we end up with nested annotations is this: > > > import java.lang.annotation.*; > > @Retention(RetentionPolicy.RUNTIME) > public @interface Foo { Bar value(); } > > @Retention(RetentionPolicy.RUNTIME) > @interface Bar { Baz value();} > > @Retention(RetentionPolicy.RUNTIME) > @interface Baz { BarBaz value(); } > > @Retention(RetentionPolicy.RUNTIME) > @interface BarBaz { End value(); } > > @Retention(RetentionPolicy.RUNTIME) > @interface End { int value(); } > > > @Foo(value = @Bar(value = @Baz(value = @BarBaz(value = @End(value=1))))) > class Lol { > > @Deprecated // <--- This annotation might be missed with my change, as the depth limit is 5 > void foobar(); > }; > > > Today, it seems that Java disallows cyclic interface annotations, this is why in order to achieve the nesting in `Lol` we need to define multiple classes (`Foo`, `Bar`, and so on). Attempting to define a `Foo` with a `Foo value()` will fail compilation. > > I think that such a high nesting of annotations is unlikely to occur in normal Java code. The only 'public' consumer of annotations is JFR, who looks for `@Deprecated` annotations. Typically, the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. To quote John Rose in the JBS issue: > >> If a JVM-detected annotation is preceded by a toxic input, it will be masked by a bailout. So be it. JVM-detected annotations are for power users; such users can take measures that their code will not be polluted with toxic annotations. > > All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. > > A regression test has been added, where we check that the JVM does not crash when provided with a large amount of nesting. > > Thanks! Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28674/files - new: https://git.openjdk.org/jdk/pull/28674/files/5cceb010..a705bc1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28674&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28674&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28674/head:pull/28674 PR: https://git.openjdk.org/jdk/pull/28674 From jsjolen at openjdk.org Thu Jan 15 12:41:27 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 15 Jan 2026 12:41:27 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:26:34 GMT, Fredrik Bredberg wrote: > Looks good to me, as long as you fix the copyright years in both files. :) Thank you @fbredber! Fixed the copyright to 2026. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28674#issuecomment-3754512441 From syan at openjdk.org Thu Jan 15 12:44:48 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 12:44:48 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan wrote: >> Hi all, >> >> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. >> >> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. >> >> Thanks! > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add an whitespace after if > > Co-authored-by: Andrey Turbanov Test-fix only, should we backport this fix to jdk26? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3754555700 From jsjolen at openjdk.org Thu Jan 15 16:27:52 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 15 Jan 2026 16:27:52 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> References: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> Message-ID: On Wed, 14 Jan 2026 15:37:15 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder 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: > > - Fixes > - Remove trailing whitespace > - [Linux] Avoid fstat in os::open Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29152#pullrequestreview-3666503486 From duke at openjdk.org Thu Jan 15 18:23:16 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 18:23:16 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> References: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> Message-ID: <__4ces32M4F6S6gYW3OXQNUM4j4f2QKDR-jtBX_UG9U=.3f4b609b-c29a-4eb5-a780-fb23b4cbfa35@github.com> On Wed, 14 Jan 2026 15:37:15 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fixes > - Remove trailing whitespace > - [Linux] Avoid fstat in os::open @JonasNorlinder Your change (at version dfc44a6bde0a9aeadb5a60639849d1721b18fc97) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3756257892 From dholmes at openjdk.org Thu Jan 15 23:35:49 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 23:35:49 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 I thought I saw direct calls to `spin_wait` elsewhere in the code. ./cpu/aarch64/aarch64.ad ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3757372293 From dholmes at openjdk.org Thu Jan 15 23:42:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Jan 2026 23:42:56 GMT Subject: RFR: 8364655: Loading class with nested annotations causes stack overflow in VM [v3] In-Reply-To: References: Message-ID: <3dQick4qOHtSRVjlCWI55ZTWNSYmlz-ID_gIHQ2hzBk=.a8898edc-d9c8-412a-a8d5-e3bfd8036f05@github.com> On Thu, 15 Jan 2026 12:41:25 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_annotation` and `skip_annotation_value` are two mutually recursive functions calling each other in order to skip over classfile annotations. If a classfile contains a highly nested annotation, then this will lead to a stack overflow and a subsequent crash of the JVM. I propose that we insert a recursion limit to prevent this from happening. This recursion limit will make the annotation parsing to bail out on the JVM side, skipping the rest of the annotations present. >> >> An example of Java code where we end up with nested annotations is this: >> >> >> import java.lang.annotation.*; >> >> @Retention(RetentionPolicy.RUNTIME) >> public @interface Foo { Bar value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Bar { Baz value();} >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface Baz { BarBaz value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface BarBaz { End value(); } >> >> @Retention(RetentionPolicy.RUNTIME) >> @interface End { int value(); } >> >> >> @Foo(value = @Bar(value = @Baz(value = @BarBaz(value = @End(value=1))))) >> class Lol { >> >> @Deprecated // <--- This annotation might be missed with my change, as the depth limit is 5 >> void foobar(); >> }; >> >> >> Today, it seems that Java disallows cyclic interface annotations, this is why in order to achieve the nesting in `Lol` we need to define multiple classes (`Foo`, `Bar`, and so on). Attempting to define a `Foo` with a `Foo value()` will fail compilation. >> >> I think that such a high nesting of annotations is unlikely to occur in normal Java code. The only 'public' consumer of annotations is JFR, who looks for `@Deprecated` annotations. Typically, the JVM parses these annotations is to gain access to a select few JDK-internal annotations, and we trust our own code to construct classfiles without egregious nesting. To quote John Rose in the JBS issue: >> >>> If a JVM-detected annotation is preceded by a toxic input, it will be masked by a bailout. So be it. JVM-detected annotations are for power users; such users can take measures that their code will not be polluted with toxic annotations. >> >> All classfile annotations are also parsed by Java-code, so we're not skipping general annotation parsing. >> >> A regression test has been added, where we check that the JVM does not crash when provided with a large amount of nesting. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28674#pullrequestreview-3668112060 From swesonga at openjdk.org Thu Jan 15 23:42:57 2026 From: swesonga at openjdk.org (Saint Wesonga) Date: Thu, 15 Jan 2026 23:42:57 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: <6NLBQq0K_bRPBP6UIsx8X9BPCEG7PYv3DqeyZnDP-hQ=.10306a35-eb8d-4e27-ad3e-d6ffd76ab616@github.com> On Thu, 15 Jan 2026 23:31:51 GMT, David Holmes wrote: > I thought I saw direct calls to `spin_wait` elsewhere in the code. ./cpu/aarch64/aarch64.ad Yes, those happen e.g. with C2 and they can be influenced with those command line flags. However, it would be good to also respect them in other locations e.g. to use a speculation barrier instruction in [ObjectMonitor::try_spin](https://github.com/openjdk/jdk/blob/b6b337926d5f13ee2bca12ea94530ea59911ff2f/src/hotspot/share/runtime/objectMonitor.cpp#L2448) as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3757388057 From pchilanomate at openjdk.org Fri Jan 16 00:46:52 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 00:46:52 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:58:41 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: fix typo in comment Thanks for adding the reproducer test Serguei. Looking at the newly filed [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) I see the problem is the same one described in this PR, it's just that the suspend checkpoint is not in the handshake processing logic but in `MountUnmountDisabler::start_transition`. So maybe it would make sense to fix them both here? BTW, looking at `JvmtiEnv::InterruptThread`, do we really need the disabler? `Thread.interrupt()` could be called directly from Java and we don't disable transitions on the target. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3757546393 From dholmes at openjdk.org Fri Jan 16 02:25:52 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 02:25:52 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> References: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> Message-ID: <8Ei8Q9VDtkU9XMhj18iRJYSg5kxnE-6xlvLl66zWNqc=.ee9d7a6e-bc7d-4a31-b8f6-4208505a5bb1@github.com> On Wed, 14 Jan 2026 15:37:15 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder 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: > > - Fixes > - Remove trailing whitespace > - [Linux] Avoid fstat in os::open Sorry I was going to sponsor but spotted a typo. src/hotspot/os/linux/os_linux.cpp line 4886: > 4884: int fd = ::open(path, oflag, mode); > 4885: // No further checking is needed if open() returned an error or > 4886: // access mode is not read only Suggestion: // access mode is not read only. src/hotspot/os/linux/os_linux.cpp line 4892: > 4890: > 4891: // If the open succeeded and is read only, the file might be a directory > 4892: // which the JVM don't allow to be read Suggestion: // which the JVM doesn't allow to be read. ------------- PR Review: https://git.openjdk.org/jdk/pull/29152#pullrequestreview-3668462012 PR Review Comment: https://git.openjdk.org/jdk/pull/29152#discussion_r2696624666 PR Review Comment: https://git.openjdk.org/jdk/pull/29152#discussion_r2696625067 From sspitsyn at openjdk.org Fri Jan 16 05:40:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 05:40:45 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12] In-Reply-To: References: Message-ID: <3YW6u4XSgIA2yRcX-KNfYO750GaESL7hD1xboNadOyU=.3d1bc81b-5d43-4671-984d-8543a9c1c26c@github.com> On Fri, 16 Jan 2026 00:44:39 GMT, Patricio Chilano Mateo wrote: > Looking at the newly filed [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) I see the problem is the same one described in this PR, it's just that the suspend checkpoint is not in the handshake processing logic but in MountUnmountDisabler::start_transition. So maybe it would make sense to fix them both here? Good suggestion, thanks! I was thinking about the same. Okay will push an update for [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) here. > BTW, looking at JvmtiEnv::InterruptThread, do we really need the disabler? Thread.interrupt() could be called directly from Java and we don't disable transitions on the target. Thank you for the suggestion! I've tried it and got many failures of the tests depending on JVMTI `InterruptThread`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3758262690 From sspitsyn at openjdk.org Fri Jan 16 08:00:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 08:00:01 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/31c09156..05b4c996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=11-12 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From jnorlinder at openjdk.org Fri Jan 16 08:08:21 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Fri, 16 Jan 2026 08:08:21 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v3] In-Reply-To: References: Message-ID: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29152/files - new: https://git.openjdk.org/jdk/pull/29152/files/dfc44a6b..ffd76aaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29152&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29152&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29152/head:pull/29152 PR: https://git.openjdk.org/jdk/pull/29152 From jnorlinder at openjdk.org Fri Jan 16 08:08:24 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Fri, 16 Jan 2026 08:08:24 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v2] In-Reply-To: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> References: <6P--7tNUpirMwgpfx3VjfIhawAh_lnWkkoxCul2QLs0=.a552832e-6293-4705-bd05-652062f78b6a@github.com> Message-ID: On Wed, 14 Jan 2026 15:37:15 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder 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: > > - Fixes > - Remove trailing whitespace > - [Linux] Avoid fstat in os::open Thanks for spotting that, David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3758658131 From azafari at openjdk.org Fri Jan 16 10:56:36 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 16 Jan 2026 10:56:36 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 09:02:19 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build Dear @tstuefe, After your last comments on the previous version of this change, I have re-implemented the poisoning in a way aligned to your concerns. Please have a look and let me know if something is missed or can be improved. TIA ------------- PR Comment: https://git.openjdk.org/jdk/pull/28503#issuecomment-3759446359 From stuefe at openjdk.org Fri Jan 16 14:11:52 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 Jan 2026 14:11:52 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 10:53:37 GMT, Afshin Zafari wrote: > Dear @tstuefe, After your last comments on the previous version of this change, I have re-implemented the poisoning in a way aligned to your concerns. Please have a look and let me know if something is missed or can be improved. TIA Hi @afshin-zafari , I currently do not have the bandwidth to review this in depth. At first glance, omitting the integrity checks for ASAN is better, thanks for that. I don't want to hold this PR up. If @jdksjolen is fine with this change, that is good to me too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28503#issuecomment-3760192312 From stuefe at openjdk.org Fri Jan 16 14:11:56 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 Jan 2026 14:11:56 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 09:02:19 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build src/hotspot/share/nmt/mallocHeader.hpp line 36: > 34: > 35: #if INCLUDE_ASAN > 36: #undef NMT_BLOCK_INTEGRITY_CHECKS Can you add a comment like this: // With ASAN, we omit NMT block integrity checks since ASAN does a better and faster // job of alerting us to memory corruptions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2698638579 From dcubed at openjdk.org Fri Jan 16 22:09:52 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:09:52 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 Sorry for the long delay in getting back to this review. There a comment in ObjectMonitor::wait() that I think might be incorrect. See L1965 -> L1969 in src/hotspot/share/runtime/objectMonitor.cpp. I really like the refactoring that you've done with the test! Thumbs up on the code and most of the comments. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3672883715 From dcubed at openjdk.org Fri Jan 16 22:09:54 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:09:54 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v9] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 00:39:14 GMT, Serguei Spitsyn wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewer's comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1950: > >> 1948: // as having "-locked" the monitor, but the OS and java.lang.Thread >> 1949: // states will still report that the thread is blocked trying to >> 1950: // acquire it. > > Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). @dcubed-ojdk, could you comment on this, please? Sorry for the long delay in getting back to this review. Hmmmm... I'm wondering if that comment is correct: - We've creat `ExitOnSuspend eos` on L1961. - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`. - We reenter the monitor on L1964. - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below: - We call the `eos` object on the current thread BEFORE we `call process_if_requested` So it looks to me like we exit the monitor before we block for the safepoint so we should not be showing the monitor as "locked" by our "blocked" thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2700092565 From dcubed at openjdk.org Fri Jan 16 22:21:11 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:21:11 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v6] In-Reply-To: References: Message-ID: <5Y1HQt7NZK25GgtxctjN90D0HGEXi3LDyuoWcCmQz3E=.55e817a1-2427-464d-81f7-5c456abe422f@github.com> On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed lines in tests. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Added a comment to a boolean arg for enter() >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed new lines. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed incorrect assert, >> - 8366659: Fixed merge conflict >> - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6 > > So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java. > > I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended > thread made the successor over and over again so that none of the other contending threads > ever get the monitor even though it is unlocked. > > I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread > manages to re-enter the monitor and then gets suspended while on its way back to Java. > > @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two > new test cases to the two deadlocks. Thanks! > is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario? @dcubed-ojdk, what do you think? Sorry for the long delay in getting back to this thread. Yes, the original SuspendWithObjectMonitorWait demonstrated a real-world scenario and it reproduced a bug in the JVM where a suspended thread was allowed to enter a monitor. That violated the SuspendThread contract that after return from the call, the target thread will execute no more bytecode or byte-code equivalents. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762019821 From dcubed at openjdk.org Fri Jan 16 22:25:47 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:25:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 See the original issue from JDK1.3.1 here: [JDK-4413752](https://bugs.openjdk.org/browse/JDK-4413752) Linux: suspended thread blocks raw ObjectMonitor entry ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762029149 From dcubed at openjdk.org Fri Jan 16 22:28:53 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:28:53 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v17] In-Reply-To: References: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com> Message-ID: <_IIvFo-i2TXxNeeJ0gzRl_xEleoHrzzApvsmEBH8P8s=.aaafc329-87d3-4cdc-93c9-40f4919a69f6@github.com> On Mon, 24 Nov 2025 10:22:12 GMT, Serguei Spitsyn wrote: > The thread was picked as a successor and then suspended. It feels like it has to be qualified same as a thread owns the monitor and suspended. The successor protocol is an internal implementation detail of ObjectMonitor. It is NOT exposed to person debugging their Java program. Just because a suspend thread is marked as the successor, that does NOT mean it should prevent other non-suspended threads from entering the monitor. In other words, being the successor IS NOT the same as owning the monitor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762044144 From dcubed at openjdk.org Fri Jan 16 22:34:59 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Jan 2026 22:34:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 I have to disagree that the notion that test case #2 and test case #3 are "artificial". These tests were written to line up the executing conditions to reproduce the two failure modes posited by the bug. Both of the new test cases, when executed on a VM without the product code changes cause a definite liveness condition. Maybe we should have said "hang" instead of "deadlock". Maybe even "livelock" is better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3762066851 From sspitsyn at openjdk.org Fri Jan 16 22:41:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Jan 2026 22:41:01 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: <6HSpZhqgIttyqFw-sz7eielDrrzdBHDGWj7Pm-TE_ko=.9dec4a59-08b6-4e46-86a7-2681c6719004@github.com> On Fri, 16 Jan 2026 08:00:01 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread I've added the following fix for [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) as we agreed with Patricio: @@ -129,7 +129,8 @@ bool MountUnmountDisabler::is_start_transition_disabled(JavaThread* thread, oop int base_disable_count = notify_jvmti_events() ? 1 : 0; return java_lang_Thread::vthread_transition_disable_count(vthread) > 0 || global_vthread_transition_disable_count() > base_disable_count JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended())); JVMTI_ONLY(|| (!thread->is_vthread_transition_disabler() && (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()))); } void MountUnmountDisabler::start_transition(JavaThread* current, oop vthread, bool is_mount, bool is_thread_end) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3762080269 From syan at openjdk.org Sat Jan 17 04:10:54 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 17 Jan 2026 04:10:54 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 Message-ID: Hi all, This PR make 2 changes which make test more rubustness: 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. Additional testing: - [ ] All tests touched test by JDK-8373945 ------------- Commit messages: - 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after JDK-8373945 Changes: https://git.openjdk.org/jdk/pull/29285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375485 Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From cjplummer at openjdk.org Sat Jan 17 18:19:25 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 17 Jan 2026 18:19:25 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: > 260: if (isClassLoaderReclaimed()) { > 261: System.out.println("ClassUnloader: class loader has been reclaimed."); > 262: Runtime.getRuntime().gc(); It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2701332698 From jkratochvil at openjdk.org Sat Jan 17 20:39:11 2026 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sat, 17 Jan 2026 20:39:11 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 01:33:37 GMT, Chad Rakoczy wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Added ded... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Fix builds I see a FAIL for `test/jdk/jdk/jfr/event/compiler/TestCodeCacheFull.java` on linux64 fastdebug: Error occurred during initialization of VM HotCodeHeapSize requires HotCodeHeap enabled But GHA does not report it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3764312804 From lmesnik at openjdk.org Sun Jan 18 20:17:30 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 18 Jan 2026 20:17:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java line 109: > 107: > 108: while (thrd.isAlive()) { > 109: logger.display("Thread state: " + thrd.getState() Please add some sleep to don't produce huge amount of output. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 254: > 252: WhiteBox.getWhiteBox().fullGC(); > 253: int count = 0; > 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { Thanks for the fix. I find the same. The old unloading method triggered several GCs and took a lot of time. So might be this allowed all classes/method to freed and corresponding events to be generate. The method unloading event might be generated after full GC is completed. It is called on ServiceThread with some latency. And haven't time to check another events. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 256: > 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { > 255: System.out.println("ClassUnloader: waiting for class loader reclaiming... " + count); > 256: WhiteBox.getWhiteBox().fullGC(); Can you add some small delay (100ms) between attempts. To give more chances to process ojbects inside VM like jvmti deferred queue. ------------- PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3675260387 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702146837 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702691837 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2702693051 From dholmes at openjdk.org Mon Jan 19 01:57:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 01:57:36 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:05:37 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 44 commits: > > - 8366659: Fixed year in the copyright. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Removed ClearSuccOnSuspend > - 8366659: Fixed liveness problem. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed build problem. > - 8366659: Fixed build issue. > - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Fixed semi-broken tests > - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 I'm struggling to map code changes to the description of the changes. I think a lot more comments are needed to describe things more clearly. The three testcases need a clearer description - and '1' '2' '3' are not great names. Given we are in the SuspendWithObjectMonitorWait directory we do not need that prefix on all the file names - we can use shorter but more descriptive names for what is actually being tested. Thanks src/hotspot/share/runtime/objectMonitor.cpp line 1907: > 1905: // That is, we fail toward safety. > 1906: > 1907: was_notified = true; This isn't quite right. If we would reach line 1882 then we were not notified, so we cannot unconditionally set this to true here. I think you need to initialize to true at line 1868 and then set to false at line 1882 (deleting the current comment). src/hotspot/share/runtime/objectMonitor.cpp line 1917: > 1915: } > 1916: > 1917: // The thread is now either on off-list (TS_RUN), Suggestion: // The thread is now either off-list (TS_RUN), src/hotspot/share/runtime/objectMonitor.cpp line 1932: > 1930: // (Don't cache naked oops over safepoints, of course). > 1931: > 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. Suggestion: // Post monitor waited event. Note that this is past-tense, we are done waiting. You need to expand the comment to explain the significance of checking for TS_ENTER. src/hotspot/share/runtime/objectMonitor.cpp line 1967: > 1965: // We can go to a safepoint at the end of this block. If we > 1966: // do a thread dump during that safepoint, then this thread will show > 1967: // as having "-locked" the monitor, but the OS and java.lang.Thread To be clear, if it is a plain-old safepoint, we will show the monitor as locked because it is. But if it happens we were suspended, then we will release the monitor and so we wouldn't report locked. src/hotspot/share/runtime/objectMonitor.cpp line 1973: > 1971: // and set the OM as pending. > 1972: } > 1973: // Done waiting, post the corresponding event What event? I expected to see `JvmtiExport::post_monitor_waited` here. ?? src/hotspot/share/runtime/objectMonitor.cpp line 2053: > 2051: // Adding to _entry_list uses Atomic::cmpxchg() which already provides > 2052: // a fence that prevents reordering of the stores. > 2053: if (!JvmtiExport::should_post_monitor_waited()) { You need to explain why this is now conditional. src/hotspot/share/runtime/objectMonitor.cpp line 2063: > 2061: if (!JvmtiExport::should_post_monitor_waited()) { > 2062: add_to_entry_list(current, iterator); > 2063: } else { You need to explain what each of these paths is doing. At this point I'm lost. src/hotspot/share/runtime/objectMonitor.cpp line 2069: > 2067: > 2068: oop vthread = nullptr; > 2069: ParkEvent* Trigger; I assume this is copied from elsewhere but we should use proper style rules in the new code i.e. local variables don't start with a capital. Thanks. Also "trigger" doesn't really convet anythng meaningful to me - `evt` for event seems fine. src/hotspot/share/runtime/objectMonitor.cpp line 2277: > 2275: node->_at_reenter = true; > 2276: > 2277: if (state == ObjectWaiter::TS_RUN) { I'm finding the changes to `was_notified` versus use of explicit state checks very confusing. I keep asking myself which state means I was notified and which does not. test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 71: > 69: public int doWork1(int timeMax, PrintStream out) { > 70: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread > 71: SuspendWithObjectMonitorWaitWorker resumer; // resumer thread Suggestion: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread SuspendWithObjectMonitorWaitWorker resumer; // resumer thread ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3675924710 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702902497 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702905495 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702909290 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702947656 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702958092 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702960742 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702965432 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702967605 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702974131 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2702975301 From dholmes at openjdk.org Mon Jan 19 04:54:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 04:54:29 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 04:34:36 GMT, David Holmes wrote: > Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. > > The changes are the same for each platform. > > Testing > - building all platforms via GHA > - tiers 1-3 (sanity) > > Thanks Manually adding runtime as this was filed as an interpreter issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29293#issuecomment-3766388787 From fyang at openjdk.org Mon Jan 19 05:28:05 2026 From: fyang at openjdk.org (Fei Yang) Date: Mon, 19 Jan 2026 05:28:05 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 04:34:36 GMT, David Holmes wrote: > Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. > > The changes are the same for each platform. > > Testing > - building all platforms via GHA > - tiers 1-3 (sanity) > > Thanks Looks reasonable to me. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29293#pullrequestreview-3676303251 From dholmes at openjdk.org Mon Jan 19 05:48:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 05:48:36 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 05:24:41 GMT, Fei Yang wrote: >> Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. >> >> The changes are the same for each platform. >> >> Testing >> - building all platforms via GHA >> - tiers 1-3 (sanity) >> >> Thanks > > Looks reasonable to me. Thanks for the review @RealFYang ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29293#issuecomment-3766507632 From syan at openjdk.org Mon Jan 19 06:57:13 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 06:57:13 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [ ] All tests touched test by JDK-8373945 SendaoYan has updated the pull request incrementally with one additional commit since the last revision: 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29285/files - new: https://git.openjdk.org/jdk/pull/29285/files/7b6daf35..4f3d03a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=00-01 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From syan at openjdk.org Mon Jan 19 07:05:30 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 07:05:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Sun, 18 Jan 2026 05:59:58 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java line 109: > >> 107: >> 108: while (thrd.isAlive()) { >> 109: logger.display("Thread state: " + thrd.getState() > > Please add some sleep to don't produce huge amount of output. Fixed. > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 256: > >> 254: while (count++ < MAX_UNLOAD_ATTEMPS && !isClassLoaderReclaimed()) { >> 255: System.out.println("ClassUnloader: waiting for class loader reclaiming... " + count); >> 256: WhiteBox.getWhiteBox().fullGC(); > > Can you add some small delay (100ms) between attempts. To give more chances to process ojbects inside VM like jvmti deferred queue. Thanks for the suggestion. Thread.sleep(100) has been added after WB.fullgc(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703461267 PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703463604 From syan at openjdk.org Mon Jan 19 07:14:06 2026 From: syan at openjdk.org (SendaoYan) Date: Mon, 19 Jan 2026 07:14:06 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 18:15:50 GMT, Chris Plummer wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Add small delay after check thrd.isAlive; 2. Add small delay between classloader reclaimed retries. > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: > >> 260: if (isClassLoaderReclaimed()) { >> 261: System.out.println("ClassUnloader: class loader has been reclaimed."); >> 262: Runtime.getRuntime().gc(); > > It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? This gc() seems meaningless but is harmless. Should we remove this gc() call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2703487032 From shade at openjdk.org Mon Jan 19 08:17:14 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 19 Jan 2026 08:17:14 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 04:34:36 GMT, David Holmes wrote: > Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. > > The changes are the same for each platform. > > Testing > - building all platforms via GHA > - tiers 1-3 (sanity) > > Thanks Looks reasonable, and similar to C1/C2 does. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 728: > 726: Label L_skip_barrier; > 727: > 728: { // Bypass the barrier for non-static methods Not entirely sure what extra `{ ... }` block is supposed to do here. Since you are changing these lines, maybe collapse it one indenting level down? ------------- PR Review: https://git.openjdk.org/jdk/pull/29293#pullrequestreview-3676807568 PR Review Comment: https://git.openjdk.org/jdk/pull/29293#discussion_r2703674670 From aartemov at openjdk.org Mon Jan 19 08:41:49 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 08:41:49 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v21] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > 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 45 commits: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed year in the copyright. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Removed ClearSuccOnSuspend - 8366659: Fixed liveness problem. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed build problem. - 8366659: Fixed build issue. - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - ... and 35 more: https://git.openjdk.org/jdk/compare/75172e06...03932cc5 ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=20 Stats: 1331 lines in 9 files changed: 882 ins; 417 del; 32 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 aartemov at openjdk.org Mon Jan 19 09:57:10 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 09:57:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v22] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Modified comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/03932cc5..95cf01f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=20-21 Stats: 14 lines in 1 file changed: 0 ins; 8 del; 6 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 aartemov at openjdk.org Mon Jan 19 09:57:11 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 09:57:11 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v21] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:07:22 GMT, Daniel D. Daugherty wrote: > Sorry for the long delay in getting back to this review. > > There a comment in ObjectMonitor::wait() that I think might be incorrect. See L1965 -> L1969 in src/hotspot/share/runtime/objectMonitor.cpp. > > I really like the refactoring that you've done with the test! > > Thumbs up on the code and most of the comments. I think that part of the comment dates back to 2014 commit, when there was no `ExitOnSuspend` trick, and it seems that the comment is no longer valid. I modified in both places where we use the trick, one in `wait()`, and another one in `enter_with_contention_mark()`, because they are the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3767425019 From duke at openjdk.org Mon Jan 19 10:09:57 2026 From: duke at openjdk.org (George Wort) Date: Mon, 19 Jan 2026 10:09:57 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 01:33:37 GMT, Chad Rakoczy wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. >> >> ### Testing >> * CodeCache tests have been updated to cover the new `HotCodeHeap`. >> * Added ded... > > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Fix builds Hi, I've played around with this PR a bit and had a few thoughts. The way the grouping is set up currently means that if you run the program for long enough you will keep adding profiled code onto the hot code heap, even if it doesn't really meet the definition of hot. This also means that if the program changes "phase", and the hot code changes, the hot code heap might already be full and you will be unable to compact the new hot code. Have you thought about adding some kind of refresh/reset when the hot code heap is full, to purge code that has not appeared in recent profiles? Other small configuration changes that helped me try this out, adding a delay variable to avoid profiling the setup period of a program, and making the sampling period configurable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3759597826 From aartemov at openjdk.org Mon Jan 19 10:10:39 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 10:10:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v23] In-Reply-To: References: Message-ID: <_g0m2zvkitzl9ztwzc45eiDfmGdjjNHP8OARjTMW8XU=.454d98a8-4fb8-4cbb-bc8e-e28654f1eab6@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Modified the comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/95cf01f6..949db95e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=21-22 Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 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 aartemov at openjdk.org Mon Jan 19 10:10:44 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 10:10:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 01:19:44 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - 8366659: Fixed year in the copyright. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed ClearSuccOnSuspend >> - 8366659: Fixed liveness problem. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed build problem. >> - 8366659: Fixed build issue. >> - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed semi-broken tests >> - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 > > src/hotspot/share/runtime/objectMonitor.cpp line 1967: > >> 1965: // We can go to a safepoint at the end of this block. If we >> 1966: // do a thread dump during that safepoint, then this thread will show >> 1967: // as having "-locked" the monitor, but the OS and java.lang.Thread > > To be clear, if it is a plain-old safepoint, we will show the monitor as locked because it is. But if it happens we were suspended, then we will release the monitor and so we wouldn't report locked. I added clarification at the end of the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704080984 From aartemov at openjdk.org Mon Jan 19 11:18:22 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 11:18:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewers' comments, added comments, renamed tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/949db95e..0fd6bc7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=22-23 Stats: 53 lines in 5 files changed: 21 ins; 4 del; 28 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 aartemov at openjdk.org Mon Jan 19 11:18:32 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 19 Jan 2026 11:18:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 00:27:39 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - 8366659: Fixed year in the copyright. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Removed ClearSuccOnSuspend >> - 8366659: Fixed liveness problem. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed build problem. >> - 8366659: Fixed build issue. >> - 8366659: Changed the way how notify_internal works if JVMTI monitor waited event allowed. >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Fixed semi-broken tests >> - ... and 34 more: https://git.openjdk.org/jdk/compare/a01283a5...21b83214 > > src/hotspot/share/runtime/objectMonitor.cpp line 1907: > >> 1905: // That is, we fail toward safety. >> 1906: >> 1907: was_notified = true; > > This isn't quite right. If we would reach line 1882 then we were not notified, so we cannot unconditionally set this to true here. I think you need to initialize to true at line 1868 and then set to false at line 1882 (deleting the current comment). Thanks for spotting this! Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1917: > >> 1915: } >> 1916: >> 1917: // The thread is now either on off-list (TS_RUN), > > Suggestion: > > // The thread is now either off-list (TS_RUN), Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1932: > >> 1930: // (Don't cache naked oops over safepoints, of course). >> 1931: >> 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. > > Suggestion: > > // Post monitor waited event. Note that this is past-tense, we are done waiting. > > You need to expand the comment to explain the significance of checking for TS_ENTER. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 1973: > >> 1971: // and set the OM as pending. >> 1972: } >> 1973: // Done waiting, post the corresponding event > > What event? I expected to see `JvmtiExport::post_monitor_waited` here. ?? I think I overlooked this comment, it is related to one of the previous iterations, where the `JvmtiExport::post_monitor_waited` event was posted further down in the code. Removed. > src/hotspot/share/runtime/objectMonitor.cpp line 2053: > >> 2051: // Adding to _entry_list uses Atomic::cmpxchg() which already provides >> 2052: // a fence that prevents reordering of the stores. >> 2053: if (!JvmtiExport::should_post_monitor_waited()) { > > You need to explain why this is now conditional. Added a comment there. > src/hotspot/share/runtime/objectMonitor.cpp line 2063: > >> 2061: if (!JvmtiExport::should_post_monitor_waited()) { >> 2062: add_to_entry_list(current, iterator); >> 2063: } else { > > You need to explain what each of these paths is doing. At this point I'm lost. Added extended comments for both cases. > src/hotspot/share/runtime/objectMonitor.cpp line 2069: > >> 2067: >> 2068: oop vthread = nullptr; >> 2069: ParkEvent* Trigger; > > I assume this is copied from elsewhere but we should use proper style rules in the new code i.e. local variables don't start with a capital. Thanks. Also "trigger" doesn't really convet anythng meaningful to me - `evt` for event seems fine. Right, it was copied from some other file. Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 2277: > >> 2275: node->_at_reenter = true; >> 2276: >> 2277: if (state == ObjectWaiter::TS_RUN) { > > I'm finding the changes to `was_notified` versus use of explicit state checks very confusing. I keep asking myself which state means I was notified and which does not. Yes, it is all because unparking inside of `notify_internal()`, which is needed to fix the problem, leads to threads which have been actually notified (aka woken up in `notify_internal()'), but are not on the `entry_list`. We may need to do a follow-up PR with some refactoring, maybe binary state is not sufficient. > test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 71: > >> 69: public int doWork1(int timeMax, PrintStream out) { >> 70: SuspendWithObjectMonitorWaitWorker waiter; // waiter thread >> 71: SuspendWithObjectMonitorWaitWorker resumer; // resumer thread > > Suggestion: > > SuspendWithObjectMonitorWaitWorker waiter; // waiter thread > SuspendWithObjectMonitorWaitWorker resumer; // resumer thread Fixed in all test cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704328783 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704329246 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704329583 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330248 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330507 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330740 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704330960 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704331400 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2704331637 From dholmes at openjdk.org Mon Jan 19 11:46:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 11:46:27 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 08:08:16 GMT, Aleksey Shipilev wrote: >> Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. >> >> The changes are the same for each platform. >> >> Testing >> - building all platforms via GHA >> - tiers 1-3 (sanity) >> >> Thanks > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 728: > >> 726: Label L_skip_barrier; >> 727: >> 728: { // Bypass the barrier for non-static methods > > Not entirely sure what extra `{ ... }` block is supposed to do here. Since you are changing these lines, maybe collapse it one indenting level down? I can't see what the block does either - may be a relic from some older code. The same pattern is in most of the files. I can take it out. Thanks for looking at this @shipilev ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29293#discussion_r2704418453 From lmesnik at openjdk.org Mon Jan 19 18:56:18 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 19 Jan 2026 18:56:18 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:10:15 GMT, SendaoYan wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 262: >> >>> 260: if (isClassLoaderReclaimed()) { >>> 261: System.out.println("ClassUnloader: class loader has been reclaimed."); >>> 262: Runtime.getRuntime().gc(); >> >> It's not clear to me why this gc() is even needed after the WhiteBox gc() calls. What does it do that we haven't already accomplished with WhiteBox gc()? > > This gc() seems meaningless but is harmless. Should we remove this gc() call. I think it could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2705807447 From iklam at openjdk.org Mon Jan 19 19:52:42 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Jan 2026 19:52:42 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v3] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - Reverted previous unintended commit - 8375654: Exclude all array classes from dynamic CDS archive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/e9006f5e..6ef4a4da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From dholmes at openjdk.org Mon Jan 19 20:45:57 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jan 2026 20:45:57 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code [v2] In-Reply-To: References: Message-ID: > Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. > > The changes are the same for each platform. > > Testing > - building all platforms via GHA > - tiers 1-3 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Remove redundant block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29293/files - new: https://git.openjdk.org/jdk/pull/29293/files/4d79690f..a721b886 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29293&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29293&range=00-01 Stats: 25 lines in 5 files changed: 0 ins; 5 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29293/head:pull/29293 PR: https://git.openjdk.org/jdk/pull/29293 From eastigeevich at openjdk.org Mon Jan 19 22:22:38 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 19 Jan 2026 22:22:38 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 20:36:34 GMT, Jan Kratochvil wrote: > I see a FAIL for `test/jdk/jdk/jfr/event/compiler/TestCodeCacheFull.java` on linux64 fastdebug: > > ``` > Error occurred during initialization of VM > HotCodeHeapSize requires HotCodeHeap enabled > ``` > > But GHA does not report it. Thank you, @jankratochvil. We will take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3770292456 From eastigeevich at openjdk.org Mon Jan 19 23:11:03 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 19 Jan 2026 23:11:03 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 11:24:08 GMT, George Wort wrote: >> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix builds > > Hi, > > I've played around with this PR a bit and had a few thoughts. > > The way the grouping is set up currently means that if you run the program for long enough you will keep adding profiled code onto the hot code heap, even if it doesn't really meet the definition of hot. This also means that if the program changes "phase", and the hot code changes, the hot code heap might already be full and you will be unable to compact the new hot code. Have you thought about adding some kind of refresh/reset when the hot code heap is full, to purge code that has not appeared in recent profiles? > > Other small configuration changes that helped me try this out, adding a delay variable to avoid profiling the setup period of a program, and making the sampling period configurable. Hi @GeorgeWort Thank you for the feedback. > The way the grouping is set up currently means that if you run the program for long enough you will keep adding profiled code onto the hot code heap, even if it doesn't really meet the definition of hot. This also means that if the program changes "phase", and the hot code changes, the hot code heap might already be full and you will be unable to compact the new hot code. We've seen only cases when an application after running for long enough gets a stable profile which stays almost unchanged forever. We currently rely on GC removing cold nmethods from HotCodeHeap. An application gradually switches between states of being idling and being active. So, possible cases: - Running <-> Idling. If no new nmethods appear, nothing should be removed from HotCodeHeap. If they appear, some other should become cold and be remove by GC. We will detect new nmethods and move them to HotCodeHeap. - Running Profile 1 <-> Running Profile 2. If both profiles cannot be kept in HotCodeHeap, we will have a problem. We will depend on how quickly switching between profiles happens. Anyway switching between profiles might cause performance issues: throwing away nmethods from HotCodeHeap, interpreting them again, recompiling them, relocating them to HotCodeHeap. > Have you thought about adding some kind of refresh/reset when the hot code heap is full, to purge code that has not appeared in recent profiles? We can consider relocating nmethods back to the normal heap, the non-profiled code heap. IMO we should do this instead of GC throwing them away. If after being moved to the normal heap they become cold, GC will remove them from CodeCache. If they become hot again, they will be relocated to HotCodeHeap. > > Other small configuration changes that helped me try this out, adding a delay variable to avoid profiling the setup period of a program, and making the sampling period configurable. Yes, this is useful. We can consider adding it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3770383465 From dholmes at openjdk.org Tue Jan 20 00:14:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 00:14:27 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:14:41 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1932: >> >>> 1930: // (Don't cache naked oops over safepoints, of course). >>> 1931: >>> 1932: // post monitor waited event. Note that this is past-tense, we are done waiting. >> >> Suggestion: >> >> // Post monitor waited event. Note that this is past-tense, we are done waiting. >> >> You need to expand the comment to explain the significance of checking for TS_ENTER. > > Addressed. You didn't expand the comment. IIUC if the state is TS_ENTER then we were notified and moved from TS_WAIT to TS_ENTER before being unparked. But, again IIUC, that will only happen if we don't have to post the event else the notification will unpark us directly and move us to TS_RUN. Which means that checking `!= TS_ENTER` is redundant because if we should post the event then we can't be in state TS_ENTER. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706361996 From dholmes at openjdk.org Tue Jan 20 00:52:12 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 00:52:12 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:18:22 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments, added comments, renamed tests. Thanks for the updates. A few follow ups and queries. src/hotspot/share/runtime/objectMonitor.cpp line 2055: > 2053: // This is is now conditional as if the monitor_waited even > 2054: // is allowed, then a thread, even virtual, should not be moved to > 2055: // the entry_list, but rather unparked and let run. See the comment below. Suggestion: // If we will add the vthread to the entry list below then we need to // increment the counter *before* doing so. // Adding to _entry_list uses Atomic::cmpxchg() which already provides // a fence that prevents reordering of the stores. if (!JvmtiExport::should_post_monitor_waited()) { src/hotspot/share/runtime/objectMonitor.cpp line 2066: > 2064: // If the monitor_waited JVMTI event is not allowed, a thread is > 2065: // transferred to the entry_list, and it will eventually be unparked > 2066: // only when it is chosen to become a successor. Suggestion: // only when it is chosen to become the successor. src/hotspot/share/runtime/objectMonitor.cpp line 2077: > 2075: // avoid a problem of having a suspension point when posting > 2076: // the monitor_waited JVMTI event, as suspending such a thread > 2077: // is no harm. Suggestion: // However, if the monitor_waited event is allowed, then // the thread is set to state TS_RUN and unparked. The thread // will then contend directly to reacquire the monitor and // avoids being flagged as the successor. This avoids the problem // of having a thread suspend whilst it is the successor. src/hotspot/share/runtime/objectMonitor.cpp line 2103: > 2101: evt->unpark(); > 2102: } > 2103: else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { Suggestion: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { src/hotspot/share/runtime/objectMonitor.cpp line 2296: > 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. > 2295: if (state == ObjectWaiter::TS_RUN) { > 2296: bool acquired = vthread_monitor_enter(current, node); If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3679921028 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706376692 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706377771 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706384082 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706385541 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2706403647 From dholmes at openjdk.org Tue Jan 20 01:14:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 01:14:36 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v3] In-Reply-To: References: Message-ID: <0HMpWn9vf9U5b1vFKeTpbkyWJ4dyZqRJvGl-S8ZHhuM=.ebbd8cb8-7566-4cfb-ba87-14a2bf9196b2@github.com> On Fri, 16 Jan 2026 08:08:21 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comments Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29152#pullrequestreview-3679974796 From syan at openjdk.org Tue Jan 20 02:21:38 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 02:21:38 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [x] All tests touched test by JDK-8373945 with relase build > - [ ] All tests touched test by JDK-8373945 with fastdebug build SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary runtime.gc() afer classloader has been reclaimed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29285/files - new: https://git.openjdk.org/jdk/pull/29285/files/4f3d03a8..a561edc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29285&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29285/head:pull/29285 PR: https://git.openjdk.org/jdk/pull/29285 From syan at openjdk.org Tue Jan 20 02:21:38 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 02:21:38 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: <3i1Aks_Y9yU4SjTB_-jBk-R6CgDREh9Ec4Gl-eFniuE=.601d8565-42bd-41b9-93af-ed55d3b1693a@github.com> On Mon, 19 Jan 2026 18:52:28 GMT, Leonid Mesnik wrote: >> This gc() seems meaningless but is harmless. Should we remove this gc() call. > > I think it could be removed. The Runtime.gc() has been removed. And all the touched tests related JDK-8373945 run passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29285#discussion_r2706520709 From shade at openjdk.org Tue Jan 20 05:34:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 20 Jan 2026 05:34:00 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 20:45:57 GMT, David Holmes wrote: >> Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. >> >> The changes are the same for each platform. >> >> Testing >> - building all platforms via GHA >> - tiers 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant block Looks fine to me! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29293#pullrequestreview-3680406748 From lmesnik at openjdk.org Tue Jan 20 06:06:30 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Jan 2026 06:06:30 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> On Tue, 20 Jan 2026 02:21:38 GMT, SendaoYan wrote: >> Hi all, >> >> This PR make 2 changes which make test more rubustness: >> >> 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. >> 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. >> >> Additional testing: >> >> - [x] All tests touched test by JDK-8373945 with relase build >> - [ ] All tests touched test by JDK-8373945 with fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary runtime.gc() afer classloader has been reclaimed Thanks for addressing all the feedback. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3680475503 From dholmes at openjdk.org Tue Jan 20 06:24:55 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 06:24:55 GMT Subject: RFR: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 05:30:24 GMT, Aleksey Shipilev wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant block > > Looks fine to me! Thanks @shipilev ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29293#issuecomment-3771217015 From dholmes at openjdk.org Tue Jan 20 06:24:57 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 06:24:57 GMT Subject: Integrated: 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 04:34:36 GMT, David Holmes wrote: > Please review this simple enhancement to remove runtime checks for `VM_Version::supports_fast_class_init_checks()` in platform specific code, and replace them with asserts - as we know statically whether a given platform supports it. > > The changes are the same for each platform. > > Testing > - building all platforms via GHA > - tiers 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: ca6925ec Author: David Holmes URL: https://git.openjdk.org/jdk/commit/ca6925ec6bf44cf7d4704becc194389e4c87b74f Stats: 113 lines in 10 files changed: 10 ins; 11 del; 92 mod 8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code Reviewed-by: shade, fyang ------------- PR: https://git.openjdk.org/jdk/pull/29293 From syan at openjdk.org Tue Jan 20 06:55:52 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 06:55:52 GMT Subject: RFR: 8375668: Compiler warning implicit-const-int-float-conversion by clang23 Message-ID: Hi all, File src/hotspot/os/linux/cgroupSubsystem_linux.hpp was reported compiler warning `implicit conversion from 'const uint64_t' (aka 'const unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616` by clang23. This compiler waring can be fixed by use explict convert instead the implict convert. This change do not change the orginal logic. ------------- Commit messages: - 8375668: Compiler warning implicit-const-int-float-conversion by clang23 Changes: https://git.openjdk.org/jdk/pull/29309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375668 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29309/head:pull/29309 PR: https://git.openjdk.org/jdk/pull/29309 From dholmes at openjdk.org Tue Jan 20 07:07:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 07:07:27 GMT Subject: RFR: 8375668: Compiler warning implicit-const-int-float-conversion by clang23 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 06:47:54 GMT, SendaoYan wrote: > Hi all, > > File src/hotspot/os/linux/cgroupSubsystem_linux.hpp was reported compiler warning `implicit conversion from 'const uint64_t' (aka 'const unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616` by clang23. This compiler waring can be fixed by use explict convert instead the implict convert. This change do not change the orginal logic. Seems reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29309#pullrequestreview-3680648953 From duke at openjdk.org Tue Jan 20 08:53:48 2026 From: duke at openjdk.org (duke) Date: Tue, 20 Jan 2026 08:53:48 GMT Subject: RFR: 8374945: Avoid fstat in os::open [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:08:21 GMT, Jonas Norlinder wrote: >> Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comments @JonasNorlinder Your change (at version ffd76aaaf8622712ddc3b926ee3e01d7d034d51d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29152#issuecomment-3771723919 From duke at openjdk.org Tue Jan 20 08:57:52 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 08:57:52 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk 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 15 additional commits since the last revision: - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - introduce -T as a commong flag - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - ... and 5 more: https://git.openjdk.org/jdk/compare/d1597314...5f1cefe0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/bfa2a927..5f1cefe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00-01 Stats: 648983 lines in 8151 files changed: 439394 ins; 124768 del; 84821 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From aartemov at openjdk.org Tue Jan 20 09:04:07 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:04:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:49:19 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments, added comments, renamed tests. > > src/hotspot/share/runtime/objectMonitor.cpp line 2296: > >> 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. >> 2295: if (state == ObjectWaiter::TS_RUN) { >> 2296: bool acquired = vthread_monitor_enter(current, node); > > If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. The else clause at line 2312 pairs with `if (state == ObjectWaiter::TS_RUN)` statement, there are only two possibilities, either TS_RUN, or TS_ENTER, the latter implies that the thread is on the `entry_list`. If `acquired` is false when handling TS_RUN case, it is fine, the whole method will return false at line 2316. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707399555 From phubner at openjdk.org Tue Jan 20 09:41:30 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 20 Jan 2026 09:41:30 GMT Subject: RFR: 8370441: Remove unnecessary/confusing null check in Verifier::verify() Message-ID: [JDK-8059924](https://bugs.openjdk.org/browse/JDK-8059924) introduced a nullcheck for a klass' Java mirror which runs during verification. However, in the modern VM, during verification time, the mirror is guaranteed to exist making the check unnecessary and misleading when reading the code. While implementing [JDK-8366488](https://bugs.openjdk.org/browse/JDK-8366488) it caused for quite some confusion. With this PR it is my intention to make sure that nobody gets side-tracked by this impossible condition. For an insight into previous discussion on this topic, please see the associated JBS issue. Testing: tiers 1-5 on Linux x64, AArch64, macOS x64, AArch64, Windows x64. ------------- Commit messages: - Turn check into an assert. Changes: https://git.openjdk.org/jdk/pull/29314/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370441 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29314/head:pull/29314 PR: https://git.openjdk.org/jdk/pull/29314 From aartemov at openjdk.org Tue Jan 20 09:49:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v25] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/0fd6bc7d..594b8769 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=23-24 Stats: 16 lines in 1 file changed: 2 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From aartemov at openjdk.org Tue Jan 20 09:49:42 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:42 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v20] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:12:20 GMT, David Holmes wrote: >> Addressed. > > You didn't expand the comment. IIUC if the state is TS_ENTER then we were notified and moved from TS_WAIT to TS_ENTER before being unparked. But, again IIUC, that will only happen if we don't have to post the event else the notification will unpark us directly and move us to TS_RUN. Which means that checking `!= TS_ENTER` is redundant because if we should post the event then we can't be in state TS_ENTER. Sorry for missing that. Yes, you are right, it is redundant, as `JvmtiExport::should_post_monitor_waited()` is mutually exclusive with being in the `TS_ENTER` state now. I added this to the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707570006 From aartemov at openjdk.org Tue Jan 20 09:49:47 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:49:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 00:25:18 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments, added comments, renamed tests. > > src/hotspot/share/runtime/objectMonitor.cpp line 2055: > >> 2053: // This is is now conditional as if the monitor_waited even >> 2054: // is allowed, then a thread, even virtual, should not be moved to >> 2055: // the entry_list, but rather unparked and let run. See the comment below. > > Suggestion: > > // If we will add the vthread to the entry list below then we need to > // increment the counter *before* doing so. > // Adding to _entry_list uses Atomic::cmpxchg() which already provides > // a fence that prevents reordering of the stores. > if (!JvmtiExport::should_post_monitor_waited()) { Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2066: > >> 2064: // If the monitor_waited JVMTI event is not allowed, a thread is >> 2065: // transferred to the entry_list, and it will eventually be unparked >> 2066: // only when it is chosen to become a successor. > > Suggestion: > > // only when it is chosen to become the successor. Thanks for spotting, addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2077: > >> 2075: // avoid a problem of having a suspension point when posting >> 2076: // the monitor_waited JVMTI event, as suspending such a thread >> 2077: // is no harm. > > Suggestion: > > // However, if the monitor_waited event is allowed, then > // the thread is set to state TS_RUN and unparked. The thread > // will then contend directly to reacquire the monitor and > // avoids being flagged as the successor. This avoids the problem > // of having a thread suspend whilst it is the successor. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2103: > >> 2101: evt->unpark(); >> 2102: } >> 2103: else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { > > Suggestion: > > } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_list_head())) { Fixed in the lates commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707568773 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707568292 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707567423 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2707566675 From aartemov at openjdk.org Tue Jan 20 09:56:09 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 20 Jan 2026 09:56:09 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Fixed whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/594b8769..f672d155 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org Tue Jan 20 10:06:00 2026 From: duke at openjdk.org (George Wort) Date: Tue, 20 Jan 2026 10:06:00 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 23:06:56 GMT, Evgeny Astigeevich wrote: > We currently rely on GC removing cold nmethods from HotCodeHeap. Won't the GC only remove an nmethod if it's inaccessible rather than it just being cold though? Or does the GC sweep methods that haven't been called for a while? > IMO we should do this instead of GC throwing them away. Yes, this was what I meant when I said purge/reset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3772024557 From duke at openjdk.org Tue Jan 20 10:07:19 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 10:07:19 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/e1bc2481...5f1cefe0 I've made timestamping optional with "-T" flag. The flag is part of the command sent to the target JVM. jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ The target diagnostic command handler can decide how to act on it. @dholmes-ora > ... what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? > And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). `Thread.print` already prints a timestamp, hence explicit "-T" has no effect for this particular command. This also affected my choice for using format "yyyy-MM-dd HH:mm:ss". At least as a default. Do you think we need to be able changing the timestamp format (say "-T=UTC")? Should we add time-stamping to STDOUT from commands that are of "action" type? E.g. "GC.run". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3772022851 From sgehwolf at openjdk.org Tue Jan 20 11:37:16 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 11:37:16 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name Message-ID: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. Thoughts? **Testing:** - [x] GHA - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. ------------- Commit messages: - 8375692: Hotspot container tests assert with non-ascii vendor name Changes: https://git.openjdk.org/jdk/pull/29315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375692 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From dholmes at openjdk.org Tue Jan 20 11:39:38 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 11:39:38 GMT Subject: RFR: 8370441: Remove unnecessary/confusing null check in Verifier::verify() In-Reply-To: References: Message-ID: <1otNaUy1vl2KWqmA0rLa2sRln5qKauzyNt63uD4WQRI=.c89541ab-9e61-443a-a490-196dad9a5d50@github.com> On Tue, 20 Jan 2026 09:33:11 GMT, Paul H?bner wrote: > [JDK-8059924](https://bugs.openjdk.org/browse/JDK-8059924) introduced a nullcheck for a klass' Java mirror which runs during verification. However, in the modern VM, during verification time, the mirror is guaranteed to exist making the check unnecessary and misleading when reading the code. While implementing [JDK-8366488](https://bugs.openjdk.org/browse/JDK-8366488) it caused for quite some confusion. With this PR it is my intention to make sure that nobody gets side-tracked by this impossible condition. > > For an insight into previous discussion on this topic, please see the associated JBS issue. > > Testing: tiers 1-5 on Linux x64, AArch64, macOS x64, AArch64, Windows x64. Changes requested by dholmes (Reviewer). src/hotspot/share/classfile/verifier.cpp line 195: > 193: if (klass->java_mirror() != nullptr) { > 194: klass->java_mirror()->identity_hash(); > 195: } You still need everything except the actual null check! ------------- PR Review: https://git.openjdk.org/jdk/pull/29314#pullrequestreview-3681750220 PR Review Comment: https://git.openjdk.org/jdk/pull/29314#discussion_r2707977220 From jnorlinder at openjdk.org Tue Jan 20 11:43:56 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Tue, 20 Jan 2026 11:43:56 GMT Subject: Integrated: 8374945: Avoid fstat in os::open In-Reply-To: References: Message-ID: <7TdqOsCJIlB3tN3pL467qid_5-3smP_6Oxy1juyFy8E=.fc78334c-15e1-4b17-9829-f14379a908d8@github.com> On Sat, 10 Jan 2026 16:55:08 GMT, Jonas Norlinder wrote: > Eliminate unnecessary calls to fstat in os::open akin to JDK-8373647. This optimization reduces system overhead. This pull request has now been integrated. Changeset: 3cc713fa Author: Jonas Norlinder Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/3cc713fa296dfb59bbc03f2cfd4fc7d8f4b44be2 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8374945: Avoid fstat in os::open Reviewed-by: dholmes, jsjolen, redestad ------------- PR: https://git.openjdk.org/jdk/pull/29152 From dholmes at openjdk.org Tue Jan 20 11:47:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 11:47:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v24] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:01:47 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 2296: >> >>> 2294: // unparked directly in notify_internal(). Its state is then TS_RUN. >>> 2295: if (state == ObjectWaiter::TS_RUN) { >>> 2296: bool acquired = vthread_monitor_enter(current, node); >> >> If we get here due to the direct unpark is it possible for `acquired` to be false? If so then I think the else clause starting at line 2312 below will be incorrect - it expects the thread to be on the entry list which it won't be. > > The else clause at line 2312 pairs with `if (state == ObjectWaiter::TS_RUN)` statement, there are only two possibilities, either TS_RUN, or TS_ENTER, the latter implies that the thread is on the `entry_list`. > > If `acquired` is false when handling TS_RUN case, it is fine, the whole method will return false at line 2316. Sorry misread the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2708005515 From syan at openjdk.org Tue Jan 20 11:52:03 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 11:52:03 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { > 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; > 380: } Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708015583 From phubner at openjdk.org Tue Jan 20 12:17:36 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 20 Jan 2026 12:17:36 GMT Subject: RFR: 8370441: Remove unnecessary/confusing null check in Verifier::verify() [v2] In-Reply-To: References: Message-ID: <5-zH4XIAg2SoprGRr2bEuGrnr2kAN20UxGuSiOeLkRc=.2d722a53-14a3-427a-b389-6d7f63f54205@github.com> > [JDK-8059924](https://bugs.openjdk.org/browse/JDK-8059924) introduced a nullcheck for a klass' Java mirror which runs during verification. However, in the modern VM, during verification time, the mirror is guaranteed to exist making the check unnecessary and misleading when reading the code. While implementing [JDK-8366488](https://bugs.openjdk.org/browse/JDK-8366488) it caused for quite some confusion. With this PR it is my intention to make sure that nobody gets side-tracked by this impossible condition. > > For an insight into previous discussion on this topic, please see the associated JBS issue. > > Testing: tiers 1-5 on Linux x64, AArch64, macOS x64, AArch64, Windows x64. Paul H?bner has updated the pull request incrementally with two additional commits since the last revision: - Keep the rest of the code. - Revert "Turn check into an assert." This reverts commit 78fa2983b532c4b390720316e79c975e61a4152a. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29314/files - new: https://git.openjdk.org/jdk/pull/29314/files/78fa2983..1ecae607 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29314&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29314&range=00-01 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29314/head:pull/29314 PR: https://git.openjdk.org/jdk/pull/29314 From cnorrbin at openjdk.org Tue Jan 20 13:22:01 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 20 Jan 2026 13:22:01 GMT Subject: RFR: 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" Message-ID: Hi everyone, When printing VM container info with trace container logging enabled, it is possible for the output to become interleaved. This can cause `TestMemoryAwareness.java` to fail, since the string it expects may be split by trace output appearing in the middle of the VM.info line. In #28766, I added improved VM.info formatting with the `OSContainer::print_container_metric` function, but it still performed printing in 2 steps, making it possible for that output to be split. With this PR, I have changed this so we construct the full line with `snprintf` before printing, ensuring the whole line is printed in a single step. This prevents other output from splitting the line, so the test can reliably detect the expected values. Since the test now works as expected, I have also removed it from the problemlist. Testing: - Oracle tiers 1-5 - Local container tests on cgroup v1/v2 with both podman and docker - Repeated runs of `TestMemoryAwareness.java` without any observed failures ------------- Commit messages: - one-print-metrics Changes: https://git.openjdk.org/jdk/pull/29319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303470 Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29319/head:pull/29319 PR: https://git.openjdk.org/jdk/pull/29319 From sgehwolf at openjdk.org Tue Jan 20 13:34:27 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 13:34:27 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:48:49 GMT, SendaoYan wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > >> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >> 380: } > > Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Sure. I can do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708370629 From kevinw at openjdk.org Tue Jan 20 14:55:39 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 20 Jan 2026 14:55:39 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/df6de4c1...5f1cefe0 Lots of duplication in the execute methods, of the same common condition around calling print_local_time... That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. Or separately in David's note earlier: "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773270519 From mdoerr at openjdk.org Tue Jan 20 15:42:33 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 20 Jan 2026 15:42:33 GMT Subject: RFR: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:15:35 GMT, Matthias Baesken wrote: > In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. > https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > This should probably be done also in other coding. I think this makes sense. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29228#pullrequestreview-3682848282 From cnorrbin at openjdk.org Tue Jan 20 15:44:13 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 20 Jan 2026 15:44:13 GMT Subject: RFR: 8375668: Compiler warning implicit-const-int-float-conversion by clang23 In-Reply-To: References: Message-ID: <-CGSjx93LtYOdp6ytxKdTchFLibilbMVhBa_lTdPFj4=.61674048-bdb1-4c6d-9ec4-40eedd76ee98@github.com> On Tue, 20 Jan 2026 06:47:54 GMT, SendaoYan wrote: > Hi all, > > File src/hotspot/os/linux/cgroupSubsystem_linux.hpp was reported compiler warning `implicit conversion from 'const uint64_t' (aka 'const unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616` by clang23. This compiler waring can be fixed by use explict convert instead the implict convert. This change do not change the orginal logic. Looks good! Thanks for catching and fixing this. I missed updating the initial value in my original change adding `MetricType`. ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/29309#pullrequestreview-3682855302 From duke at openjdk.org Tue Jan 20 15:58:46 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:58:46 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 14:51:27 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/438fc675...5f1cefe0 > > Lots of duplication in the execute methods, of the same common condition around calling print_local_time... > That's a reason in favour of the jcmd driver printing the timestamp itself so it can be done in one place, if required. > (The local attach API is not slow enough to cause a problematic latency in when the timestamp was printed, and when the command was actually run. Certainly not compared to the current workaround of running: "date; jcmd ...") > > > To deal with commands that already show a timestamp, if JCmd.java is where the timestamp is printed: if jcmd can send a parameter over the new attach api to the diagnostic command, then it can send a boolean "i have already printed a timestamp". Then only an existing command which already prints a timestamp would need to check. > > > Or separately in David's note earlier: > "And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds." > This relates to if the printing is done in the native code, and as I read it this was about having a flag checked before the individual execute methods, so it can be done in one place (not sure but maybe this would be DCmd::Executor::parse_and_execute()). @kevinjwalls I have created a v2 MR that handles timestamp in `DCmd::Executor::parse_and_execute` and doesn't change the executors. https://github.com/openjdk/jdk/pull/29325 The drawback is that timestamp can be printed twice in case of `Thread.print` diagnostic command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3773628920 From duke at openjdk.org Tue Jan 20 15:59:41 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:59:41 GMT Subject: RFR: 8357828: add timestamp to jcmd v2 Message-ID: `jcmd` provides great diagnostics but many commands lack a timestamp in their output. Adding a timestamp to the output of some would add value for those debugging JVM data. With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ This is a simplified approach to handle timestamp (v1 is [here](https://github.com/openjdk/jdk/pull/27368)) Some diagnostic commands already provide timestamps information. For example `Thread.print` already starts with a timestamp of "yyyy-MM-dd HH:mm:ss" format. In that case the timestamp is printed twice if "-T" flag is passed to `Thread.print`. ------------- Commit messages: - improve TestJcmdTimestamp.java. add '-f - implementation v2, top level timestamping - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - ... and 7 more: https://git.openjdk.org/jdk/compare/f2d5290c...eaea764d Changes: https://git.openjdk.org/jdk/pull/29325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357828 Stats: 189 lines in 6 files changed: 169 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29325/head:pull/29325 PR: https://git.openjdk.org/jdk/pull/29325 From mbaesken at openjdk.org Tue Jan 20 16:52:50 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 20 Jan 2026 16:52:50 GMT Subject: RFR: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 15:38:24 GMT, Martin Doerr wrote: > I think this makes sense. Thanks for the review ! Any idea about the jfr code mentioned above , should I include this in this PR or better leave out ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29228#issuecomment-3773920422 From sgehwolf at openjdk.org Tue Jan 20 16:57:26 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:26 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/73bad7f9..9f93451f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Tue Jan 20 16:57:29 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 13:30:43 GMT, Severin Gehwolf wrote: >> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: >> >>> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >>> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >>> 380: } >> >> Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java > > Sure. I can do that. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/9f93451faae3e4f168386e7367ba75c54797deb7 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2709230655 From cjplummer at openjdk.org Tue Jan 20 17:31:05 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Jan 2026 17:31:05 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 02:21:38 GMT, SendaoYan wrote: >> Hi all, >> >> This PR make 2 changes which make test more rubustness: >> >> 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. >> 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. >> >> Additional testing: >> >> - [x] All tests touched test by JDK-8373945 with relase build >> - [ ] All tests touched test by JDK-8373945 with fastdebug build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary runtime.gc() afer classloader has been reclaimed Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29285#pullrequestreview-3683399494 From sgehwolf at openjdk.org Tue Jan 20 17:40:09 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 17:40:09 GMT Subject: RFR: 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:14:22 GMT, Casper Norrbin wrote: > Hi everyone, > > When printing VM container info with trace container logging enabled, it is possible for the output to become interleaved. This can cause `TestMemoryAwareness.java` to fail, since the string it expects may be split by trace output appearing in the middle of the VM.info line. > > In #28766, I added improved VM.info formatting with the `OSContainer::print_container_metric` function, but it still performed printing in 2 steps, making it possible for that output to be split. With this PR, I have changed this so we construct the full line with `snprintf` before printing, ensuring the whole line is printed in a single step. This prevents other output from splitting the line, so the test can reliably detect the expected values. > > Since the test now works as expected, I have also removed it from the problemlist. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1/v2 with both podman and docker > - Repeated runs of `TestMemoryAwareness.java` without any observed failures Looks good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29319#pullrequestreview-3683460500 From kbarrett at openjdk.org Tue Jan 20 18:46:53 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 Jan 2026 18:46:53 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code Message-ID: Please review this change to MacOSX and bsd code to avoid using literal zero as a null pointer constant, instead using nullptr. Also disable that warning when building the gtest framework with clang, similarly to what was done in JDK-8338154 for gcc. Testing: mach5 tier1. Also tested with additional build changes to enable the warning. ------------- Commit messages: - fix MacOSX -Wzero-as-null-pointer-constant warnings Changes: https://git.openjdk.org/jdk/pull/29329/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29329&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375738 Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29329/head:pull/29329 PR: https://git.openjdk.org/jdk/pull/29329 From dcubed at openjdk.org Tue Jan 20 19:03:17 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 20 Jan 2026 19:03:17 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:56:09 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Fixed whitespace. I last reviewed v19 and I've re-reviewed all the changes since then as one diff between v19 and v25. This looks good to me and I've posted just a couple of comments. src/hotspot/share/runtime/objectMonitor.cpp line 1869: > 1867: > 1868: int ret = OS_OK; > 1869: bool was_notified = true; L2021: // Monitor notify has precedence over thread interrupt. With this change to `was_notified` default value, I don't think we can say that monitor notify has precedence over thread interrupt anymore. src/hotspot/share/runtime/objectMonitor.cpp line 1933: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. > 1933: if (JvmtiExport::should_post_monitor_waited()) { Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3683757507 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709683636 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709638312 From erikj at openjdk.org Tue Jan 20 19:27:59 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 Jan 2026 19:27:59 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: References: Message-ID: <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com> On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett wrote: > Please review this change to MacOSX and bsd code to avoid using literal zero > as a null pointer constant, instead using nullptr. > > Also disable that warning when building the gtest framework with clang, > similarly to what was done in JDK-8338154 for gcc. > > Testing: mach5 tier1. Also tested with additional build changes to enable the > warning. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29329#pullrequestreview-3683921917 From dcubed at openjdk.org Tue Jan 20 20:34:38 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 20 Jan 2026 20:34:38 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:56:54 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 1869: > >> 1867: >> 1868: int ret = OS_OK; >> 1869: bool was_notified = true; > > L2021: // Monitor notify has precedence over thread interrupt. > > With this change to `was_notified` default value, I don't think we can say > that monitor notify has precedence over thread interrupt anymore. I've tracked that comment back to this very old changeset: $ git log 22929fb78f46^! commit 22929fb78f4606f726b652a25772980336398575 Author: Karen Kinnear Date: Fri Oct 22 15:59:34 2010 -0400 6988353: refactor contended sync subsystem Reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2709973474 From dholmes at openjdk.org Tue Jan 20 21:02:13 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 21:02:13 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:32:07 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1869: >> >>> 1867: >>> 1868: int ret = OS_OK; >>> 1869: bool was_notified = true; >> >> L2021: // Monitor notify has precedence over thread interrupt. >> >> With this change to `was_notified` default value, I don't think we can say >> that monitor notify has precedence over thread interrupt anymore. > > I've tracked that comment back to this very old changeset: > > > $ git log 22929fb78f46^! > commit 22929fb78f4606f726b652a25772980336398575 > Author: Karen Kinnear > Date: Fri Oct 22 15:59:34 2010 -0400 > > 6988353: refactor contended sync subsystem > > Reduce complexity by factoring synchronizer.cpp > > Reviewed-by: dholmes, never, coleenp I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: 1882 if (interrupted || HAS_PENDING_EXCEPTION) { 1883 was_notified = false; will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710053165 From pchilanomate at openjdk.org Tue Jan 20 21:07:27 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 21:07:27 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:00:01 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread Thanks for the update Serguei, looks good to me. A few comments below. src/hotspot/share/runtime/javaThread.cpp line 1186: > 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { > 1185: // Suspending a vthread transition disabler can cause deadlocks. > 1186: // The HandshakeState::has_operation does not allow such suspends. So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) src/hotspot/share/runtime/javaThread.hpp line 737: > 735: private: > 736: bool _is_in_vthread_transition; // thread is in virtual thread mount state transition > 737: bool _is_vthread_transition_disabler; // thread currently disabled vthread transitions Should we make this field `JVMTI` only? src/hotspot/share/runtime/suspendResumeManager.cpp line 136: > 134: while (is_suspended()) { > 135: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_target)); > 136: assert(!_target->is_vthread_transition_disabler(), "attempt to suspend a vthread transition disabler"); We could check this once before the loop since only the current thread changes `_is_vthread_transition_disabler`. test/hotspot/jtreg/ProblemList.txt line 2: > 1: # > 2: # Copyright (c) 2016, 2026, Oracle and/or its affiliates. All rights reserved. Not needed anymore. ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3684247351 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710046216 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710038316 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710050645 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2710059988 From naoto at openjdk.org Tue Jan 20 22:43:41 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:43:41 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM from i18n point of view. Probably needs more reviews from hotspot side test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > 1: /* > 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. nit: needs to keep 2025 ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3684605144 PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710321875 From dholmes at openjdk.org Tue Jan 20 23:30:12 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Jan 2026 23:30:12 GMT Subject: RFR: 8370441: Remove unnecessary/confusing null check in Verifier::verify() [v2] In-Reply-To: <5-zH4XIAg2SoprGRr2bEuGrnr2kAN20UxGuSiOeLkRc=.2d722a53-14a3-427a-b389-6d7f63f54205@github.com> References: <5-zH4XIAg2SoprGRr2bEuGrnr2kAN20UxGuSiOeLkRc=.2d722a53-14a3-427a-b389-6d7f63f54205@github.com> Message-ID: On Tue, 20 Jan 2026 12:17:36 GMT, Paul H?bner wrote: >> [JDK-8059924](https://bugs.openjdk.org/browse/JDK-8059924) introduced a nullcheck for a klass' Java mirror which runs during verification. However, in the modern VM, during verification time, the mirror is guaranteed to exist making the check unnecessary and misleading when reading the code. While implementing [JDK-8366488](https://bugs.openjdk.org/browse/JDK-8366488) it caused for quite some confusion. With this PR it is my intention to make sure that nobody gets side-tracked by this impossible condition. >> >> For an insight into previous discussion on this topic, please see the associated JBS issue. >> >> Testing: tiers 1-5 on Linux x64, AArch64, macOS x64, AArch64, Windows x64. > > Paul H?bner has updated the pull request incrementally with two additional commits since the last revision: > > - Keep the rest of the code. > - Revert "Turn check into an assert." > > This reverts commit 78fa2983b532c4b390720316e79c975e61a4152a. Looks good. The analysis seems correct and I agree that checking for impossible conditions is confusing. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29314#pullrequestreview-3684716491 From syan at openjdk.org Wed Jan 21 02:01:30 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 02:01:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3685013389 From dholmes at openjdk.org Wed Jan 21 02:30:19 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 02:30:19 GMT Subject: RFR: 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:14:22 GMT, Casper Norrbin wrote: > Hi everyone, > > When printing VM container info with trace container logging enabled, it is possible for the output to become interleaved. This can cause `TestMemoryAwareness.java` to fail, since the string it expects may be split by trace output appearing in the middle of the VM.info line. > > In #28766, I added improved VM.info formatting with the `OSContainer::print_container_metric` function, but it still performed printing in 2 steps, making it possible for that output to be split. With this PR, I have changed this so we construct the full line with `snprintf` before printing, ensuring the whole line is printed in a single step. This prevents other output from splitting the line, so the test can reliably detect the expected values. > > Since the test now works as expected, I have also removed it from the problemlist. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1/v2 with both podman and docker > - Repeated runs of `TestMemoryAwareness.java` without any observed failures That seems fine to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29319#pullrequestreview-3685082437 From syan at openjdk.org Wed Jan 21 03:40:02 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:40:02 GMT Subject: RFR: 8375668: Compiler warning implicit-const-int-float-conversion by clang23 In-Reply-To: <-CGSjx93LtYOdp6ytxKdTchFLibilbMVhBa_lTdPFj4=.61674048-bdb1-4c6d-9ec4-40eedd76ee98@github.com> References: <-CGSjx93LtYOdp6ytxKdTchFLibilbMVhBa_lTdPFj4=.61674048-bdb1-4c6d-9ec4-40eedd76ee98@github.com> Message-ID: On Tue, 20 Jan 2026 15:39:46 GMT, Casper Norrbin wrote: >> Hi all, >> >> File src/hotspot/os/linux/cgroupSubsystem_linux.hpp was reported compiler warning `implicit conversion from 'const uint64_t' (aka 'const unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616` by clang23. This compiler waring can be fixed by use explict convert instead the implict convert. This change do not change the orginal logic. > > Looks good! Thanks for catching and fixing this. > > I missed updating the initial value in my original change adding `MetricType`. Thanks for the reviews @caspernorrbin @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/29309#issuecomment-3775978331 From syan at openjdk.org Wed Jan 21 03:42:06 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:42:06 GMT Subject: RFR: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 [v3] In-Reply-To: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> References: <7a8kdJIL239voUmYcBMfSl6W__e2cyViwgLv9iVetm8=.14f1c7e0-d288-4160-8e6d-43613932ea99@github.com> Message-ID: On Tue, 20 Jan 2026 06:03:00 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary runtime.gc() afer classloader has been reclaimed > > Thanks for addressing all the feedback. Thanks for the suggestions and reviews @lmesnik @plummercj ------------- PR Comment: https://git.openjdk.org/jdk/pull/29285#issuecomment-3775982942 From syan at openjdk.org Wed Jan 21 03:42:07 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:42:07 GMT Subject: Integrated: 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 In-Reply-To: References: Message-ID: <_t6tz7eMUbF_6aLOYbJdoGzenjLeQmKygr8S5JW1lis=.37cc787e-33cf-44e8-b70a-fbccf6f17419@github.com> On Sat, 17 Jan 2026 04:05:14 GMT, SendaoYan wrote: > Hi all, > > This PR make 2 changes which make test more rubustness: > > 1. Add max 10 times tries which removed by JDK-8342659, this will make test more steady after JDK-8373945. vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java fails before this PR, run passed after this PR with fastdebug build. > 2. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java try to invoke thread and do not wailt the thread run finish unload the class immediately. This PR wait util the thread is non alive, and wait more 2 senonds to make sure the thread exit completely. This will make test more robustness, before this PR vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java fails probability 1/50, after this PR test run all passed 10k times. > > Additional testing: > > - [x] All tests touched test by JDK-8373945 with relase build > - [x] All tests touched test by JDK-8373945 with fastdebug build This pull request has now been integrated. Changeset: 599ed0bb Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/599ed0bb5fd62e26c71651bc02f198cd27636cfb Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod 8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945 Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/29285 From syan at openjdk.org Wed Jan 21 03:43:10 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 03:43:10 GMT Subject: Integrated: 8375668: Compiler warning implicit-const-int-float-conversion by clang23 In-Reply-To: References: Message-ID: <6Sw_Rd8_PWYaVsgWPME_vyGnvCME0lteqfUVbpRVFcc=.220729fe-3138-45fc-824d-bbd13cd67eb6@github.com> On Tue, 20 Jan 2026 06:47:54 GMT, SendaoYan wrote: > Hi all, > > File src/hotspot/os/linux/cgroupSubsystem_linux.hpp was reported compiler warning `implicit conversion from 'const uint64_t' (aka 'const unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616` by clang23. This compiler waring can be fixed by use explict convert instead the implict convert. This change do not change the orginal logic. This pull request has now been integrated. Changeset: a448f0b9 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/a448f0b9f46de35ef26994e8540b9ae242372e8d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8375668: Compiler warning implicit-const-int-float-conversion by clang23 Reviewed-by: dholmes, cnorrbin ------------- PR: https://git.openjdk.org/jdk/pull/29309 From pchilanomate at openjdk.org Wed Jan 21 05:05:56 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:05:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:56:09 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Fixed whitespace. Looks good overall, just a few comments. Thanks. src/hotspot/share/runtime/objectMonitor.cpp line 558: > 556: bool is_virtual = ce != nullptr && ce->is_virtual_thread(); > 557: if (is_virtual) { > 558: notify_contended_enter(current, post_jvmti_events); We should also add `post_jvmti_event &&` to L567 below. src/hotspot/share/runtime/objectMonitor.cpp line 2065: > 2063: did_notify = true; > 2064: > 2065: if (!JvmtiExport::should_post_monitor_waited()) { For the vthread case this value could be different from the one read above. src/hotspot/share/runtime/objectMonitor.cpp line 2079: > 2077: iterator->TState = ObjectWaiter::TS_RUN; > 2078: > 2079: OrderAccess::fence(); Is the fence needed? We already synchronize with `_wait_set_lock`. src/hotspot/share/runtime/objectMonitor.cpp line 2085: > 2083: if (!iterator->is_vthread()) { > 2084: iterator->wait_reenter_begin(this); > 2085: if (has_unmounted_vthreads()) { The thread is going to call `enter` for this case so this is not needed. Same with `wait_reenter_begin` above. src/hotspot/share/runtime/objectMonitor.cpp line 2105: > 2103: } > 2104: return did_notify; > 2105: } Given that there are more differences than common code, I think it's probably better to just separate the vthread and platform thread paths to make it easier to read. Something like this: https://github.com/openjdk/jdk/compare/pr/27040...pchilano:jdk:altnotify You could add a comment on top of the method about the behavior when monitor_waited event is enabled. src/hotspot/share/runtime/objectMonitor.cpp line 2291: > 2289: // because, if monitor_waited JVMTI event is allowed, there can be a vthead which > 2290: // is not on the entry_list, but has been notified in the sense that it has been > 2291: // unparked directly in notify_internal(). Its state is then TS_RUN. Suggestion for shorter comment: // We check the state rather than was_notified because, when JVMTI // monitor_waited event is enabled, the notifier only unparks the waiter // without adding it to the entry_list. src/hotspot/share/runtime/objectMonitor.hpp line 367: > 365: bool enter_is_async_deflating(); > 366: void notify_contended_enter(JavaThread *current, bool post_jvmti_events = true); > 367: void post_waited_event(JavaThread* current, EventJavaMonitorWait* wait_event, bool was_notified, ObjectWaiter* node, jlong millis, int ret); Leftover? ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3685329768 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710948914 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710964239 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710957840 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710958952 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710969804 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710956795 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710954338 From pchilanomate at openjdk.org Wed Jan 21 05:05:58 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:05:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:59:57 GMT, David Holmes wrote: >> I've tracked that comment back to this very old changeset: >> >> >> $ git log 22929fb78f46^! >> commit 22929fb78f4606f726b652a25772980336398575 >> Author: Karen Kinnear >> Date: Fri Oct 22 15:59:34 2010 -0400 >> >> 6988353: refactor contended sync subsystem >> >> Reduce complexity by factoring synchronizer.cpp >> >> Reviewed-by: dholmes, never, coleenp > > I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: > > 1882 if (interrupted || HAS_PENDING_EXCEPTION) { > 1883 was_notified = false; > > will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. > > The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. Might be clearer to move `bool was_notified = true;` right before the branch at L1908 where we determine if there was a notification or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710950713 From pchilanomate at openjdk.org Wed Jan 21 05:06:00 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 05:06:00 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:42:54 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 1933: > >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >> 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. >> 1933: if (JvmtiExport::should_post_monitor_waited()) { > > Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? I think we will have to add it as a branch condition since the event could have been enabled after notification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2710952492 From dholmes at openjdk.org Wed Jan 21 05:13:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:13:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> On Tue, 20 Jan 2026 22:38:26 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > >> 1: /* >> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. > > nit: needs to keep 2025 Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710989942 From dholmes at openjdk.org Wed Jan 21 05:16:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:16:56 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett wrote: > Please review this change to MacOSX and bsd code to avoid using literal zero > as a null pointer constant, instead using nullptr. > > Also disable that warning when building the gtest framework with clang, > similarly to what was done in JDK-8338154 for gcc. > > Testing: mach5 tier1. Also tested with additional build changes to enable the > warning. Looks good. If we don't already have the warning disabled, why are these occurrences not already causing warnings (and thus errors) in clang builds?? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29329#pullrequestreview-3685377964 From sspitsyn at openjdk.org Wed Jan 21 05:23:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:23:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:54:46 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread > > src/hotspot/share/runtime/javaThread.hpp line 737: > >> 735: private: >> 736: bool _is_in_vthread_transition; // thread is in virtual thread mount state transition >> 737: bool _is_vthread_transition_disabler; // thread currently disabled vthread transitions > > Should we make this field `JVMTI` only? Good suggestion, thanks! Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711008857 From dholmes at openjdk.org Wed Jan 21 05:25:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:25:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:48:00 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1933: >> >>> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >>> 1932: // A thread which should post monitor_waited event is never in TS_ENTER state. >>> 1933: if (JvmtiExport::should_post_monitor_waited()) { >> >> Is it worth asserting that `node.TState != ObjectWaiter::TS_ENTER` inside the if-statement? > > I think we will have to add it as a branch condition since the event could have been enabled after notification. If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2711012799 From dholmes at openjdk.org Wed Jan 21 05:30:45 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:30:45 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:23:14 GMT, David Holmes wrote: >> I think we will have to add it as a branch condition since the event could have been enabled after notification. > > If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). And the notification code would have to assume that the event will be enabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2711019472 From sspitsyn at openjdk.org Wed Jan 21 05:41:58 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:41:58 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:57:29 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375362: deadlock with unmount of suspended virtual thread interrupting another virtual thread > > src/hotspot/share/runtime/javaThread.cpp line 1186: > >> 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { >> 1185: // Suspending a vthread transition disabler can cause deadlocks. >> 1186: // The HandshakeState::has_operation does not allow such suspends. > > So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) Good check, thanks. The `JvmtiJavaUpcallMark` hides the JVMTI events during the `interrupt` upcall: JvmtiEnv::InterruptThread(jthread thread) { . . . if (java_lang_VirtualThread::is_instance(thread_obj)) { // For virtual threads we have to call into Java to interrupt: Handle obj(current_thread, thread_obj); JvmtiJavaUpcallMark jjum(current_thread); // hide JVMTI events for Java upcall <== !!! JavaValue result(T_VOID); JavaCalls::call_virtual(&result, obj, vmClasses::Thread_klass(), vmSymbols::interrupt_method_name(), vmSymbols::void_method_signature(), current_thread); > src/hotspot/share/runtime/suspendResumeManager.cpp line 136: > >> 134: while (is_suspended()) { >> 135: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_target)); >> 136: assert(!_target->is_vthread_transition_disabler(), "attempt to suspend a vthread transition disabler"); > > We could check this once before the loop since only the current thread changes `_is_vthread_transition_disabler`. Good suggestion, thanks! Fixed now. > test/hotspot/jtreg/ProblemList.txt line 2: > >> 1: # >> 2: # Copyright (c) 2016, 2026, Oracle and/or its affiliates. All rights reserved. > > Not needed anymore. Good catch, thanks. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711037099 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711038426 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2711039636 From dholmes at openjdk.org Wed Jan 21 05:46:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:46:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 10:03:15 GMT, Ivan Bereziuk wrote: > Do you think we need to be able changing the timestamp format (say "-T=UTC")? The main use of the time-stamp is to be able to correlate the time the diagnostic command was run, with the time of other events captured in other logs. So for that you would want compatible/comparable timestamps. As I mentioned previously UL has different timestamp formats, so be able to match those may be of benefit. Though I could also see that as being a future enhancement once we see how the basic wall-clock timestamp is received. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776296670 From sspitsyn at openjdk.org Wed Jan 21 05:55:33 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 05:55:33 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v14] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: moved vthread_transition_disabler under JVMTI_ONLY; two more tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/05b4c996..64e7dc9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=12-13 Stats: 16 lines in 5 files changed: 3 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From kbarrett at openjdk.org Wed Jan 21 06:02:34 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 06:02:34 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:14:49 GMT, David Holmes wrote: > If we don't already have the warning disabled, why are these occurrences not already causing warnings (and thus errors) in clang builds?? Because we aren't currently enabling the warning. I have a build change to enable the warning ready to propose once the warnings that would be triggered by it have been addressed. That's what I'm using to find these. Note that when I started working on this there were thousands of warnings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776345311 From dholmes at openjdk.org Wed Jan 21 06:02:40 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 06:02:40 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/d32dc5c4...5f1cefe0 > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776344918 From kbarrett at openjdk.org Wed Jan 21 06:05:46 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 06:05:46 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com> References: <0envuxcIleKParv5aWj9n3w8IPuau-2_cWgWOvkszQ4=.d86cceda-c2b6-444e-9a85-3d7f30f99f85@github.com> Message-ID: On Tue, 20 Jan 2026 19:24:16 GMT, Erik Joelsson wrote: >> Please review this change to MacOSX and bsd code to avoid using literal zero >> as a null pointer constant, instead using nullptr. >> >> Also disable that warning when building the gtest framework with clang, >> similarly to what was done in JDK-8338154 for gcc. >> >> Testing: mach5 tier1. Also tested with additional build changes to enable the >> warning. > > Marked as reviewed by erikj (Reviewer). Thanks for reviews @erikj79 and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776351783 From kbarrett at openjdk.org Wed Jan 21 06:08:38 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 Jan 2026 06:08:38 GMT Subject: Integrated: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:40:10 GMT, Kim Barrett wrote: > Please review this change to MacOSX and bsd code to avoid using literal zero > as a null pointer constant, instead using nullptr. > > Also disable that warning when building the gtest framework with clang, > similarly to what was done in JDK-8338154 for gcc. > > Testing: mach5 tier1. Also tested with additional build changes to enable the > warning. This pull request has now been integrated. Changeset: b5727d27 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/b5727d27622e1e321733f8d0e606b366984104be Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code Reviewed-by: erikj, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29329 From dholmes at openjdk.org Wed Jan 21 06:10:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 06:10:44 GMT Subject: RFR: 8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 06:00:28 GMT, Kim Barrett wrote: > Because we aren't currently enabling the warning. Sorry, the "gtest" part didn't register with me, ------------- PR Comment: https://git.openjdk.org/jdk/pull/29329#issuecomment-3776364384 From alanb at openjdk.org Wed Jan 21 07:25:57 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 07:25:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: <63zZ3oyXzNCOjLubKLhsa63UwZGSh1-3o-YLX3YbjF0=.2e2ca1cd-a933-4a59-9c5f-bc9806a5ff14@github.com> On Wed, 21 Jan 2026 06:00:18 GMT, David Holmes wrote: > > The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in Thread.print. > > That could be seen as a poor choice by `Thread.print`. The `VMUptimeDCmd` uses `OutputStream::date_stamp()` which in turn uses `os::iso8601_time`, which is also what the `time` decorator for UL uses. For anything new then we should try to use ISO 8601 unless there is a good reason to do otherwise. The "yyyy-MM-dd HH:mm:ss" format, seen in the jstack and jcmd Thread.print output, seems to go back a long way. I wonder how risky it would be change that now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3776554080 From sgehwolf at openjdk.org Wed Jan 21 09:07:51 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 09:07:51 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 05:10:15 GMT, David Holmes wrote: >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. >> >> nit: needs to keep 2025 > > Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711604932 From sgehwolf at openjdk.org Wed Jan 21 10:05:30 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Restore Bellsoft copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/9f93451f..e539a64f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Wed Jan 21 10:05:31 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:31 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 09:03:25 GMT, Severin Gehwolf wrote: >> Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. > > OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711832957 From dholmes at openjdk.org Wed Jan 21 12:19:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 12:19:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 10:00:15 GMT, Severin Gehwolf wrote: >> OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. > > Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > I'm also not an Oracle contributor, fwiw. We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712314104 From sgehwolf at openjdk.org Wed Jan 21 12:53:40 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 12:53:40 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 12:16:17 GMT, David Holmes wrote: >> Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > >> I'm also not an Oracle contributor, fwiw. > > We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712437275 From aartemov at openjdk.org Wed Jan 21 13:26:33 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:33 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: Message-ID: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewers' comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/f672d155..20a81450 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=25-26 Stats: 101 lines in 2 files changed: 23 ins; 60 del; 18 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 aartemov at openjdk.org Wed Jan 21 13:26:41 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:26:38 GMT, David Holmes wrote: >> If the event can be enabled (and disabled?) dynamically then that changes a lot! We can't use the event state as a proxy for TS_RUN state (nor vice-versa). > > And the notification code would have to assume that the event will be enabled. I added it back to the branch condition and modified the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712551707 From aartemov at openjdk.org Wed Jan 21 13:26:39 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:45:49 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Fixed whitespace. > > src/hotspot/share/runtime/objectMonitor.cpp line 558: > >> 556: bool is_virtual = ce != nullptr && ce->is_virtual_thread(); >> 557: if (is_virtual) { >> 558: notify_contended_enter(current, post_jvmti_events); > > We should also add `post_jvmti_event &&` to L567 below. Good catch, added! > src/hotspot/share/runtime/objectMonitor.cpp line 2079: > >> 2077: iterator->TState = ObjectWaiter::TS_RUN; >> 2078: >> 2079: OrderAccess::fence(); > > Is the fence needed? We already synchronize with `_wait_set_lock`. Actually it is not, as we are inside of a wider critical section. > src/hotspot/share/runtime/objectMonitor.cpp line 2105: > >> 2103: } >> 2104: return did_notify; >> 2105: } > > Given that there are more differences than common code, I think it's probably better to just separate the vthread and platform thread paths to make it easier to read. Something like this: https://github.com/openjdk/jdk/compare/pr/27040...pchilano:jdk:altnotify > You could add a comment on top of the method about the behavior when monitor_waited event is enabled. Thanks, I have incorporated your changes. > src/hotspot/share/runtime/objectMonitor.cpp line 2291: > >> 2289: // because, if monitor_waited JVMTI event is allowed, there can be a vthead which >> 2290: // is not on the entry_list, but has been notified in the sense that it has been >> 2291: // unparked directly in notify_internal(). Its state is then TS_RUN. > > Suggestion for shorter comment: > > // We check the state rather than was_notified because, when JVMTI > // monitor_waited event is enabled, the notifier only unparks the waiter > // without adding it to the entry_list. Yes, a bit wordy, fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 367: > >> 365: bool enter_is_async_deflating(); >> 366: void notify_contended_enter(JavaThread *current, bool post_jvmti_events = true); >> 367: void post_waited_event(JavaThread* current, EventJavaMonitorWait* wait_event, bool was_notified, ObjectWaiter* node, jlong millis, int ret); > > Leftover? Yes, a leftover from a previous iteration, thanks for spotting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553017 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712554279 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712557326 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553670 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712553472 From aartemov at openjdk.org Wed Jan 21 13:26:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 21 Jan 2026 13:26:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v26] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 04:46:56 GMT, Patricio Chilano Mateo wrote: >> I think Dan is right that this has changed the behaviour by deciding `was_notified` earlier in the process. Now this check: >> >> 1882 if (interrupted || HAS_PENDING_EXCEPTION) { >> 1883 was_notified = false; >> >> will supercede the fact we could actually have been notified. And that is a problem because if the current was notified but now throws InterruptedException then we lose the notification. I think my suggestion to set `was_notified` at 1883 was wrong - we need to undo that. >> >> The key point is that if we unlink ourselves then we were definitely not notified; otherwise we must have been. > > Might be clearer to move `bool was_notified = true;` right before the branch at L1908 where we determine if there was a notification or not. I think we just undo this recent change, moving `bool was_notified = true;` to L1908 is not possible as it is used further at L2012 outside of this huge code block. So it has to be declared where it used to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2712552530 From lucy at openjdk.org Wed Jan 21 13:59:58 2026 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 21 Jan 2026 13:59:58 GMT Subject: RFR: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:15:35 GMT, Matthias Baesken wrote: > In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. > https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > This should probably be done also in other coding. Looks good for transient files. For files containing "real" data, I would require verification that it's a file corruption issue and not just a (temporary) access issue. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29228#pullrequestreview-3687381555 From mbaesken at openjdk.org Wed Jan 21 14:17:34 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 21 Jan 2026 14:17:34 GMT Subject: RFR: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: <4DzjyKNPIdx3A3p0LmLlVpKpU2E08HpdB2xu4NbCxMA=.8535c138-910b-4a4c-9280-30c4cfd34d47@github.com> On Wed, 14 Jan 2026 11:15:35 GMT, Matthias Baesken wrote: > In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. > https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > This should probably be done also in other coding. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29228#issuecomment-3778343703 From mbaesken at openjdk.org Wed Jan 21 14:17:35 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 21 Jan 2026 14:17:35 GMT Subject: Integrated: 8374998: Failing os::write - remove bad file In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 11:15:35 GMT, Matthias Baesken wrote: > In filemap.cpp there is error - handling for os::write and in case of failure a 'bad' potentially incomplete file is removed. > https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/hotspot/share/cds/filemap.cpp#L1059-L1062 > This should probably be done also in other coding. This pull request has now been integrated. Changeset: 4c9103f7 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/4c9103f7b6c91b0f237859516ef72bb9ee27157e Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8374998: Failing os::write - remove bad file Reviewed-by: mdoerr, lucy ------------- PR: https://git.openjdk.org/jdk/pull/29228 From kevinw at openjdk.org Wed Jan 21 15:26:35 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Jan 2026 15:26:35 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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 15 additional commits since the last revision: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/1e69e598...5f1cefe0 OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3778803463 From duke at openjdk.org Wed Jan 21 16:28:15 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:28:15 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v3] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision: - improve test. Assert new ISO 8601 format - handle timestamp in parse_and_execute(). Thread.print is exceptional. Add default initialation to JcmdOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/5f1cefe0..c702901d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01-02 Stats: 133 lines in 4 files changed: 19 ins; 101 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From duke at openjdk.org Wed Jan 21 16:54:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 21 Jan 2026 16:54:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 15:24:15 GMT, Kevin Walls wrote: >> Ivan Bereziuk 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 15 additional commits since the last revision: >> >> - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - changes to jcmd.md >> - undo changes to reorder_help_cmd() >> - cleanup >> - add timestamp to VM.version. Add test >> - updated jcmd usage text >> - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible >> - introduce -T as a commong flag >> - Merge branch 'master' into 8357828_add_timestamp_to_jcmd >> - ... and 5 more: https://git.openjdk.org/jdk/compare/e81dffc4...5f1cefe0 > > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: > Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? > (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... > This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. > It sidesteps the problem that Thread.print uses an arguably "wrong" format. > (An in time, maybe Thread.print would migrate to not printing a timestamp.) > > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. > Heap dumping prints its own time taken, but few other commands consider it interesting.) @kevinjwalls > not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) Yes. That is indeed an option to consider. In here * I've removed "print timestamp" handling from `DCmd::execute()`. Now it's handled in `DCmd::Executor::parse_and_execute()`. The additional parameter passed to `DCmd::execute` serves the only purpose - let `Thread.print` dcmd be backwards compatible and print a "timestamp" of old format when "-T" flag was passed. * I have also embraced an ISO 8601 format. Example `2026-01-21T16:58:49.518+0100`; Alan, David, thank you. It might be fine to keep framework of "common jcmd flags" in place. Executors would need to know about "-format=json" if that becomes a common flag in the future. Other than that, it might be fine to let "Thread.print" print two timestamps which will make the implementation simpler: https://github.com/openjdk/jdk/pull/29325 Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3779616328 From pchilanomate at openjdk.org Wed Jan 21 18:18:53 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 18:18:53 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:36:32 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1186: >> >>> 1184: bool JavaThread::java_suspend(bool register_vthread_SR) { >>> 1185: // Suspending a vthread transition disabler can cause deadlocks. >>> 1186: // The HandshakeState::has_operation does not allow such suspends. >> >> So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change) > > Good check, thanks. > The `JvmtiJavaUpcallMark` hides the JVMTI events during the `interrupt` upcall: > > JvmtiEnv::InterruptThread(jthread thread) { > . . . > if (java_lang_VirtualThread::is_instance(thread_obj)) { > // For virtual threads we have to call into Java to interrupt: > Handle obj(current_thread, thread_obj); > JvmtiJavaUpcallMark jjum(current_thread); // hide JVMTI events for Java upcall <== !!! > JavaValue result(T_VOID); > JavaCalls::call_virtual(&result, > obj, > vmClasses::Thread_klass(), > vmSymbols::interrupt_method_name(), > vmSymbols::void_method_signature(), > current_thread); I see, could we keep the original assert? Should not be possible to request suspend on a transition disabler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2713776399 From sspitsyn at openjdk.org Wed Jan 21 19:48:27 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 19:48:27 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:13:39 GMT, Patricio Chilano Mateo wrote: > I see, could we keep the original assert? Should not be possible to request suspend on a transition disabler. Even though such a request is not possible, it should be allowed in general as it does not break anything at this execution point. :) But I do not see a problem to restore the assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714084109 From sspitsyn at openjdk.org Wed Jan 21 20:11:53 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 20:11:53 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: restored the original assert with a different message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/64e7dc9e..bb0fc064 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=13-14 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From pchilanomate at openjdk.org Wed Jan 21 20:16:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 20:16:24 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: <3QgrFiiQHK2BxQb36Za5uucbGcl5lbjgwHloH1D7rmo=.8adaeb7c-00c8-4459-84c2-ba1cb66f841f@github.com> On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Thanks Serguei, looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689199704 From pchilanomate at openjdk.org Wed Jan 21 20:39:55 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 21 Jan 2026 20:39:55 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. Thanks for the updates, looks good to me. src/hotspot/share/runtime/objectMonitor.hpp line 42: > 40: class BasicLock; > 41: class ContinuationWrapper; > 42: class EventJavaMonitorWait; Nit: leftover ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3689302980 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2714253300 From lmesnik at openjdk.org Wed Jan 21 21:51:14 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 Jan 2026 21:51:14 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Looks good. A couple of small nits, feel free to ignore them. src/hotspot/share/runtime/handshake.cpp line 525: > 523: #if INCLUDE_JVMTI > 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { > 525: // filter out suspend operations while JavaThread is in disable_suspend mode does it makes sense to update comment to // filter out suspend operations while JavaThread is in disable_suspend mode or in transition or something more generic // check if JavaThread can be suspended in this handshake test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp line 63: > 61: JNIEXPORT void JNICALL > 62: Java_ThreadStateTest2_setMonitorContendedMode(JNIEnv* jni, jclass klass, jboolean enable) { > 63: jvmtiError err = jvmti->SetEventNotificationMode(enable ? JVMTI_ENABLE : JVMTI_DISABLE, JVMTI_EVENT_MONITOR_CONTENDED_ENTER, nullptr); You can use set_event_notification_mode(jvmtiEnv*, ... ) from jvmti_common.h ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689496071 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714417725 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714441116 From sspitsyn at openjdk.org Wed Jan 21 21:59:38 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 21:59:38 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:11:53 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the original assert with a different message Patricio and Leonid, thank you a lot for reviews and suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3781344905 From sspitsyn at openjdk.org Wed Jan 21 23:46:40 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 23:46:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v16] In-Reply-To: References: Message-ID: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: minor comment tweak in a comment; use test lib function set_event_notification_mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28740/files - new: https://git.openjdk.org/jdk/pull/28740/files/bb0fc064..b68dbe45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28740&range=14-15 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28740/head:pull/28740 PR: https://git.openjdk.org/jdk/pull/28740 From lmesnik at openjdk.org Wed Jan 21 23:46:40 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 Jan 2026 23:46:40 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v16] In-Reply-To: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> References: <_ucZjYmkkIu-sdMb2SiUbr2G4zYm6h-AhA96fUv2n90=.0bce5e1b-817b-4dc8-b840-50abb4e07832@github.com> Message-ID: On Wed, 21 Jan 2026 23:43:07 GMT, Serguei Spitsyn wrote: >> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: minor comment tweak in a comment; use test lib function set_event_notification_mode Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28740#pullrequestreview-3689851937 From sspitsyn at openjdk.org Wed Jan 21 23:46:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 23:46:45 GMT Subject: RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v15] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 21:33:30 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: restored the original assert with a different message > > src/hotspot/share/runtime/handshake.cpp line 525: > >> 523: #if INCLUDE_JVMTI >> 524: if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { >> 525: // filter out suspend operations while JavaThread is in disable_suspend mode > > does it makes sense to update comment to > // filter out suspend operations while JavaThread is in disable_suspend mode or in transition > or something more generic > // check if JavaThread can be suspended in this handshake Thanks. How about more generic? : @@ -522,7 +522,7 @@ HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool che assert(allow_suspend || !check_async_exception, "invalid case"); #if INCLUDE_JVMTI if (allow_suspend && (_handshakee->is_disable_suspend() || _handshakee->is_vthread_transition_disabler())) { - // filter out suspend operations while JavaThread is in disable_suspend mode + // filter out suspend operations while JavaThread can not be suspended allow_suspend = false; } #endif > test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp line 63: > >> 61: JNIEXPORT void JNICALL >> 62: Java_ThreadStateTest2_setMonitorContendedMode(JNIEnv* jni, jclass klass, jboolean enable) { >> 63: jvmtiError err = jvmti->SetEventNotificationMode(enable ? JVMTI_ENABLE : JVMTI_DISABLE, JVMTI_EVENT_MONITOR_CONTENDED_ENTER, nullptr); > > You can use > set_event_notification_mode(jvmtiEnv*, ... ) > from jvmti_common.h Thanks, fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714723247 PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2714723634 From dholmes at openjdk.org Thu Jan 22 01:51:17 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 01:51:17 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Wed, 21 Jan 2026 16:51:17 GMT, Ivan Bereziuk wrote: > Q: what would be best name for the flag. Currently it's "-T". Should we use a different name? Lowercase `-t` seems more consistent with other options ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3782041944 From sspitsyn at openjdk.org Thu Jan 22 01:57:08 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Jan 2026 01:57:08 GMT Subject: Integrated: 8373366: HandshakeState should disallow suspend ops for disabler threads In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:18:11 GMT, Serguei Spitsyn wrote: > An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) can be installed when the target thread is not in a `MountUnmountDisabler` scope. But the target thread can enter such scope by the time the operation is self-processed by the target thread. > > This is fixed by a small tweak in the function > `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool check_async_exception)`. > The tweak is to skip a `HandshakeOperation` if `_handshakee->is_vthread_transition_disabler() == true`, so the same temporary suspension disabling mechanism would be used as for `_handshakee->is_disable_suspend() == true`. > > All other changes are to move the `is_vthread_transition_disabler()` out of DEBUG to product. > > Testing: > - In progress: mach5 tiers 1-6 This pull request has now been integrated. Changeset: 3d919ad4 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/3d919ad43a041eb60ce51e78831c77fd3b109aee Stats: 290 lines in 7 files changed: 270 ins; 4 del; 16 mod 8373366: HandshakeState should disallow suspend ops for disabler threads 8375362: Deadlock with unmount of suspended virtual thread interrupting another virtual thread Reviewed-by: lmesnik, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/28740 From dholmes at openjdk.org Thu Jan 22 02:30:02 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 02:30:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. There are still issues with `was_notified` and I don't think the possibility of the event enabling changing has been fully handled. src/hotspot/share/runtime/objectMonitor.cpp line 1907: > 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. > 1906: // That is, we fail toward safety. > 1907: was_notified = true; You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" src/hotspot/share/runtime/objectMonitor.cpp line 2066: > 2064: } > 2065: } else { > 2066: if (!JvmtiExport::should_post_monitor_waited()) { What if this has changed value since we checked it above? ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3690267548 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715060072 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715066067 From dholmes at openjdk.org Thu Jan 22 02:40:59 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 02:40:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> On Thu, 22 Jan 2026 02:21:11 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1907: > >> 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. >> 1906: // That is, we fail toward safety. >> 1907: was_notified = true; > > You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" This should be: was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; and no need to adjust to false below (as it will already be false). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715087288 From pchilanomate at openjdk.org Thu Jan 22 03:38:40 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 03:38:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 02:37:41 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1907: >> >>> 1905: // then we'll acquire the lock and then re-fetch a fresh TState value. >>> 1906: // That is, we fail toward safety. >>> 1907: was_notified = true; >> >> You can't just go back to this as it is wrong. Your are now marking an initial interrupt case as "was_notified" > > This should be: > > was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; > > and no need to adjust to false below (as it will already be false). Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715178509 From iklam at openjdk.org Thu Jan 22 04:13:50 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 22 Jan 2026 04:13:50 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive Message-ID: In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. (I also added missing copyright header to a problem list file used by CDS/AOT testing). ------------- Commit messages: - 8375654: Exclude all array classes from dynamic CDS archive Changes: https://git.openjdk.org/jdk/pull/29356/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29356&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375654 Stats: 108 lines in 3 files changed: 107 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29356/head:pull/29356 PR: https://git.openjdk.org/jdk/pull/29356 From dholmes at openjdk.org Thu Jan 22 04:22:36 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:22:36 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1916: > 1914: } > 1915: } > 1916: // The thread is now either on off-list (TS_RUN), Suggestion: // The thread is now either off-list (TS_RUN), Pre-existing typo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715241999 From dholmes at openjdk.org Thu Jan 22 04:36:58 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:36:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1933: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > 1932: // An event could have been enabled after notification, need to check the state. > 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: if (JvmtiExport::should_post_monitor_waited()) { if (node.TState != ObjectWaiter::TS_ENTER) { // Process suspend requests now if any, before posting the event. ThreadBlockInVM tbvm(current, true); } JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715266992 From dholmes at openjdk.org Thu Jan 22 04:56:10 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:56:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 03:35:10 GMT, Patricio Chilano Mateo wrote: >> This should be: >> >> was_notified = node.TState == ObjectWaiter::TS_RUN || node.TState == ObjectWaiter::TS_ENTER; >> >> and no need to adjust to false below (as it will already be false). > > Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715292501 From dholmes at openjdk.org Thu Jan 22 04:56:10 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 04:56:10 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 04:50:05 GMT, David Holmes wrote: >> Note that if the thread was interrupted the state will be `TS_WAIT` here, so `was_notified ` will be set to false. If the thread was interrupted and notified we consider it a notification case (even if the unpark was due to the interrupt). > > Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. Though it would be clearer to just have: 1869 bool was_notified = true; and delete line 1907. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715297305 From dholmes at openjdk.org Thu Jan 22 05:02:02 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:02:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 04:34:05 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1933: > >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >> 1932: // An event could have been enabled after notification, need to check the state. >> 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > > I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: > > if (JvmtiExport::should_post_monitor_waited()) { > if (node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event. > ThreadBlockInVM tbvm(current, true); > } > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715307376 From dholmes at openjdk.org Thu Jan 22 05:21:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:21:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 02:24:39 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 2066: > >> 2064: } >> 2065: } else { >> 2066: if (!JvmtiExport::should_post_monitor_waited()) { > > What if this has changed value since we checked it above? Sorry ignore that - got the block structure wrong again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715338855 From dholmes at openjdk.org Thu Jan 22 05:37:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Jan 2026 05:37:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 13:26:33 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewers' comments. src/hotspot/share/runtime/objectMonitor.cpp line 1931: > 1929: // (Don't cache naked oops over safepoints, of course). > 1930: > 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. Pre-existing but I just noticed this. We should only be posting events in the "interruptible" case. Refer above: 1824 if (interruptible && JvmtiExport::should_post_monitor_wait()) { 1825 JvmtiExport::post_monitor_wait(current, object(), millis); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715368280 From sspitsyn at openjdk.org Thu Jan 22 09:14:07 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Jan 2026 09:14:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 04:52:53 GMT, David Holmes wrote: >> Thanks @pchilano . Apologies @toxaart the diff view confused me and I got things muddled up with when we accidently gave interrupt priority over notification. > > Though it would be clearer to just have: > > 1869 bool was_notified = true; > > and delete line 1907. Wanted to suggest the same. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2715989355 From cnorrbin at openjdk.org Thu Jan 22 09:48:43 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 22 Jan 2026 09:48:43 GMT Subject: RFR: 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 13:14:22 GMT, Casper Norrbin wrote: > Hi everyone, > > When printing VM container info with trace container logging enabled, it is possible for the output to become interleaved. This can cause `TestMemoryAwareness.java` to fail, since the string it expects may be split by trace output appearing in the middle of the VM.info line. > > In #28766, I added improved VM.info formatting with the `OSContainer::print_container_metric` function, but it still performed printing in 2 steps, making it possible for that output to be split. With this PR, I have changed this so we construct the full line with `snprintf` before printing, ensuring the whole line is printed in a single step. This prevents other output from splitting the line, so the test can reliably detect the expected values. > > Since the test now works as expected, I have also removed it from the problemlist. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1/v2 with both podman and docker > - Repeated runs of `TestMemoryAwareness.java` without any observed failures Thank you both for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29319#issuecomment-3783464187 From cnorrbin at openjdk.org Thu Jan 22 09:48:44 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 22 Jan 2026 09:48:44 GMT Subject: Integrated: 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" In-Reply-To: References: Message-ID: <_7fNvu9wGH9e-f4O_YCScDEa52svYP51ALZPlNt0MF4=.e62c41ed-a9e0-447c-aace-855b947a0bac@github.com> On Tue, 20 Jan 2026 13:14:22 GMT, Casper Norrbin wrote: > Hi everyone, > > When printing VM container info with trace container logging enabled, it is possible for the output to become interleaved. This can cause `TestMemoryAwareness.java` to fail, since the string it expects may be split by trace output appearing in the middle of the VM.info line. > > In #28766, I added improved VM.info formatting with the `OSContainer::print_container_metric` function, but it still performed printing in 2 steps, making it possible for that output to be split. With this PR, I have changed this so we construct the full line with `snprintf` before printing, ensuring the whole line is printed in a single step. This prevents other output from splitting the line, so the test can reliably detect the expected values. > > Since the test now works as expected, I have also removed it from the problemlist. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1/v2 with both podman and docker > - Repeated runs of `TestMemoryAwareness.java` without any observed failures This pull request has now been integrated. Changeset: ddbd4617 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/ddbd4617a6172e3054b2afade4f304f66c79816e Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod 8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr" Reviewed-by: sgehwolf, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/29319 From aartemov at openjdk.org Thu Jan 22 10:44:08 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:08 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v28] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/20a81450..72b583ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=26-27 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 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 aartemov at openjdk.org Thu Jan 22 10:44:09 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:09 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <60VG1ir0B-NHg6u78our8KgJvA5n4ntG9_32lRtHrJo=.f479edcb-0bbc-4076-95c0-c1344a80a1bf@github.com> Message-ID: On Thu, 22 Jan 2026 09:10:50 GMT, Serguei Spitsyn wrote: >> Though it would be clearer to just have: >> >> 1869 bool was_notified = true; >> >> and delete line 1907. > > Wanted to suggest the same. :) Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314580 From aartemov at openjdk.org Thu Jan 22 10:44:13 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:13 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> <8_u0_gO6D4LV9zpkWOryqcsM4CAjkXwmUEcQcLeXotQ=.cd2116c0-8f22-4e9b-81c1-05db6ae1fff7@github.com> Message-ID: On Thu, 22 Jan 2026 04:19:16 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.cpp line 1916: > >> 1914: } >> 1915: } >> 1916: // The thread is now either on off-list (TS_RUN), > > Suggestion: > > // The thread is now either off-list (TS_RUN), > > Pre-existing typo Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 1931: > >> 1929: // (Don't cache naked oops over safepoints, of course). >> 1930: >> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. > > Pre-existing but I just noticed this. We should only be posting events in the "interruptible" case. Refer above: > > 1824 if (interruptible && JvmtiExport::should_post_monitor_wait()) { > 1825 JvmtiExport::post_monitor_wait(current, object(), millis); Added as an extra condition, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314378 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716312228 From aartemov at openjdk.org Thu Jan 22 10:44:16 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:44:16 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 04:59:04 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1933: >> >>> 1931: // Post monitor waited event. Note that this is past-tense, we are done waiting. >>> 1932: // An event could have been enabled after notification, need to check the state. >>> 1933: if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { >> >> I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be: >> >> if (JvmtiExport::should_post_monitor_waited()) { >> if (node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> ThreadBlockInVM tbvm(current, true); >> } >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. I added the changes you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716314002 From aartemov at openjdk.org Thu Jan 22 11:00:02 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 11:00:02 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Wed, 21 Jan 2026 20:36:32 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewers' comments. > > src/hotspot/share/runtime/objectMonitor.hpp line 42: > >> 40: class BasicLock; >> 41: class ContinuationWrapper; >> 42: class EventJavaMonitorWait; > > Nit: leftover Removed, thanks for spotting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2716392207 From aartemov at openjdk.org Thu Jan 22 10:59:59 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 10:59:59 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v29] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/72b583ab..3dff4f17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=27-28 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 aartemov at openjdk.org Thu Jan 22 11:08:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 22 Jan 2026 11:08:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v30] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Fixed whitespaces. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/3dff4f17..eb5afa25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=28-29 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org Thu Jan 22 11:11:04 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 22 Jan 2026 11:11:04 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: Message-ID: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: change flag name from -T to -t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/c702901d..f0e39a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=02-03 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From duke at openjdk.org Thu Jan 22 11:28:29 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 22 Jan 2026 11:28:29 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": > > jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename > ^^^^ > > > This is a simplified approach to handle timestamp (v1 is [here](https://github.com/openjdk/jdk/pull/27368)) > > Some diagnostic commands already provide timestamps information. For example `Thread.print` already starts with a timestamp of "yyyy-MM-dd HH:mm:ss" format. > In that case the timestamp is printed twice if "-t" flag is passed to `Thread.print`. > > The time format for the generic timestamp is ISO 8601. Example: `2026-01-21T16:58:49.518+0100` Ivan Bereziuk has updated the pull request incrementally with three additional commits since the last revision: - change timestamp format to ISO 8601 - lowercase flag - improve test. Assert new ISO 8601 format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29325/files - new: https://git.openjdk.org/jdk/pull/29325/files/eaea764d..1047677b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=00-01 Stats: 21 lines in 6 files changed: 1 ins; 5 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29325/head:pull/29325 PR: https://git.openjdk.org/jdk/pull/29325 From kevinw at openjdk.org Thu Jan 22 12:36:02 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 22 Jan 2026 12:36:02 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t I am liking the much simpler alternative. I think you did a lot of exploratory work here, but there is a lot of complexity needed just because Thread.print already prints a timestamp. I do not find this ugly or unparseable: $ jcmd -t 2970459 Thread.print 2970459: 2026-01-22T12:05:50.518+0100 2026-01-22 12:05:55 Full thread dump Java HotSpot(TM) 64-Bit Server VM (27-internal-kwalls.open mixed mode, sharing) JDK version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-kwalls.open) Threads class SMR info: ... It would not seem right to add the common flags infrastructure in dcmd framework just in case it's useful in future, just add what we need right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3784154369 From sgehwolf at openjdk.org Thu Jan 22 13:30:58 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:30:58 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into jdk-8375692-container-test-assert - Restore Bellsoft copyright - Update copyright year - 8375692: Hotspot container tests assert with non-ascii vendor name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/e539a64f..dbe943dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02-03 Stats: 14011 lines in 386 files changed: 8639 ins; 2067 del; 3305 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Thu Jan 22 13:31:01 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:31:01 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Wed, 21 Jan 2026 10:05:30 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Restore Bellsoft copyright @dholmes-ora Any more thoughts on this? OK as it is? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3784411173 From kvn at openjdk.org Thu Jan 22 17:22:05 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 22 Jan 2026 17:22:05 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: References: Message-ID: <4JJOIZzKkYiNkP3o_D3ZtL5mlXl4GC--w65rKk67AFQ=.d3714f4f-21f4-4724-92a5-7c2a41bfe2db@github.com> On Thu, 22 Jan 2026 02:49:17 GMT, Ioi Lam wrote: > In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. > > This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. > > Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. > > (I also added missing copyright header to a problem list file used by CDS/AOT testing). Will this affect Leyden? In AOT code generation we store number of dimensions and Klass: https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L2399-L2402 When we load AOT code we assume that such array already exist - we use `k->array_klass_or_null(array_dim)`: https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L2475-L2480 There is comment there to create the array instead of just lookup. Should,d we use commented code after these changes? ------------- PR Review: https://git.openjdk.org/jdk/pull/29356#pullrequestreview-3693629826 From iklam at openjdk.org Thu Jan 22 17:31:32 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 22 Jan 2026 17:31:32 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: <4JJOIZzKkYiNkP3o_D3ZtL5mlXl4GC--w65rKk67AFQ=.d3714f4f-21f4-4724-92a5-7c2a41bfe2db@github.com> References: <4JJOIZzKkYiNkP3o_D3ZtL5mlXl4GC--w65rKk67AFQ=.d3714f4f-21f4-4724-92a5-7c2a41bfe2db@github.com> Message-ID: <0StzuUp8CpeC7gGJK0zqXAQJO-BpZk6wLId5oFXRh1o=.77206e39-1f06-49af-bc56-f03c3cfa2e32@github.com> On Thu, 22 Jan 2026 17:19:22 GMT, Vladimir Kozlov wrote: > Will this affect Leyden? In AOT code generation we store number of dimensions and Klass: https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L2399-L2402 > > When we load AOT code we assume that such array already exist - we use `k->array_klass_or_null(array_dim)`: https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L2475-L2480 > > There is comment there to create the array instead of just lookup. Should,d we use commented code after these changes? This PR doesn't affect Leyden. The exclusion happens only for the dynamic archive. The AOT cache (which is the same as a static CDS archive) includes array classes so they can be referenced by AOT compiled Java methods. We don't plan to support AOT compiled methods for the dynamic archive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29356#issuecomment-3785691478 From kvn at openjdk.org Thu Jan 22 17:44:37 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 22 Jan 2026 17:44:37 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: References: Message-ID: <4sUYq3IHhCjAn_4vRgAIv9MU2KwUckGDCuRgpWyrZgw=.2732a0ff-86ff-475d-87ef-0a7eab2a920d@github.com> On Thu, 22 Jan 2026 02:49:17 GMT, Ioi Lam wrote: > In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. > > This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. > > Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. > > (I also added missing copyright header to a problem list file used by CDS/AOT testing). Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29356#pullrequestreview-3693740553 From pchilanomate at openjdk.org Thu Jan 22 18:38:48 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 18:38:48 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 10:39:23 GMT, Anton Artemov wrote: >> Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended. > > Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. > > I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. > > I added the changes you suggested. My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2718123607 From vlivanov at openjdk.org Thu Jan 22 18:58:27 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 22 Jan 2026 18:58:27 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 02:49:17 GMT, Ioi Lam wrote: > In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. > > This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. > > Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. > > (I also added missing copyright header to a problem list file used by CDS/AOT testing). Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29356#pullrequestreview-3694026950 From dholmes at openjdk.org Fri Jan 23 05:15:56 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Jan 2026 05:15:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo wrote: >> Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. >> >> I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. >> >> I added the changes you suggested. > > My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. Patricio is right as usual. I was thinking that the check for enabled-after-notification was to ensure we always posted the event, but really it is to ensure that if we post the event, we only do it if it had been enabled before notification. Sorry for the to-and-fro Anton. Reasoning about this is tricky. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2719636203 From iklam at openjdk.org Fri Jan 23 06:28:16 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 Jan 2026 06:28:16 GMT Subject: RFR: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: <4sUYq3IHhCjAn_4vRgAIv9MU2KwUckGDCuRgpWyrZgw=.2732a0ff-86ff-475d-87ef-0a7eab2a920d@github.com> References: <4sUYq3IHhCjAn_4vRgAIv9MU2KwUckGDCuRgpWyrZgw=.2732a0ff-86ff-475d-87ef-0a7eab2a920d@github.com> Message-ID: <0AGs4VfJ8Ipe7F2vI2fHI1k_jNV-8iBme_6hKhRrrSM=.23e12f86-4570-43cd-96b8-61a6a44058bb@github.com> On Thu, 22 Jan 2026 17:41:17 GMT, Vladimir Kozlov wrote: >> In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. >> >> This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. >> >> Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. >> >> (I also added missing copyright header to a problem list file used by CDS/AOT testing). > > Good. Thanks @vnkozlov and @iwanowww for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29356#issuecomment-3788518839 From iklam at openjdk.org Fri Jan 23 06:28:18 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 Jan 2026 06:28:18 GMT Subject: Integrated: 8375654: Exclude all array classes from dynamic CDS archive In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 02:49:17 GMT, Ioi Lam wrote: > In `A` is a subtype of `B`, it's possible for an `ObjArrayKlass` for `A[]` to be archived in the dynamic CDS archive and its `_secondary_supers` contains a pointer to an `ObjArrayKlass` for `B[]` that's also archived in the dynamic archive. > > This scenario used to be supported, but since [JDK-8374639](https://bugs.openjdk.org/browse/JDK-8374639), if `B` is archived in the static CDS archive, at runtime a different `B[]` is created dynamically. As a result, we can no longer typecast an instance of `A[]` into an instance of `B[]`. > > Since `ObjArrayKlasses` are cheap to allocate at runtime, the easiest fix is to simply not store any `ObjArrayKlass` in the dynamic CDS archive. > > (I also added missing copyright header to a problem list file used by CDS/AOT testing). This pull request has now been integrated. Changeset: 7f2aa59f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/7f2aa59f8220f302a3f8662eeca3291dcf86d2ad Stats: 108 lines in 3 files changed: 107 ins; 0 del; 1 mod 8375654: Exclude all array classes from dynamic CDS archive Reviewed-by: kvn, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/29356 From dholmes at openjdk.org Fri Jan 23 06:33:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Jan 2026 06:33:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name I was hoping one of our container experts would jump in, but this seems okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3695895003 From stuefe at openjdk.org Fri Jan 23 07:04:44 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Jan 2026 07:04:44 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Just piling on, sorry for bikeshedding... > OK thanks, yes not changing all the dcmds in https://github.com/openjdk/jdk/pull/29325/files is nice. 8-) > > Regarding whether JCmd.java could do the timestamp, or we need to change the native side: Yes a problem there is the timestamp duplication issue: if JCmd can optionally print a timestamp as a header before running the command, that timestamp info is duplicated in Thread.print. > > But is it really that bad, and is it worth the extra argument processing? (In diagnosticFramework, we need to introduce parse_common options just for this one flag.) I agree. > > If JCmd.java does the timestamp: if you opt-in to JCmd with a timestamp, you would get the new timestamp in the new format, followed by the old Thread.print timestamp in its format... This avoids the new complexity in the native code, and keeps the new timestamp handling in the simple JCmd.java wrapper. It sidesteps the problem that Thread.print uses an arguably "wrong" format. (An in time, maybe Thread.print would migrate to not printing a timestamp.) I would prefer if the hotspot did write the timestamp, because 1) The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) 2) adding it to the hotspot will automatically work for every version of jcmd (e.g., I usually just call "jcmd" and use whatever jcmd tool happens to be on the path on that particular machine, but no guarantee it comes from the target VM) > > (JCmd could optionally print a duration at the end as was hinted somewhere earlier. Heap dumping prints its own time taken, but few other commands consider it interesting.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3788641543 From aartemov at openjdk.org Fri Jan 23 09:05:58 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 23 Jan 2026 09:05:58 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > 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 56 commits: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Changed condition on when to post an event. - 8366659: Fixed whitespaces. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewers' comments. - 8366659: Fixed whitespace. - 8366659: Addressed reviewer's comments. - 8366659: Addressed reviewers' comments, added comments, renamed tests. - 8366659: Modified the comment. - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad ------------- Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=30 Stats: 1372 lines in 9 files changed: 889 ins; 444 del; 39 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 aartemov at openjdk.org Fri Jan 23 09:06:00 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 23 Jan 2026 09:06:00 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v27] In-Reply-To: References: <9Dj_fGvTxaQ4wvC8VOhREO3L2ks_aNgQ-QusH7U6kBM=.7c73a5a8-b7bf-46f0-9585-e4d197db1212@github.com> Message-ID: On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo wrote: >> Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do. >> >> I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point. >> >> I added the changes you suggested. > > My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. Thanks @pchilano, I was not aware of that property of agents. With that in mind, it makes sense to check the state in the condition. Modified the code accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2720303739 From sgehwolf at openjdk.org Fri Jan 23 09:37:34 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Failing GHA checks are infra related. `git clone` returned `500`... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789300277 From sgehwolf at openjdk.org Fri Jan 23 09:37:37 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:37 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 22:40:12 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > LGTM from i18n point of view. Probably needs more reviews from hotspot side @naotoj Could you please ack this again? The same change, just the bellsoft copyright left untouched. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789304289 From kevinw at openjdk.org Fri Jan 23 11:14:20 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 23 Jan 2026 11:14:20 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Thanks Thomas yes it's kind of bikeshedding, but worth talking about hopefully. 8-) Glad you agree with the simplicity part. But you like the timestamp coming from the JVM: > The time may run differently on the jcmd side (e.g. target runs on a container on Windows or MacOS, or if we ever add remote capabilities to jcmd) We don't want to do anything which prohibits possible future features, but also don't want to be constrained by what might possibly happen. 8-) So you're on the same hardware, running jcmd that may contact a container. jcmd logs the time. Is the time in the container that different? The new info contains the TZ/offset I think. We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. > adding it to the hotspot will automatically work for every version of jcmd Yes, this works both ways. The new jcmd will give timestamps when talking to older VMs. You can opt-in to new behaviour by choosing a later jcmd, without a JDK update in the app. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3789758234 From fbredberg at openjdk.org Fri Jan 23 13:09:38 2026 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 23 Jan 2026 13:09:38 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation Message-ID: Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. Tests are running okay tier1-7 on supported platforms. The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` ------------- Commit messages: - 8373595: A new ObjectMonitorTable implementation Changes: https://git.openjdk.org/jdk/pull/29383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373595 Stats: 930 lines in 38 files changed: 533 ins; 126 del; 271 mod Patch: https://git.openjdk.org/jdk/pull/29383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29383/head:pull/29383 PR: https://git.openjdk.org/jdk/pull/29383 From naoto at openjdk.org Fri Jan 23 13:20:02 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jan 2026 13:20:02 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Looks fine. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3697432626 From fbredberg at openjdk.org Fri Jan 23 13:54:40 2026 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 23 Jan 2026 13:54:40 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` @TheRealMDoerr, @RealFYang, @offamitkumar Hi guys! So here we have a new Object Monitor Table implementation. As stated above I've smoke tested `ppc`, `riscv` and `s390` using QEMU. However I haven't been able to run proper performance tests on "your" platforms, but all the assembler stuff is follows the same scheme as x86 and aarch64, which I have run performance tests on, so hopefully it's good on all platforms. Anyhow, please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29383#issuecomment-3790328499 From duke at openjdk.org Fri Jan 23 15:02:09 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 15:02:09 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Thu, 22 Jan 2026 11:11:04 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": >> >> jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) >> * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > change flag name from -T to -t Kevin, Thomas, thank you very much for comments. Indeed. The way `jcmd` is implemented currently and in older JDKs, the tool does not question arguments following PID. One more thing to keep in mind. The is a use case with a chain of commands passed to `jcmd`. With this MR we can timestamp per command: $ cat input.txt -t VM.version -t VM.version $ jcmd -f input.txt 51721: 2026-01-23T14:58:28.515+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 2026-01-23T14:58:28.518+0100 Java HotSpot(TM) 64-Bit Server VM version 27-internal-john24.open JDK 27.0.0 The timestamping implemented in `JCmd.java` would print timestamp only once at the beginning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3790630542 From duke at openjdk.org Fri Jan 23 16:26:57 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 23 Jan 2026 16:26:57 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v5] In-Reply-To: References: Message-ID: > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-t": > > jcmd [pid | main-class] [-t] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is ISO 8601 `yyyy-MM-dd'T'HH:mm:ss.SSSZ` (example `2026-01-21T16:58:49.518+0100`) > * if "-t" flag is not passed, `Thread.print` keeps printing "yyyy-MM-dd HH:mm:ss" timestamp to preserve backwards compatibility. Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: tweaked help working for -t flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/f0e39a34..7371f3c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From jvernee at openjdk.org Fri Jan 23 16:44:05 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 16:44:05 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3698507443 From sgehwolf at openjdk.org Fri Jan 23 16:55:22 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:55:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3791233146 From sgehwolf at openjdk.org Fri Jan 23 16:58:50 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:58:50 GMT Subject: Integrated: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. This pull request has now been integrated. Changeset: 3fb118a2 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3fb118a29ed68f2fbb64de45468b0f014fa01890 Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod 8375692: Hotspot container tests assert with non-ascii vendor name Reviewed-by: naoto, dholmes, syan ------------- PR: https://git.openjdk.org/jdk/pull/29315 From bulasevich at openjdk.org Fri Jan 23 17:14:30 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 23 Jan 2026 17:14:30 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable In-Reply-To: References: Message-ID: <3MuR2PIDKO4bpebkf3qYo8zSIRUhhOCU437A3PJrmt8=.2823a684-5c6e-49e5-87a2-431b5f0ab32a@github.com> On Wed, 14 Jan 2026 06:18:55 GMT, Ioi Lam 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. > > I agree with David's earlier comment. We must limit the amount of system integrity checks. Otherwise, we would need to propagate the failure. So what do we do with this function that calls `ClassLoader::get_jrt_entry()`: > > https://github.com/openjdk/jdk/blob/b082a390b77fca7134000bfe631f73bfd082bfa1/src/hotspot/share/cds/aotClassLocation.cpp#L453-L458 > > Do we need to change it to return a boolean to indicate some sort of failure, or do we need to throw a HotSpot exception? In either way, the callers of this function will be affected and soon every function will need to return a boolean or be declared TRAPS. > > In HotSpot, we do the system integrity checks early and exit the VM on failures. For example, we already exit the VM if the modules file is removed from `JAVA_HOME`: > > > $ cd images/jdk/lib > $ mv modules modules.old > $ ../bin/java > Error occurred during initialization of VM > Failed setting boot class path. > > > The same should be done if the modules file is expected to exist but cannot be opened: > > > --- a/src/hotspot/share/classfile/classLoader.cpp > +++ b/src/hotspot/share/classfile/classLoader.cpp > @@ -1418,6 +1418,10 @@ char* ClassLoader::lookup_vm_options() { > jio_snprintf(modules_path, JVM_MAXPATHLEN, "%s%slib%smodules", Arguments::get_java_home(), fileSep, fileSep); > JImage_file =(*JImageOpen)(modules_path, &error); > if (JImage_file == nullptr) { > + if (Arguments::has_jimage()) { > + // The modules file exists but is unreadable or corrupt > + vm_exit_during_initialization(err_msg("Unable to load %s", modules_path)); > + } > return nullptr; > } @iklam Right. Correct failure propagation here is harder than a simple null check, so an early check and fail-fast behavior seems preferable. Thanks for the suggestion. I tested it locally and it works well. I?m going to update the PR accordingly. Do you think it makes sense to add a jtreg regression test to cover lib/modules missing or unreadable cases, or is that unnecessary here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3791328595 From bulasevich at openjdk.org Fri Jan 23 17:21:48 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 23 Jan 2026 17:21:48 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable [v2] In-Reply-To: References: Message-ID: > The JVM crashes with a SIGSEGV during startup if the runtime image (lib/modules) exists but is unreadable. In this scenario, ClassLoader::get_jrt_entry() returns nullptr, leading to a crash. This change adds a null check to avoid the dereference and bail out gracefully. Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: Move runtime image check to early VM init Suggested-by: Ioi Lam ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28982/files - new: https://git.openjdk.org/jdk/pull/28982/files/f3da8c82..8152b3b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28982&range=00-01 Stats: 10 lines in 2 files changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28982/head:pull/28982 PR: https://git.openjdk.org/jdk/pull/28982 From dcubed at openjdk.org Fri Jan 23 20:13:03 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Jan 2026 20:13:03 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:05:58 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 56 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Changed condition on when to post an event. > - 8366659: Fixed whitespaces. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments. > - 8366659: Fixed whitespace. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments, added comments, renamed tests. > - 8366659: Modified the comment. > - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad I last reviewed v25 and I tried to use the "Changes since you last reviewed" link, but I couldn't make sense of what I was seeing in the comparison from v25 -> v30. I'm gonna have to go back and do another crawl thru review here. Is it just me or has this patch (not counting the test refactoring) gotten really big? I realize that what we're trying to fix here is extremely complicated hence the size of the corrections. The bigger the patch, the harder it is to backport, but I don't know if we have any plans to backport this at all. Also, I don't see a root cause analysis in the bug report so we don't know how far back this issue goes. I suppose we could morph the new tests into something standalone that doesn't depend on anything in the current test suites and then work our way backward thru the LTS releases to see how far back this goes... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3792172270 From jrose at openjdk.org Fri Jan 23 21:49:50 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 21:49:50 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Good work. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3699825444 From dcubed at openjdk.org Fri Jan 23 22:12:39 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Jan 2026 22:12:39 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: Message-ID: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> On Fri, 23 Jan 2026 09:05:58 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> 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 56 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock > - 8366659: Changed condition on when to post an event. > - 8366659: Fixed whitespaces. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments. > - 8366659: Fixed whitespace. > - 8366659: Addressed reviewer's comments. > - 8366659: Addressed reviewers' comments, added comments, renamed tests. > - 8366659: Modified the comment. > - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad I've made two complete read-thrus today. Just a couple comments about the changes as they are in v30. src/hotspot/share/runtime/objectMonitor.cpp line 1942: > 1940: } > 1941: > 1942: JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); OK so this effectively polls and handles a pending suspend request. That does not guarantee that another suspend request won't be pending again (and handled in the `JvmtiExport::post_monitor_waited()` call). src/hotspot/share/runtime/objectMonitor.cpp line 2099: > 2097: // move the add-to-entry_list operation, above, outside the critical section > 2098: // protected by _wait_set_lock. In practice that's not useful. With the > 2099: // exception of wait() timeouts and interrupts the monitor owner nit: extra space before wait. src/hotspot/share/runtime/objectMonitor.cpp line 2242: > 2240: // once we re-acquire the monitor we know if we need to throw IE or not. > 2241: ObjectWaiter::TStates state = node->TState; > 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, ""); assert with multiple conditions should output the values so we know exactly what condition failed. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3699805855 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722940869 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722949992 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2722983763 From iklam at openjdk.org Sat Jan 24 03:55:57 2026 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 24 Jan 2026 03:55:57 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable [v2] In-Reply-To: References: Message-ID: <1RSo_DMPzGUdellDSiOL5OqVLboyATvGinXutTvRSBw=.0c96991a-f696-41df-be34-0a189b42378d@github.com> On Fri, 23 Jan 2026 17:21:48 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. > > Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: > > Move runtime image check to early VM init > > Suggested-by: Ioi Lam LGTM. I think it's not necessary to include a test case. We generally don't test for corruption of the JDK installation itself. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28982#pullrequestreview-3700569688 From jiefu at openjdk.org Mon Jan 26 08:45:10 2026 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 26 Jan 2026 08:45:10 GMT Subject: [jdk26] RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 Message-ID: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> Hi all, This pull request contains a backport of commit [9715e6da](https://github.com/openjdk/jdk/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jie Fu on 22 Dec 2025 and was reviewed by Kim Barrett and David Holmes. Thanks! ------------- Commit messages: - Backport 9715e6da8355a103d9066bd15ce68b4773cbadcb Changes: https://git.openjdk.org/jdk/pull/29406/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374178 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29406/head:pull/29406 PR: https://git.openjdk.org/jdk/pull/29406 From mbaesken at openjdk.org Mon Jan 26 09:31:26 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 26 Jan 2026 09:31:26 GMT Subject: RFR: 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code Message-ID: There are a few usages of USE_XLC_BUILTINS left in the AIX hotspot coding. But they are obsolete these days. Most were removed already but the few remaining can be removed too. ------------- Commit messages: - JDK-8376281 Changes: https://git.openjdk.org/jdk/pull/29408/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376281 Stats: 15 lines in 2 files changed: 0 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29408.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29408/head:pull/29408 PR: https://git.openjdk.org/jdk/pull/29408 From mdoerr at openjdk.org Mon Jan 26 09:40:05 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 26 Jan 2026 09:40:05 GMT Subject: RFR: 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:23:33 GMT, Matthias Baesken wrote: > There are a few usages of USE_XLC_BUILTINS left in the AIX hotspot coding. But they are obsolete these days. Most were removed already but the few remaining can be removed too. Looks good and trivial. Thanks for cleaning this up! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29408#pullrequestreview-3705259325 From angelorubini at hotmail.it Mon Jan 26 10:56:44 2026 From: angelorubini at hotmail.it (Angelo Rubini) Date: Mon, 26 Jan 2026 10:56:44 +0000 Subject: Temurin JRE 25 ARM64 fails to start on Nanos unikernel, IBM Semeru JRE 25 works well Message-ID: Hi everyone, following Martijn Verburg's suggestion, I'm posting the open issue here, where you can find all the details. In short, the OpenJDK 25 JVM for Arm 64 doesn't launch on Nanos Unikernel, while the same version of JVM 25 with the Semeru runtime launches without errors. https://github.com/adoptium/adoptium-support/issues/1397 If you need further details, let me know. Regards Angelo Rubini -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Mon Jan 26 11:18:59 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Jan 2026 11:18:59 GMT Subject: [jdk26] RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> References: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> Message-ID: On Mon, 26 Jan 2026 08:35:02 GMT, Jie Fu wrote: > Hi all, > > This pull request contains a backport of commit [9715e6da](https://github.com/openjdk/jdk/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jie Fu on 22 Dec 2025 and was reviewed by Kim Barrett and David Holmes. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29406#pullrequestreview-3705595322 From azafari at openjdk.org Mon Jan 26 12:19:40 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 26 Jan 2026 12:19:40 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: <1ZRPt2rS8Cb3n1f9mYgx333wOvag2VA80PrCt-6zSP8=.5c62a3de-e2c8-4ea4-9012-3ee71fbd0713@github.com> 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 Thank you Sendao for taking this fix. Just a comment on the Copyright text and year. There should be an Oracle line in the Copyright with 2026. ------------- PR Review: https://git.openjdk.org/jdk/pull/28975#pullrequestreview-3705775879 From cnorrbin at openjdk.org Mon Jan 26 12:23:57 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 26 Jan 2026 12:23:57 GMT Subject: RFR: 8376302: os::Machine::used_memory reports container used memory when running containerized Message-ID: Hi everyone, In #27646, I introduced interfaces to get machine and container values separately when running inside a container. For `os::used_memory`, I initially moved the container check out of the function, and the remainder became `os::Machine::used_memory`. However, this function was still calling the "normal" `os::` functions, which resulted in the container check being performed again. This was incorrect. I have now updated these calls to use the appropriate `os::Machine::` functions, which do not re-check for containerization. The behaviour of `os::used_memory` itself remains unchanged, as it does the container check before delegating to the `Machine` function. Testing: - Oracle tier 1 - Manual testing to see that the value works correctly ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/29413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376302 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29413/head:pull/29413 PR: https://git.openjdk.org/jdk/pull/29413 From eosterlund at openjdk.org Mon Jan 26 13:02:47 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 26 Jan 2026 13:02:47 GMT Subject: RFR: 8376302: os::Machine::used_memory reports container used memory when running containerized In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:16:19 GMT, Casper Norrbin wrote: > Hi everyone, > > In #27646, I introduced interfaces to get machine and container values separately when running inside a container. For `os::used_memory`, I initially moved the container check out of the function, and the remainder became `os::Machine::used_memory`. However, this function was still calling the "normal" `os::` functions, which resulted in the container check being performed again. This was incorrect. I have now updated these calls to use the appropriate `os::Machine::` functions, which do not re-check for containerization. The behaviour of `os::used_memory` itself remains unchanged, as it does the container check before delegating to the `Machine` function. > > Testing: > - Oracle tier 1 > - Manual testing to see that the value works correctly Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29413#pullrequestreview-3705935783 From aartemov at openjdk.org Mon Jan 26 14:45:34 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 14:45:34 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Addressed reviewer's comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/31779cad..a3f07b94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=30-31 Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 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 aartemov at openjdk.org Mon Jan 26 14:45:40 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 14:45:40 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> Message-ID: <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> On Fri, 23 Jan 2026 21:42:46 GMT, Daniel D. Daugherty wrote: >> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock >> - 8366659: Changed condition on when to post an event. >> - 8366659: Fixed whitespaces. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewers' comments. >> - 8366659: Fixed whitespace. >> - 8366659: Addressed reviewer's comments. >> - 8366659: Addressed reviewers' comments, added comments, renamed tests. >> - 8366659: Modified the comment. >> - ... and 46 more: https://git.openjdk.org/jdk/compare/fa20391e...31779cad > > src/hotspot/share/runtime/objectMonitor.cpp line 1942: > >> 1940: } >> 1941: >> 1942: JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > > OK so this effectively polls and handles a pending suspend request. > That does not guarantee that another suspend request won't be pending > again (and handled in the `JvmtiExport::post_monitor_waited()` call). I may not fully understand the problem here, but isn't it that suspension requests will be processed in order of execution at relevant places in the code? If there are, for instance 2 of those, then n1 will be handled on L1939, n2 - inside of `JvmtiExport::post_monitor_waited()`, any further suspension request will be handled by the thread as soon as it runs into a check for suspension in the program flow. What exactly is the concern here? There is no harm to suspend the thread in both L1939 and L1942 as the thread is known not to be the successor. @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > src/hotspot/share/runtime/objectMonitor.cpp line 2099: > >> 2097: // move the add-to-entry_list operation, above, outside the critical section >> 2098: // protected by _wait_set_lock. In practice that's not useful. With the >> 2099: // exception of wait() timeouts and interrupts the monitor owner > > nit: extra space before wait. Addressed. > src/hotspot/share/runtime/objectMonitor.cpp line 2242: > >> 2240: // once we re-acquire the monitor we know if we need to throw IE or not. >> 2241: ObjectWaiter::TStates state = node->TState; >> 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, ""); > > assert with multiple conditions should output the values so we know exactly what condition failed. I added an error message and a small function to convert `ObjectWaiter::TState` to a `char*` for printing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865056 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865334 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2727865876 From mdoerr at openjdk.org Mon Jan 26 15:27:35 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 26 Jan 2026 15:27:35 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` Nice work! And thanks for writing the platform code as well. That's awesome! The PPC64 tests have passed (executed huge number of tests), but the comparison with `below_is_special` should be unsigned. In addition, the code can be optimized: diff --git a/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp b/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp index c1c818684cd..9012a3767b9 100644 --- a/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp @@ -955,8 +955,8 @@ void ZBarrierSetAssembler::try_resolve_weak_handle_in_c2(MacroAssembler* masm, R BarrierSetAssembler::try_resolve_weak_handle_in_c2(masm, obj, tmp, slow_path); // Check if the oop is bad, in which case we need to take the slow path. - __ ld(tmp, in_bytes(ZThreadLocalData::mark_bad_mask_offset()), R16_thread); - __ and_(tmp, obj, tmp); + __ relocate(barrier_Relocation::spec(), ZBarrierRelocationFormatMarkBadMask); + __ andi_(tmp, obj, barrier_Relocation::unpatched); __ bne(CR0, slow_path); // Oop is okay, so we uncolor it. diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp index f7a59983854..7ff8c08e1bf 100644 --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp @@ -2756,47 +2756,41 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register addi(owner_addr, mark, in_bytes(ObjectMonitor::owner_offset()) - monitor_tag); mark = noreg; } else { - const Register cache_addr = tmp3; - const Register tmp3_bucket = tmp3; - const Register tmp2_hash = tmp2; Label monitor_found; - // Save the mark, we might need it to extract the hash. - mr(tmp2_hash, mark); - // Look for the monitor in the om_cache. - - // Load cache address - addi(cache_addr, R16_thread, in_bytes(JavaThread::om_cache_oops_offset())); - + const int first_obj_offset = in_bytes(JavaThread::om_cache_oops_offset()); + const int first_monitor_offset = first_obj_offset + in_bytes(OMCache::oop_to_monitor_difference()); + const int entry_size = in_bytes(OMCache::oop_to_oop_difference()); const int num_unrolled = OMCache::CAPACITY; + for (int i = 0; i < num_unrolled; i++) { - ld(R0, 0, cache_addr); - ld(monitor, in_bytes(OMCache::oop_to_monitor_difference()), cache_addr); + ld(R0, first_obj_offset + i * entry_size, R16_thread); + ld(monitor, first_monitor_offset + i * entry_size, R16_thread); cmpd(CR0, R0, obj); beq(CR0, monitor_found); - addi(cache_addr, cache_addr, in_bytes(OMCache::oop_to_oop_difference())); } // Look for the monitor in the table. + const Register tmp2_hash = tmp2; + const Register tmp3_bucket = tmp3; // Get the hash code. - srdi(tmp2_hash, tmp2_hash, markWord::hash_shift); + srdi(tmp2_hash, mark, markWord::hash_shift); - // Get the table and calculate the bucket's address - load_const_optimized(tmp3, ObjectMonitorTable::current_table_address(), R0); - ld_ptr(tmp3, 0, tmp3); + // Get the table and calculate the bucket's address (base and index) + int simm16_rest = load_const_optimized(tmp3, ObjectMonitorTable::current_table_address(), R0, true); + ld_ptr(tmp3, simm16_rest, tmp3); ld(tmp1, in_bytes(ObjectMonitorTable::table_capacity_mask_offset()), tmp3); andr(tmp2_hash, tmp2_hash, tmp1); - ld(tmp3, in_bytes(ObjectMonitorTable::table_buckets_offset()), tmp3); - sldi(tmp2_hash, tmp2_hash, LogBytesPerWord); - add(tmp3_bucket, tmp3, tmp2_hash); + ld(tmp3_bucket, in_bytes(ObjectMonitorTable::table_buckets_offset()), tmp3); // Read the monitor from the bucket. - ld_ptr(monitor, 0, tmp3_bucket); + sldi(tmp2_hash, tmp2_hash, LogBytesPerWord); + ldx(monitor, tmp3_bucket, tmp2_hash); // Check if the monitor in the bucket is special (empty, tombstone or removed). - cmpdi(CR0, monitor, ObjectMonitorTable::SpecialPointerValues::below_is_special); + cmpldi(CR0, monitor, ObjectMonitorTable::SpecialPointerValues::below_is_special); blt(CR0, slow_path); // Check if object matches. Please take a look! Some parts may be interesting for other platform, too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29383#issuecomment-3800172269 From sgehwolf at openjdk.org Mon Jan 26 15:44:23 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 26 Jan 2026 15:44:23 GMT Subject: RFR: 8376302: os::Machine::used_memory reports container used memory when running containerized In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:16:19 GMT, Casper Norrbin wrote: > Hi everyone, > > In #27646, I introduced interfaces to get machine and container values separately when running inside a container. For `os::used_memory`, I initially moved the container check out of the function, and the remainder became `os::Machine::used_memory`. However, this function was still calling the "normal" `os::` functions, which resulted in the container check being performed again. This was incorrect. I have now updated these calls to use the appropriate `os::Machine::` functions, which do not re-check for containerization. The behaviour of `os::used_memory` itself remains unchanged, as it does the container check before delegating to the `Machine` function. > > Testing: > - Oracle tier 1 > - Manual testing to see that the value works correctly Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29413#pullrequestreview-3706662221 From liach at openjdk.org Mon Jan 26 17:16:13 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 17:16:13 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:27:06 GMT, Quan Anh Mai wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Move test, fix merge garbage >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Typo >> - assert >> - refactorings >> - Typo >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const >> - Cleanup >> - identity hash support in C2 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/96fd00b6...67a3954f > > src/hotspot/share/ci/ciArray.cpp line 93: > >> 91: // Returns T_ILLEGAL if there is no element at the given index. >> 92: ciConstant ciArray::element_value(int index) { >> 93: assert(index >= 0, "out-of-bounds index: %d", index); > > IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. I think I will not touch ciArray but rather comment on the ConstantValue _off variable about it is just a key. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728496636 From duke at openjdk.org Mon Jan 26 17:24:56 2026 From: duke at openjdk.org (Ryan Hallock) Date: Mon, 26 Jan 2026 17:24:56 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: <_aldMUgRlZczkrjTXtd7k1EVzaM3OzLoLJEPWAd-k6Q=.80ebeb4b-8181-4646-ac1a-73aeba1dbbdc@github.com> On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/f449918c...67a3954f Would this PR allow the removal of the stable hash in Enum#hashCode, maybe that should be a followup? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3800754288 From liach at openjdk.org Mon Jan 26 17:40:19 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 17:40:19 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Move test, fix merge garbage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Typo > - assert > - refactorings > - Typo > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const > - Cleanup > - identity hash support in C2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/8652dc25...67a3954f No, this only covers if a constant enum is passed. If an arbitrary enum constant is passed we still go through sone arithmetics and is slower. But this difference is probably small enough to warrant the removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3800819255 From kvn at openjdk.org Mon Jan 26 18:10:14 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 26 Jan 2026 18:10:14 GMT Subject: [jdk26] RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> References: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> Message-ID: On Mon, 26 Jan 2026 08:35:02 GMT, Jie Fu wrote: > Hi all, > > This pull request contains a backport of commit [9715e6da](https://github.com/openjdk/jdk/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jie Fu on 22 Dec 2025 and was reviewed by Kim Barrett and David Holmes. > > Thanks! @DamonFool You need to get approval for pushing it into JDK 26 since it is in RDP2 phase and it should be P2: https://openjdk.org/jeps/3#Fix-Request-Process Or you can push into JDK 26u update release instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29406#issuecomment-3800959782 From liach at openjdk.org Mon Jan 26 18:32:47 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:32:47 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move the test to a core library purposed directory Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3801082528 From liach at openjdk.org Mon Jan 26 18:33:18 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:18 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v5] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Copyright year, code style improvements - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Move test, fix merge garbage - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - Typo - assert - refactorings - Typo - Merge branch 'master' of https://github.com/openjdk/jdk into fix/identity-hash-const - ... and 4 more: https://git.openjdk.org/jdk/compare/a4c5fb85...e33f01e0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/67a3954f..e33f01e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=03-04 Stats: 95520 lines in 3917 files changed: 47645 ins; 16634 del; 31241 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From liach at openjdk.org Mon Jan 26 18:33:22 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:22 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 03:19:14 GMT, Quan Anh Mai wrote: >> src/hotspot/share/ci/ciObject.hpp line 76: >> >>> 74: }; >>> 75: >>> 76: const int IDENTITY_HASH_OFFSET = -1; >> >> `const` is fine, but `constexpr` is often preferred. Also, is `static` needed here? Another nitpick is that constants are usually not in uppercase in C++, as macros are often in uppercase. > > It is also useful to note what this value is. It is not clear at first glance why offset is -1 here. I see gc is now using `static constexpr int lowerCamelCase = ...` will use it here too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728758052 From liach at openjdk.org Mon Jan 26 18:33:21 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:33:21 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 17:13:08 GMT, Chen Liang wrote: >> src/hotspot/share/ci/ciArray.cpp line 93: >> >>> 91: // Returns T_ILLEGAL if there is no element at the given index. >>> 92: ciConstant ciArray::element_value(int index) { >>> 93: assert(index >= 0, "out-of-bounds index: %d", index); >> >> IIUC, this is because you use `-1` as the offset for hashcode, so you need to make sure we are accessing a real element here, or the cache access will return something dubious. I think it is then more uniform to save the value at the cache using the offset instead of the element index. > > I think I will not touch ciArray but rather comment on the ConstantValue _off variable about it is just a key. I decided to rename ConstantValue's off into key, should reduce confusions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2728758977 From eirbjo at openjdk.org Mon Jan 26 18:35:18 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 18:35:18 GMT Subject: RFR: 8376398: [TESTBUG] Testing of Unsafe native (re)allocation is sensitive to current JDK native memory use Message-ID: <2VzXQvgMoYrn4XLcGI-Mk53n53WiaMTlF6VQ--vsj8A=.feec0d1d-a524-4785-b21f-dc420685bd23@github.com> Please consider this PR which bumps the size of attempted allocations with 1m such that the tests are less brittle to JDK-internal native memory use. These tests currently run with `XX:MallocLimit=other:100m:oom`, but also try to allocate `100 * 1024 * 1024` bytes. With current JDK-internal native memory use, these allocation fail with OOM. When the JDK itself uses less memory, these tests start failing because allocation succeeds. I think we should simply try to allocate one more megabyte than the configured limit, which should cause the allocation to fail regardless of internal JVM native memory use. ------------- Commit messages: - Attempt to allocate 1m more than limit Changes: https://git.openjdk.org/jdk/pull/29429/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29429&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376398 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29429/head:pull/29429 PR: https://git.openjdk.org/jdk/pull/29429 From liach at openjdk.org Mon Jan 26 18:35:22 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:35:22 GMT Subject: Integrated: 8372696: Allow boot classes to explicitly opt-in for final field trusting In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 16:16:05 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. This pull request has now been integrated. Changeset: 3220c4cb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/3220c4cb431a2c4eb8bb2d60f0d5046e40af69bd Stats: 168 lines in 13 files changed: 154 ins; 13 del; 1 mod 8372696: Allow boot classes to explicitly opt-in for final field trusting Reviewed-by: jvernee, jrose, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28540 From liach at openjdk.org Mon Jan 26 19:37:06 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 19:37:06 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: > Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Use UpperCamelCase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28589/files - new: https://git.openjdk.org/jdk/pull/28589/files/e33f01e0..77ec309b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From sspitsyn at openjdk.org Mon Jan 26 23:59:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 26 Jan 2026 23:59:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: On Mon, 26 Jan 2026 14:38:40 GMT, Anton Artemov wrote: > @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: - suspend 1, resume 1, suspend 2 I'll read it more carefully and provide update if needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2729724632 From dcubed at openjdk.org Tue Jan 27 00:31:20 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 27 Jan 2026 00:31:20 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:45:34 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewer's comment. Thanks for addressing my comments. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3708613462 From jiefu at openjdk.org Tue Jan 27 01:27:17 2026 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 27 Jan 2026 01:27:17 GMT Subject: [jdk26] RFR: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: References: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> Message-ID: On Mon, 26 Jan 2026 18:07:42 GMT, Vladimir Kozlov wrote: > @DamonFool You need to get approval for pushing it into JDK 26 since it is in RDP2 phase and it should be P2: https://openjdk.org/jeps/3#Fix-Request-Process Sorry, I missed the status of JDK26. > Or you can push into JDK 26u update release instead. Okay. Will close this pr and reopen for jdk26u. Thanks @shipilev and @vnkozlov for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29406#issuecomment-3802587591 From jiefu at openjdk.org Tue Jan 27 01:27:18 2026 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 27 Jan 2026 01:27:18 GMT Subject: [jdk26] Withdrawn: 8374178: Missing include in systemDictionary.cpp after JDK-8365526 In-Reply-To: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> References: <1PPQqj3KOEQcxG0jz5XUeAAjTymJBtnHvKdoM_or2mI=.2f113992-7029-4cdb-ba69-689b1c133fc6@github.com> Message-ID: On Mon, 26 Jan 2026 08:35:02 GMT, Jie Fu wrote: > Hi all, > > This pull request contains a backport of commit [9715e6da](https://github.com/openjdk/jdk/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jie Fu on 22 Dec 2025 and was reviewed by Kim Barrett and David Holmes. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29406 From syan at openjdk.org Tue Jan 27 02:23:32 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 27 Jan 2026 02:23:32 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v5] In-Reply-To: References: Message-ID: <_pdoKJnTKMT4O4HJDQIDKIhCPPJapiRxejiGWIvXh4U=.c8fd64a1-3706-40c9-9690-8f84aaa0b9d8@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: Add oracle copyright line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28975/files - new: https://git.openjdk.org/jdk/pull/28975/files/b1b2a482..df7451df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28975&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 27 02:23:33 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 27 Jan 2026 02:23:33 GMT Subject: RFR: 8374322: TestMemoryWithSubgroups.java fails Permission denied [v4] In-Reply-To: <1ZRPt2rS8Cb3n1f9mYgx333wOvag2VA80PrCt-6zSP8=.5c62a3de-e2c8-4ea4-9012-3ee71fbd0713@github.com> References: <02ksOlBPDEVmRbkMK0iFzJ32y0qwfeGqti4aDWqJKwA=.897e17ed-a284-4495-ba0f-f90741ab612a@github.com> <1ZRPt2rS8Cb3n1f9mYgx333wOvag2VA80PrCt-6zSP8=.5c62a3de-e2c8-4ea4-9012-3ee71fbd0713@github.com> Message-ID: On Mon, 26 Jan 2026 12:17:21 GMT, Afshin Zafari wrote: > Thank you Sendao for taking this fix. Just a comment on the Copyright text and year. There should be an Oracle line in the Copyright with 2026. Thanks. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28975#issuecomment-3802709097 From epeter at openjdk.org Tue Jan 27 06:55:16 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 06:55:16 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: > 35: * @summary Verify constant folding is possible for identity hash code > 36: * @library /test/lib / > 37: * @requires vm.compiler2.enabled Drive-by comment: Do you really need this restriction? IR rules are only executed if C2 is available anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730518926 From liach at openjdk.org Tue Jan 27 07:15:12 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 07:15:12 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:51:54 GMT, Emanuel Peter wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Use UpperCamelCase > > test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: > >> 35: * @summary Verify constant folding is possible for identity hash code >> 36: * @library /test/lib / >> 37: * @requires vm.compiler2.enabled > > Drive-by comment: > Do you really need this restriction? IR rules are only executed if C2 is available anyway. Well, the plain test isn't that meaningful without C2. https://github.com/openjdk/jdk/pull/28589#discussion_r2615925589 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730577795 From epeter at openjdk.org Tue Jan 27 07:50:09 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 07:50:09 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v3] In-Reply-To: References: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com> <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com> Message-ID: On Mon, 15 Dec 2025 19:44:47 GMT, Chen Liang wrote: >> I don't argue that there's always a chance to catch a bug, but unit tests on C2 IR are mostly trivial, so the actual chance to spot a unique problem is quite low. And the price is execution time. > > I kept the C2 limit (note this is a build restriction instead of a flag restriction), but updated to use test.main.class. Right. Vladimir already argued against it. I forgot. I still believe it is best practice not to limit tests unless they are very expensive. But I'll accept the majority vote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730682963 From epeter at openjdk.org Tue Jan 27 07:50:12 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 07:50:12 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 07:12:28 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/intrinsics/object/IdentityHashCodeFold.java line 37: >> >>> 35: * @summary Verify constant folding is possible for identity hash code >>> 36: * @library /test/lib / >>> 37: * @requires vm.compiler2.enabled >> >> Drive-by comment: >> Do you really need this restriction? IR rules are only executed if C2 is available anyway. > > Well, the plain test isn't that meaningful without C2. https://github.com/openjdk/jdk/pull/28589#discussion_r2615925589 Right. Vladimir already argued against it. I forgot. I still believe it is best practice not to limit tests unless they are very expensive. But I'll accept the majority vote. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2730681732 From aboldtch at openjdk.org Tue Jan 27 08:12:42 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 27 Jan 2026 08:12:42 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` Thanks to everyone involved for implementing this. Very nice with a simpler, specialised hash table we can use from the emitted code. Also moving the resizing work to the deflation thread and keeping rebuilding in sync with deflation is something I always thought we should have done. Nice improvement. Only wonder if we should do something when deflation is turned off. As we will then never `rebuild` and thus have all previous tables forever. (They are diagnostic flags) So maybe we should just not turn off the deflation thread, and instead have it only respond to `ObjectSynchronizer::request_deflate_idle_monitors();` requests, but not do anything timebased. I have a few comments most related to type safety. The new table implementation looks sound. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 229: > 227: > 228: // Save the mark, we might need it to extract the hash. > 229: mov(rscratch2, t1_mark); Using `rscratch2` here is a little bit scary as we call other MacroAssembler functions with the expectation of it being live. Guessing the `ldr`, `lea` and `increment` implementations are not likely to change anytime soon, but maybe it is worth a comment saying that we do not expect these to modify the state of `rscratch2` src/hotspot/share/runtime/lockStack.hpp line 142: > 140: ObjectMonitor* _monitor = nullptr; > 141: } _entries[CAPACITY]; > 142: const oop _null_sentinel = nullptr; This should no longer be needed. As we no longer have any loops in C2 that terminates on a null read. src/hotspot/share/runtime/objectMonitorTable.cpp line 47: > 45: const size_t _capacity_mask; // One less than its power-of-two capacity > 46: Table* volatile _prev; // Set while rehashing > 47: ObjectMonitor* volatile* _buckets; // The payload I think this should have some opaque `enum class` type rather than `ObjectMonitor*` because we do not always store an `ObjectMonitor*` inside. We could repurpose `SpecialPointerValues` with another name. So we avoid these reinterpret_casts from our special values to `ObjectMonitor*`. And only reinterpret_cast values we know to be `ObjectMonitor*` to `ObjectMonitor*`. src/hotspot/share/runtime/objectMonitorTable.cpp line 51: > 49: char _padding[DEFAULT_CACHE_LINE_SIZE]; > 50: > 51: volatile size_t _items_count; I wonder if we want something along the lines of this here. We do not allocate many of these tables, so using some extra padding to make sure we never share cache lines with anything outside the objects either (even though it will probably always just be our NMT headers). Suggestion: DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, 0); const size_t _capacity_mask; // One less than its power-of-two capacity Table* volatile _prev; // Set while rehashing ObjectMonitor* volatile* _buckets; // The payload DEFINE_PAD_MINUS_SIZE(1, DEFAULT_CACHE_LINE_SIZE, sizeof(_capacity_mask) + sizeof(_prev) + sizeof(_buckets)); volatile size_t _items_count; DEFINE_PAD_MINUS_SIZE(2, DEFAULT_CACHE_LINE_SIZE, sizeof(_items_count)); Once we add alignment support for our CHeapObj operator new we can replace this with: ```c++ const size_t _capacity_mask; // One less than its power-of-two capacity Table* volatile _prev; // Set while rehashing ObjectMonitor* volatile* _buckets; // The payload alignas(DEFAULT_CACHE_LINE_SIZE) volatile size_t _items_count; src/hotspot/share/runtime/objectMonitorTable.cpp line 59: > 57: static ObjectMonitor* removed_entry() { > 58: return (ObjectMonitor*)ObjectMonitorTable::SpecialPointerValues::removed; > 59: } Same comment as above w.r.t. not using reinterpret_cast on non-`ObjectMonitor*` values src/hotspot/share/runtime/objectMonitorTable.cpp line 118: > 116: } > 117: > 118: ObjectMonitor* get(oop obj, int hash) { While it might be wrong that we type the hash() interface on the markWord as `intptr_t`. I think we should stick with that type until we decide to change this in the markWord inteface. When I see a `intptr_t` -> `int` -> `size_t` roundtrip I try and figure out what the purpose is. src/hotspot/share/runtime/objectMonitorTable.cpp line 153: > 151: } > 152: > 153: // Rehashing could have stareted by now, but if a monitor has been inserted in a Suggestion: // Rehashing could have started by now, but if a monitor has been inserted in a src/hotspot/share/runtime/objectMonitorTable.cpp line 158: > 156: } > 157: > 158: ObjectMonitor* get_set(oop obj, ObjectMonitor* new_monitor, int hash) { Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.cpp line 218: > 216: } > 217: > 218: void remove(oop obj, ObjectMonitor* old_monitor, int hash) { Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.cpp line 252: > 250: > 251: void reinsert(oop obj, ObjectMonitor* new_monitor) { > 252: int hash = obj->mark().hash(); Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.cpp line 334: > 332: // A monitor > 333: oop obj = monitor->object_peek(); > 334: if (!monitor->is_being_async_deflated() && obj != nullptr) { While there is nothing inherently wrong with the check. In the current implementation will we ever encounter a `monitor->is_being_async_deflated() == true`. As it is the deflation thread which drives the rebuilding, and it will already have removed any entry it has deflated. src/hotspot/share/runtime/objectMonitorTable.cpp line 351: > 349: > 350: ObjectMonitor* ObjectMonitorTable::monitor_get(Thread* current, oop obj) { > 351: const int hash = obj->mark().hash(); Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.cpp line 382: > 380: > 381: ObjectMonitor* ObjectMonitorTable::monitor_put_get(Thread* current, ObjectMonitor* monitor, oop obj) { > 382: const int hash = obj->mark().hash(); Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.cpp line 402: > 400: return; > 401: } > 402: const int hash = obj->mark().hash(); Same type comment. (`int` -> `intptr_t`) src/hotspot/share/runtime/objectMonitorTable.hpp line 56: > 54: removed = 2, > 55: below_is_special = (removed + 1) > 56: } SpecialPointerValues; Could this be a C++ enum instead? Suggestion: enum SpecialPointerValues { empty = 0, tombstone = 1, removed = 2, below_is_special = (removed + 1) }; I think I preferred it to be an strongly typed `enum class` as well. (But we do use it as an integral in the MacroAssembler so that would introduce some casts. ------------- PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3709345634 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730469114 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730510424 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730606148 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730553209 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730608119 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730627153 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730672999 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730627382 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730627673 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730621824 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730732236 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730624277 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730625000 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730626783 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2730561044 From cnorrbin at openjdk.org Tue Jan 27 10:20:46 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 27 Jan 2026 10:20:46 GMT Subject: RFR: 8369503: [Linux] Move machine-specific queries to the OSContainer layer [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > In #27470, we removed most calls up to `os::Linux` from the container/cgroup layer. This PR finishes that work by removing the last few tricky ones. We had one call in `CgroupSubsystem::active_processor_count` and two calls in `CgroupUtil::adjust_controller`. These were harder to untangle because the call in `active_processor_count` was guarded by a cache, and `adjust_controller` was called in the v1/v2 controller constructors. > > `CgroupSubsystem::active_processor_count` now takes a supplier function for the host CPU count, provided from `OSContainer`. The cache still decides if we call the supplied function, so we keep existing caching functionality. > > For hierarchy adjustments, I moved the calls out of the cgroup constructors and into `OSContainer`'s initialization, with a new used helper function `CgroupSubsystem::adjust_controllers` that adjusts all controllers. After creating the cgroup subsystem, we adjust the controllers once from `OSContainer`, instead of doing it as the last step of the creation. > > As a result from these changes, cgroup code no longer needs to include or call `os::Linux` functions. > > Testing: > - Oracle tiers 1-5 > - Local container tests on cgroup v1 and v2 on both Podman and Docker Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into cgroupsubsystem-no-os-calls - move os::linux calls out of cgroups ------------- Changes: https://git.openjdk.org/jdk/pull/29188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29188&range=01 Stats: 45 lines in 8 files changed: 12 ins; 8 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29188/head:pull/29188 PR: https://git.openjdk.org/jdk/pull/29188 From sgehwolf at openjdk.org Tue Jan 27 10:44:41 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 27 Jan 2026 10:44:41 GMT Subject: RFR: 8369503: [Linux] Move machine-specific queries to the OSContainer layer [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:20:46 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> In #27470, we removed most calls up to `os::Linux` from the container/cgroup layer. This PR finishes that work by removing the last few tricky ones. We had one call in `CgroupSubsystem::active_processor_count` and two calls in `CgroupUtil::adjust_controller`. These were harder to untangle because the call in `active_processor_count` was guarded by a cache, and `adjust_controller` was called in the v1/v2 controller constructors. >> >> `CgroupSubsystem::active_processor_count` now takes a supplier function for the host CPU count, provided from `OSContainer`. The cache still decides if we call the supplied function, so we keep existing caching functionality. >> >> For hierarchy adjustments, I moved the calls out of the cgroup constructors and into `OSContainer`'s initialization, with a new used helper function `CgroupSubsystem::adjust_controllers` that adjusts all controllers. After creating the cgroup subsystem, we adjust the controllers once from `OSContainer`, instead of doing it as the last step of the creation. >> >> As a result from these changes, cgroup code no longer needs to include or call `os::Linux` functions. >> >> Testing: >> - Oracle tiers 1-5 >> - Local container tests on cgroup v1 and v2 on both Podman and Docker > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into cgroupsubsystem-no-os-calls > - move os::linux calls out of cgroups Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29188#pullrequestreview-3710432166 From cnorrbin at openjdk.org Tue Jan 27 12:37:23 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 27 Jan 2026 12:37:23 GMT Subject: RFR: 8376302: os::Machine::used_memory reports container used memory when running containerized In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:16:19 GMT, Casper Norrbin wrote: > Hi everyone, > > In #27646, I introduced interfaces to get machine and container values separately when running inside a container. For `os::used_memory`, I initially moved the container check out of the function, and the remainder became `os::Machine::used_memory`. However, this function was still calling the "normal" `os::` functions, which resulted in the container check being performed again. This was incorrect. I have now updated these calls to use the appropriate `os::Machine::` functions, which do not re-check for containerization. The behaviour of `os::used_memory` itself remains unchanged, as it does the container check before delegating to the `Machine` function. > > Testing: > - Oracle tier 1 > - Manual testing to see that the value works correctly Thank you for the quick reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29413#issuecomment-3804972230 From cnorrbin at openjdk.org Tue Jan 27 12:37:24 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 27 Jan 2026 12:37:24 GMT Subject: Integrated: 8376302: os::Machine::used_memory reports container used memory when running containerized In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:16:19 GMT, Casper Norrbin wrote: > Hi everyone, > > In #27646, I introduced interfaces to get machine and container values separately when running inside a container. For `os::used_memory`, I initially moved the container check out of the function, and the remainder became `os::Machine::used_memory`. However, this function was still calling the "normal" `os::` functions, which resulted in the container check being performed again. This was incorrect. I have now updated these calls to use the appropriate `os::Machine::` functions, which do not re-check for containerization. The behaviour of `os::used_memory` itself remains unchanged, as it does the container check before delegating to the `Machine` function. > > Testing: > - Oracle tier 1 > - Manual testing to see that the value works correctly This pull request has now been integrated. Changeset: 528bbe79 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/528bbe7919785c50dda583277f4146b25eb4d2a4 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8376302: os::Machine::used_memory reports container used memory when running containerized Reviewed-by: eosterlund, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/29413 From clanger at openjdk.org Tue Jan 27 13:27:17 2026 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 27 Jan 2026 13:27:17 GMT Subject: RFR: 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:23:33 GMT, Matthias Baesken wrote: > There are a few usages of USE_XLC_BUILTINS left in the AIX hotspot coding. But they are obsolete these days. Most were removed already but the few remaining can be removed too. Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29408#pullrequestreview-3711183198 From mbaesken at openjdk.org Tue Jan 27 13:30:37 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 27 Jan 2026 13:30:37 GMT Subject: RFR: 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:23:33 GMT, Matthias Baesken wrote: > There are a few usages of USE_XLC_BUILTINS left in the AIX hotspot coding. But they are obsolete these days. Most were removed already but the few remaining can be removed too. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29408#issuecomment-3805223092 From mbaesken at openjdk.org Tue Jan 27 13:33:18 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 27 Jan 2026 13:33:18 GMT Subject: Integrated: 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:23:33 GMT, Matthias Baesken wrote: > There are a few usages of USE_XLC_BUILTINS left in the AIX hotspot coding. But they are obsolete these days. Most were removed already but the few remaining can be removed too. This pull request has now been integrated. Changeset: 479ac8b2 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/479ac8b2fdfbb64d26b34ff72abd61a1ce5f6c87 Stats: 15 lines in 2 files changed: 0 ins; 12 del; 3 mod 8376281: Remove USE_XLC_BUILTINS macro usage in AIX code Reviewed-by: mdoerr, clanger ------------- PR: https://git.openjdk.org/jdk/pull/29408 From phubner at openjdk.org Tue Jan 27 15:33:03 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 27 Jan 2026 15:33:03 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain Message-ID: Hi all, This fixes `runtime/ErrorHandling/TestDwarf.java` failing on Linux+Clang. Two sub-tests are patched. #### `crashNativeMultipleMethods` Disallow inlining of `foo` to ensure it appears in the native frames stack, where it can be picked up by the test process analyser. #### `crashNativeDereferenceNull` Preventatively also disable inlining for `dereference_null` since it's searched for in the stack. With Clang, the JVM process can exit without an hs_err file, so skip the subtest. `crashNativeMultipleMethods` already checks the stack frames, so we are not losing coverage. Furthermore, the vast majority of the world uses a GCC-built JDK anyway. Testing: Ran the test for 20 iterations on Linux+GCC and Linux+Clang without failure. Also tier1 on Linux, macOS and Windows as a sanity test. ------------- Commit messages: - Fix failing test. Changes: https://git.openjdk.org/jdk/pull/29451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371590 Stats: 24 lines in 3 files changed: 16 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29451/head:pull/29451 PR: https://git.openjdk.org/jdk/pull/29451 From duke at openjdk.org Tue Jan 27 23:34:26 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Jan 2026 23:34:26 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:03:39 GMT, George Wort wrote: > Won't the GC only remove an nmethod if it's inaccessible rather than it just being cold though? Or does the GC sweep methods that haven't been called for a while? The GC should remove nmethods even if they are still accessible. There is a check to determine if an nmethod should be removed based on the `is_cold` heuristic ([link](https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/code/nmethod.cpp#L2736-L2741)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3808110703 From duke at openjdk.org Wed Jan 28 00:39:13 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 28 Jan 2026 00:39:13 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6] In-Reply-To: References: Message-ID: <9m7_4Kf6Vea6NuHshrpu882clUZ62dg4eUEaEz6ZfNM=.32b82a85-21ac-4a9b-ae89-ed66a4bcd4e1@github.com> On Mon, 19 Jan 2026 23:06:56 GMT, Evgeny Astigeevich wrote: > We can consider relocating nmethods back to the normal heap, the non-profiled code heap. IMO we should do this instead of GC throwing them away. If after being moved to the normal heap they become cold, GC will remove them from CodeCache. If they become hot again, they will be relocated to HotCodeHeap. I think we should only consider relocating nmethods to the non-profiled code heap if the HotCodeHeap is full. If the GC determines an nmethod from the HotCodeHeap is cold, it would also have determined it were cold in the non-profiled heap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3808304020 From dlong at openjdk.org Wed Jan 28 02:25:23 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 02:25:23 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/ci/ciObject.hpp line 118: > 116: > 117: // Access to the constant value cache > 118: // Key must be nonnegative. Negative keys are reserved. Suggestion: // Keys representing an array index or field offset are nonnegative. Negative keys are reserved for special values such as identity hash code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734576071 From dholmes at openjdk.org Wed Jan 28 02:30:14 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 02:30:14 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: On Mon, 26 Jan 2026 23:56:03 GMT, Serguei Spitsyn wrote: >> I may not fully understand the problem here, but isn't it that suspension requests will be processed in order of execution at relevant places in the code? >> >> If there are, for instance 2 of those, then n1 will be handled on L1939, n2 - inside of `JvmtiExport::post_monitor_waited()`, any further suspension request will be handled by the thread as soon as it runs into a check for suspension in the program flow. What exactly is the concern here? There is no harm to suspend the thread in both L1939 and L1942 as the thread is known not to be the successor. >> >> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > >> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? > > It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: > - suspend 1, resume 1, suspend 2 > > The `JvmtiExport::post_monitor_waited()` has a recursive call to `ThreadStateTransition::transition_from_native()` upon return from event callback. There is a suspend point there. > I'll read it more carefully and provide update if needed. IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2734584373 From dholmes at openjdk.org Wed Jan 28 02:38:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 02:38:29 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:45:34 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Addressed reviewer's comment. A couple of nits but otherwise I think everything has been addressed and that the code will do what we want/expect. Thanks src/hotspot/share/runtime/objectMonitor.cpp line 2244: > 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, > 2243: "was not notified and is not in the right state: was_notified = %s, state = %s", > 2244: was_notified ? "true" : "false", node->getTStateName(state)); Suggestion: assert(was_notified || state == ObjectWaiter::TS_RUN, "was not notified and is not in the right state: was_notified = %s, state = %s", was_notified ? "true" : "false", node->getTStateName(state)); Fix indent. Printing was_notified is redundant though as the assert can only fail if it is false. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3714312102 PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2734592403 From dlong at openjdk.org Wed Jan 28 02:56:57 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 02:56:57 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/oops/oop.inline.hpp line 443: > 441: intptr_t oopDesc::fast_identity_hash_or_no_hash() { > 442: // Note: The mark must be read into local variable to avoid concurrent updates. > 443: markWord mrk = mark_acquire(); Suggestion: markWord mrk = mark(); For the fast case, it seems safe to use mark() like oopDesc::identity_hash() does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734638145 From dlong at openjdk.org Wed Jan 28 03:14:45 2026 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Jan 2026 03:14:45 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:37:06 GMT, Chen Liang wrote: >> Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use UpperCamelCase src/hotspot/share/opto/library_call.cpp line 4791: > 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); > 4790: if (t != nullptr && t->const_oop() != nullptr) { > 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734670836 From liach at openjdk.org Wed Jan 28 03:46:01 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jan 2026 03:46:01 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:11:52 GMT, Dean Long wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Use UpperCamelCase > > src/hotspot/share/opto/library_call.cpp line 4791: > >> 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); >> 4790: if (t != nullptr && t->const_oop() != nullptr) { >> 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); > > Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? I think once we are not virtual, the native Object::hashCode behaves like System::identityHashCode. The only difference is null check, but I think there's a null check in the beginning so we should be safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2734726026 From iklam at openjdk.org Wed Jan 28 07:57:39 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 Jan 2026 07:57:39 GMT Subject: RFR: 8376523: Move interned strings into AOT heap roots array Message-ID: This is a small clean up that deletes about 200 lines of code. With AOTMappedHeapLoader, the interned strings are stored inside a cached ObjArray. Because cached ObjArrays cannot be larger than 256KB, we need to split this ObjArray into two levels when there are a lot of interned strings https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/classfile/stringTable.cpp#L81-L93 However, we already have a similar mechanism for storing heap roots in multiple ObjArrays that are no larger than 256KB: https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/cds/aotMappedHeapLoader.cpp#L403-L409 By storing the interned strings inside the heap roots array, we can get rid of the two-level ObjArray manipulation code in stringTables.cpp. ------------- Commit messages: - 8376523: Move interned strings into AOT roots array Changes: https://git.openjdk.org/jdk/pull/29459/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29459&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376523 Stats: 236 lines in 7 files changed: 7 ins; 209 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29459/head:pull/29459 PR: https://git.openjdk.org/jdk/pull/29459 From lucy at openjdk.org Wed Jan 28 09:23:03 2026 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 28 Jan 2026 09:23:03 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` I checked the s390 implementation only: nice work! I have added some hints to make the generated code more s390-style. Thanks for considering. Please note: the suggested changes are just dry-coded, not tested! src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6394: > 6392: z_bre(monitor_found); > 6393: add2reg(cache_addr, in_bytes(OMCache::oop_to_oop_difference())); > 6394: } This would be an alternative for the above loop: ByteSize cache_offset = JavaThread::om_cache_oops_offset(); ByteSize monitor_offset = OMCache::oop_to_monitor_difference(); const unsigned int num_unrolled = 2; for (unsigned int i = 0; i < num_unrolled; i++) { z_lg(tmp1_monitor, Address(Z_thread, cache_offset + monitor_offset)); z_cg(obj, Address(Z_thread, cache_offset)); z_bre(monitor_found); cache_offset += in_bytes(OMCache::oop_to_oop_difference()); } src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6403: > 6401: z_lg(tmp2, Address(tmp2)); > 6402: z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset())); > 6403: z_ngr(hash, tmp1); The above two instructions could be combined: ` z_ng(hash, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset()));` src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6404: > 6402: z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset())); > 6403: z_ngr(hash, tmp1); > 6404: z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_buckets_offset())); Wouldn't it be clearer to use `tmp1_bucket` here? ------------- Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3715414005 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2735608767 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2735567037 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2735574647 From aartemov at openjdk.org Wed Jan 28 09:26:17 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 09:26:17 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: References: Message-ID: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> > Hi, please consider the following changes: > > If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8366659: Indentation fix. - 8366659: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/a3f07b94..6620a88f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=31-32 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 aartemov at openjdk.org Wed Jan 28 09:26:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 09:26:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v32] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 02:31:31 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8366659: Addressed reviewer's comment. > > src/hotspot/share/runtime/objectMonitor.cpp line 2244: > >> 2242: assert(was_notified || state == ObjectWaiter::TS_RUN, >> 2243: "was not notified and is not in the right state: was_notified = %s, state = %s", >> 2244: was_notified ? "true" : "false", node->getTStateName(state)); > > Suggestion: > > assert(was_notified || state == ObjectWaiter::TS_RUN, > "was not notified and is not in the right state: was_notified = %s, state = %s", > was_notified ? "true" : "false", node->getTStateName(state)); > > Fix indent. > > Printing was_notified is redundant though as the assert can only fail if it is false. Thanks for spotting, addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2735645462 From lucy at openjdk.org Wed Jan 28 09:46:08 2026 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 28 Jan 2026 09:46:08 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` Just one more thing: `cghi` -> `clgfi` in one place. src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6412: > 6410: > 6411: // Check if the monitor in the bucket is special (empty, tombstone or removed). > 6412: z_cghi(tmp1_monitor, ObjectMonitorTable::SpecialPointerValues::below_is_special); Address comparison should be unsigned. Please use `clgfi` instead. ------------- Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3715643449 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2735751686 From fjiang at openjdk.org Wed Jan 28 10:14:39 2026 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 28 Jan 2026 10:14:39 GMT Subject: RFR: 8376572: RISC-V: Interpreter: Load array index as signed int Message-ID: Please consider. We should use the `lw` instruction (which loads a 32-bit index from the operand stack and performs sign extension) instead of the `ld` instruction for the array index loading from the operand stack. Testing: - [x] tier1 with linux-riscv64 release build ------------- Commit messages: - RISC-V: Interpreter: Load array index as signed int Changes: https://git.openjdk.org/jdk/pull/29458/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376572 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29458/head:pull/29458 PR: https://git.openjdk.org/jdk/pull/29458 From phubner at openjdk.org Wed Jan 28 10:17:01 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 28 Jan 2026 10:17:01 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v2] In-Reply-To: References: Message-ID: > Hi all, > > This fixes `runtime/ErrorHandling/TestDwarf.java` failing on Linux+Clang. Two sub-tests are patched. > > #### `crashNativeMultipleMethods` > > Disallow inlining of `foo` to ensure it appears in the native frames stack, where it can be picked up by the test process analyser. > > #### `crashNativeDereferenceNull` > > Preventatively also disable inlining for `dereference_null` since it's searched for in the stack. With Clang, the JVM process can exit without an hs_err file, so skip the subtest. `crashNativeMultipleMethods` already checks the stack frames, so we are not losing coverage. Furthermore, the vast majority of the world uses a GCC-built JDK anyway. > > Testing: Ran the test for 20 iterations on Linux+GCC and Linux+Clang without failure. Also tier1 on Linux, macOS and Windows as a sanity test. Paul H?bner has updated the pull request incrementally with one additional commit since the last revision: Ignore inlining with MSVC. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29451/files - new: https://git.openjdk.org/jdk/pull/29451/files/0fb953bc..7b6e6578 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=00-01 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29451/head:pull/29451 PR: https://git.openjdk.org/jdk/pull/29451 From fyang at openjdk.org Wed Jan 28 10:24:02 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Jan 2026 10:24:02 GMT Subject: RFR: 8376572: RISC-V: Interpreter: Load array index as signed int In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:22:22 GMT, Feilong Jiang wrote: > Please consider. > We should use the `lw` instruction (which loads a 32-bit index from the operand stack and performs sign extension) instead of the `ld` instruction for the array index loading from the operand stack. > > Testing: > > - [x] tier1 with linux-riscv64 release build Looks reasonable. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29458#pullrequestreview-3715877817 From sspitsyn at openjdk.org Wed Jan 28 11:34:24 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 11:34:24 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> References: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> Message-ID: On Wed, 28 Jan 2026 09:26:17 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8366659: Indentation fix. > - 8366659: Addressed reviewer's comments. Changes requested by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3716198918 From sspitsyn at openjdk.org Wed Jan 28 11:34:25 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 11:34:25 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> Message-ID: <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> On Wed, 28 Jan 2026 02:27:10 GMT, David Holmes wrote: >>> @sspitsyn could you clarify if it is technically possible to have more than one suspension request for a thread at any given time? >> >> It is not possible to have multiple suspend requests for a thread at any given time. There can be attempts to do so but they are sorted out at JVMTI calls level. But if I understand correctly, David is saying about something like this sequence: >> - suspend 1, resume 1, suspend 2 >> >> The `JvmtiExport::post_monitor_waited()` has a recursive call to `ThreadStateTransition::transition_from_native()` upon return from event callback. There is a suspend point there. >> I'll read it more carefully and provide update if needed. > > IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. The problem here is a decision to post the monitor waited event at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. One approach would be to refactor this as below: // Process suspend requests now if any, before posting the event { ThreadBlockInVM tbvm(current, true); } if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); Another approach would be to get rid of this `ThreadBlockInVM`. But it is hard to predict all the consequences. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736211365 From fyang at openjdk.org Wed Jan 28 11:51:04 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Jan 2026 11:51:04 GMT Subject: RFR: 8376575: aarch64: incorrect array index load in aastore Message-ID: Hi, Please consider this small change fixing array index load in aastore. >From the jvm spec, array index is is of type `int` for aastore. But we use `ldr` to get index in `TemplateTable::aastore()`. AArch64 `ldr` instruction loads 64-bit value from memory, which doesn't match the type of array index. This doesn't seem to cause an issue as we only use the lower 32-bit of the loaded value for index check (`cmpw`). We should use `ldrw` here which loads 4 bytes instead to avoid out of bounds read of array index. Testing: tier1 with release build on linux-aarch64. ------------- Commit messages: - 8376575: aarch64: incorrect array index load in aastore Changes: https://git.openjdk.org/jdk/pull/29464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29464&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376575 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29464/head:pull/29464 PR: https://git.openjdk.org/jdk/pull/29464 From dholmes at openjdk.org Wed Jan 28 11:54:44 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 11:54:44 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> Message-ID: <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> On Wed, 28 Jan 2026 11:31:03 GMT, Serguei Spitsyn wrote: >> IIUC Dan's concern is not a concern because another suspend request can be initiated but it won't be actioned until the target executes the handshake - which can only happen at well-defined points where we allow for suspension. > > Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. > As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. > The problem here is a decision to post the monitor waited event at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. > > One approach would be to refactor this as below: > > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > > Another approach would be to get rid of this `ThreadBlockInVM`. > But it is hard to predict all the consequences. The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736280646 From aph at openjdk.org Wed Jan 28 12:27:51 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 12:27:51 GMT Subject: RFR: 8376575: aarch64: incorrect array index load in aastore In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 11:31:44 GMT, Fei Yang wrote: > Hi, > > Please consider this small change fixing array index load in aastore. > > From the jvm spec, array index is is of type `int` for aastore. But we use `ldr` to get index in `TemplateTable::aastore()`. > AArch64 `ldr` instruction loads 64-bit value from memory, which doesn't match the type of array index. > This doesn't seem to cause an issue as we only use the lower 32-bit of the loaded value for index check (`cmpw`). > We should use `ldrw` here which loads 4 bytes instead to avoid out of bounds read of array index. > > Testing: tier1-tier2 with release build on linux-aarch64. This is fine. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29464#pullrequestreview-3716441292 From aartemov at openjdk.org Wed Jan 28 12:40:07 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Wed, 28 Jan 2026 12:40:07 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 11:51:06 GMT, David Holmes wrote: >> Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`. >> As Patricio already explained, enabling and posting JVMTI events are intentionally racy, so we normally do not care about missing racy events. However, suspend points are synchronous. We should honor both enabled and disabled event requests that are present at a suspend point. >> The problem here is a decision to post the monitor waited event has been made at the line 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at the `ThreadBlockInVM` suspend point. >> >> One approach would be to refactor this as below: >> >> // Process suspend requests now if any, before posting the event >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> >> Another approach would be to get rid of this `ThreadBlockInVM`. >> But it is hard to predict all the consequences. > > The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736447830 From adinn at openjdk.org Wed Jan 28 13:29:53 2026 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 28 Jan 2026 13:29:53 GMT Subject: RFR: 8376575: aarch64: incorrect array index load in aastore In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 11:31:44 GMT, Fei Yang wrote: > Hi, > > Please consider this small change fixing array index load in aastore. > > From the jvm spec, array index is is of type `int` for aastore. But we use `ldr` to get index in `TemplateTable::aastore()`. > AArch64 `ldr` instruction loads 64-bit value from memory, which doesn't match the type of array index. > This doesn't seem to cause an issue as we only use the lower 32-bit of the loaded value for index check (`cmpw`). > We should use `ldrw` here which loads 4 bytes instead to avoid out of bounds read of array index. > > Testing: tier1-tier2 with release build on linux-aarch64. This appears to me to be an odd thing to do for just this one case. For example, looking at iload and its varinats they all use a plain ldr. Would we not want to change them as well? The template methods that load an int from the stack or locals area get away with using ldr because an int is only available to load from those locations if it has been put on the stack or into a local as an int -- the bytecode verifier plus correctness of the store operations will guarantee that on aarch64. So, use of ldrw is not strictly needed -- it merely ensures we don't detect a store that uses str by mistake. If we are going to enforce this then maybe we should do it everywhere just to be consistent. Half and half is arguably more likely to confuse. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29464#issuecomment-3811309353 From jsikstro at openjdk.org Wed Jan 28 13:44:51 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 28 Jan 2026 13:44:51 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 10:17:01 GMT, Paul H?bner wrote: >> Hi all, >> >> This fixes `runtime/ErrorHandling/TestDwarf.java` failing on Linux+Clang. Two sub-tests are patched. >> >> #### `crashNativeMultipleMethods` >> >> Disallow inlining of `foo` to ensure it appears in the native frames stack, where it can be picked up by the test process analyser. >> >> #### `crashNativeDereferenceNull` >> >> Preventatively also disable inlining for `dereference_null` since it's searched for in the stack. With Clang, the JVM process can exit without an hs_err file, so skip the subtest. `crashNativeMultipleMethods` already checks the stack frames, so we are not losing coverage. Furthermore, the vast majority of the world uses a GCC-built JDK anyway. >> >> Testing: Ran the test for 20 iterations on Linux+GCC and Linux+Clang without failure. Also tier1 on Linux, macOS and Windows as a sanity test. > > Paul H?bner has updated the pull request incrementally with one additional commit since the last revision: > > Ignore inlining with MSVC. I think this looks fine. I added a few of my reflections. test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarf.c line 35: > 33: __attribute__((noinline)) > 34: #endif > 35: void foo(int x) { Now that we are explicitly NOT inlining this method, we could follow-up with simplifying this instead of doing "some random things" as the old comment stated. test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 46: > 44: #if !defined(_MSC_VER) > 45: __attribute__((noinline)) > 46: #endif If I understand this correctly, we relied upon this not being inlined before, but now we want to guarantee this. This is so that we can check that the line-numer in the produced hs_err matches the line-numer in this file to see that we crash at the "correct" place. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29451#pullrequestreview-3716701693 PR Review Comment: https://git.openjdk.org/jdk/pull/29451#discussion_r2736633983 PR Review Comment: https://git.openjdk.org/jdk/pull/29451#discussion_r2736696548 From aph at openjdk.org Wed Jan 28 15:06:36 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 15:06:36 GMT Subject: RFR: 8376575: aarch64: incorrect array index load in aastore In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 13:27:23 GMT, Andrew Dinn wrote: > This appears to me to be an odd thing to do for just this one case. For example, looking at iload and its varinats they all use a plain ldr. Would we not want to change them as well? Definitely. > If we are going to enforce this then maybe we should do it everywhere just to be consistent. Half and half is arguably more likely to confuse. Yes, that makes sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29464#issuecomment-3811810105 From sspitsyn at openjdk.org Wed Jan 28 16:03:41 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 16:03:41 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 12:37:55 GMT, Anton Artemov wrote: >> The `ThreadBlockInVM` is there so that a thread suspended before being notified does not expose that fact by issuing a monitor_waited event whilst suspended. > > Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. Okay. Then what about this ? : if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { // Process suspend requests now if any, before posting the event { ThreadBlockInVM tbvm(current, true); } if (JvmtiExport::should_post_monitor_waited()) { JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2737343109 From kvn at openjdk.org Wed Jan 28 17:45:44 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 Jan 2026 17:45:44 GMT Subject: RFR: 8376523: Move interned strings into AOT heap roots array In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 06:50:47 GMT, Ioi Lam wrote: > This is a small clean up that deletes about 200 lines of code. > > With AOTMappedHeapLoader, the interned strings are stored inside a cached ObjArray. Because cached ObjArrays cannot be larger than 256KB, we need to split this ObjArray into two levels when there are a lot of interned strings > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/classfile/stringTable.cpp#L81-L93 > > However, we already have a similar mechanism for storing heap roots in multiple ObjArrays that are no larger than 256KB: > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/cds/aotMappedHeapLoader.cpp#L403-L409 > > By storing the interned strings inside the heap roots array, we can get rid of the two-level ObjArray manipulation code in stringTables.cpp. Nice cleanup. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29459#pullrequestreview-3718102491 From sspitsyn at openjdk.org Wed Jan 28 18:40:01 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 18:40:01 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 15:59:58 GMT, Serguei Spitsyn wrote: >> Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen. > > Okay. Then what about this ? : > > if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event. > // The monitor waited events can be disabled while suspended. > { > ThreadBlockInVM tbvm(current, true); > } > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Just want to explain my concern better. At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_RUN`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is a `ThreadBlockInVM` for this case, so the thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended. However the event will be posted after suspension. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2737985956 From dholmes at openjdk.org Wed Jan 28 20:44:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 20:44:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn wrote: >> Okay. Then what about this ? : >> >> if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> // The monitor waited events can be disabled while suspended. >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (JvmtiExport::should_post_monitor_waited()) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Just want to explain my concern better. > At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. > If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_RUN`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. > If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > At the monitor notification point there is a check for JvmtiExport::should_post_monitor_waited(). > If it is false then the node.TState is set to ObjectWaiter::TS_RUN. > If it is true the node.TState is set to ObjectWaiter::TS_ENTER. @sspitsyn you have that the wrong way around. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738525236 From sspitsyn at openjdk.org Wed Jan 28 20:57:45 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 20:57:45 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn wrote: >> Okay. Then what about this ? : >> >> if (interruptible && node.TState != ObjectWaiter::TS_ENTER) { >> // Process suspend requests now if any, before posting the event. >> // The monitor waited events can be disabled while suspended. >> { >> ThreadBlockInVM tbvm(current, true); >> } >> if (JvmtiExport::should_post_monitor_waited()) { >> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); >> } > > Just want to explain my concern better. > At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. > If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. > If it is `true` the `node.TState` is set to `ObjectWaiter::TS_RUN`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > @sspitsyn you have that the wrong way around. Thanks! Corrected in place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738567428 From dholmes at openjdk.org Wed Jan 28 21:14:04 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Jan 2026 21:14:04 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 20:54:42 GMT, Serguei Spitsyn wrote: >> Just want to explain my concern better. >> At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`. >> If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case. >> If it is `true` the `node.TState` is set to `ObjectWaiter::TS_RUN`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation. > >> @sspitsyn you have that the wrong way around. > > Thanks! Corrected in place. Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738624642 From sspitsyn at openjdk.org Wed Jan 28 21:33:56 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Jan 2026 21:33:56 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:10:57 GMT, David Holmes wrote: > Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738696353 From iklam at openjdk.org Wed Jan 28 22:09:03 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 Jan 2026 22:09:03 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file Message-ID: The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. ------------- Depends on: https://git.openjdk.org/jdk/pull/29459 Commit messages: - dump heap oop in aot config file Changes: https://git.openjdk.org/jdk/pull/29472/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29472&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375569 Stats: 99 lines in 10 files changed: 73 ins; 9 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29472/head:pull/29472 PR: https://git.openjdk.org/jdk/pull/29472 From pchilanomate at openjdk.org Wed Jan 28 22:13:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Jan 2026 22:13:24 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be Message-ID: Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/29473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376405 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29473/head:pull/29473 PR: https://git.openjdk.org/jdk/pull/29473 From kvn at openjdk.org Wed Jan 28 23:43:29 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 Jan 2026 23:43:29 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:04:14 GMT, Ioi Lam wrote: > The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. > > However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: > > - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). > > As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. > > - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29472#pullrequestreview-3719699617 From duke at openjdk.org Thu Jan 29 00:09:26 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 29 Jan 2026 00:09:26 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v7] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Fix test failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/9999bf7b..4ce14eef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From dholmes at openjdk.org Thu Jan 29 00:22:01 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 00:22:01 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio So we are logically suspended (`is_suspended()` is true) but we haven't actually done a check for suspension that would cause us to actually block, due to the transition-disabler? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3814621640 From duke at openjdk.org Thu Jan 29 00:24:33 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 29 Jan 2026 00:24:33 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v8] In-Reply-To: References: Message-ID: > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > Testing has shown up to a 20% latency reduction in an internal service with a large CodeCache (512 MB). Public benchmark results are forthcoming. > > ### Testing > * CodeCache tests have been updated to cover the new `HotCodeHeap`. > * Added dedicated tests for the `HotCodeGrouper` > ... Chad Rakoczy has updated the pull request 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 30 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8326205 - Fix test failure - Fix builds - Fix merge - Merge remote-tracking branch 'origin/master' into JDK-8326205 - Add check for full HotCodeHeap - Add HotCodeGrouperMoveFunction test - Add StessHotCodeGrouper test - Update blob checks - Merge fix - ... and 20 more: https://git.openjdk.org/jdk/compare/d5e16db1...b5a5c71b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/4ce14eef..b5a5c71b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=06-07 Stats: 47318 lines in 1062 files changed: 23617 ins; 9713 del; 13988 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From dholmes at openjdk.org Thu Jan 29 01:42:32 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 01:42:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:30:15 GMT, Serguei Spitsyn wrote: >> Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > >> Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > > Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. > Update: I see your point. You most likely suggested something like this: > > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > // Re-check the condition as the monitor waited events can be disabled whilst thread was suspended. > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Yes that is what I meant. The event could have been disabled since the notification, in which case we don't need to bother with the TBIVM etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2739379031 From lmesnik at openjdk.org Thu Jan 29 01:43:41 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 Jan 2026 01:43:41 GMT Subject: RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote Message-ID: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> Hi Please review following fix that remove incorrect assertion. Verification should be always done for redefined classes, and is called `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class, TRAPS)` where `should_verify_class` and `is_eligible_for_verification` define if verification should be done or not. Thus, seems it doesn't make a sense to check `BytecodeVerificationRemote` during verification. Verified that class redefinition tests pass now with TEST_VM_OPTS="-XX:-BytecodeVerificationRemote" and fastdebug ------------- Commit messages: - 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote Changes: https://git.openjdk.org/jdk/pull/29476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376295 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29476/head:pull/29476 PR: https://git.openjdk.org/jdk/pull/29476 From dzhang at openjdk.org Thu Jan 29 02:01:00 2026 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 29 Jan 2026 02:01:00 GMT Subject: RFR: 8376572: RISC-V: Interpreter: Load array index as signed int In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:22:22 GMT, Feilong Jiang wrote: > Please consider. > We should use the `lw` instruction (which loads a 32-bit index from the operand stack and performs sign extension) instead of the `ld` instruction for the array index loading. > > Testing: > > - [x] tier1 with linux-riscv64 release build LGTM, thanks! ------------- Marked as reviewed by dzhang (Committer). PR Review: https://git.openjdk.org/jdk/pull/29458#pullrequestreview-3720116882 From dholmes at openjdk.org Thu Jan 29 02:33:11 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 02:33:11 GMT Subject: RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote In-Reply-To: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> References: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> Message-ID: <-Wdu_j4jW-ps3EsSXOA2gWy2rrE0-a13F4Qk9rIJdqE=.d317a55b-4de4-47b7-bf3e-b5a3444a3866@github.com> On Thu, 29 Jan 2026 01:35:57 GMT, Leonid Mesnik wrote: > Hi > > Please review following fix that remove incorrect assertion. > > Verification should be always done for redefined classes, and is called > `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class, TRAPS)` > where `should_verify_class` and `is_eligible_for_verification` define if verification should be done or not. > Thus, seems it doesn't make a sense to check `BytecodeVerificationRemote` during verification. > > Verified that class redefinition tests pass now with TEST_VM_OPTS="-XX:-BytecodeVerificationRemote" and fastdebug Changes requested by dholmes (Reviewer). src/hotspot/share/classfile/verifier.cpp line 625: > 623: > 624: // Either verifying both local and remote classes or just remote classes. > 625: assert(BytecodeVerificationRemote, "Should not be here"); Rather than deleting the assertion can we expand it: assert(BytecodeVerificationRemote || _klass->should_verify_class(), "Should not be here"); ? ------------- PR Review: https://git.openjdk.org/jdk/pull/29476#pullrequestreview-3720198386 PR Review Comment: https://git.openjdk.org/jdk/pull/29476#discussion_r2739496785 From dlong at openjdk.org Thu Jan 29 06:50:32 2026 From: dlong at openjdk.org (Dean Long) Date: Thu, 29 Jan 2026 06:50:32 GMT Subject: RFR: 8372845: C2: Fold identity hash code if object is constant [v6] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 03:43:15 GMT, Chen Liang wrote: >> src/hotspot/share/opto/library_call.cpp line 4791: >> >>> 4789: const TypeInstPtr* t = _gvn.type(obj)->isa_instptr(); >>> 4790: if (t != nullptr && t->const_oop() != nullptr) { >>> 4791: assert(!is_virtual, "no devirtualization for constant receiver?"); >> >> Don't we also need to check for `is_static`, to distinguish between `Object.hashCode` and `System.identityHashCode`? > > I think once we are not virtual, the native Object::hashCode behaves like System::identityHashCode. The only difference is null check, but I think there's a null check in the beginning so we should be safe. OK so if we get here we are guaranteed to be calling Object::hashCode and not a devirtualized MySubClass::hashCode? I guess the intrinsic lookup would fail if the callee was a subclass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2740204610 From lmesnik at openjdk.org Thu Jan 29 07:04:11 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 Jan 2026 07:04:11 GMT Subject: RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote In-Reply-To: <-Wdu_j4jW-ps3EsSXOA2gWy2rrE0-a13F4Qk9rIJdqE=.d317a55b-4de4-47b7-bf3e-b5a3444a3866@github.com> References: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> <-Wdu_j4jW-ps3EsSXOA2gWy2rrE0-a13F4Qk9rIJdqE=.d317a55b-4de4-47b7-bf3e-b5a3444a3866@github.com> Message-ID: On Thu, 29 Jan 2026 02:30:19 GMT, David Holmes wrote: >> Hi >> >> Please review following fix that remove incorrect assertion. >> >> Verification should be always done for redefined classes, and is called >> `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class, TRAPS)` >> where `should_verify_class` and `is_eligible_for_verification` define if verification should be done or not. >> Thus, seems it doesn't make a sense to check `BytecodeVerificationRemote` during verification. >> >> Verified that class redefinition tests pass now with TEST_VM_OPTS="-XX:-BytecodeVerificationRemote" and fastdebug > > src/hotspot/share/classfile/verifier.cpp line 625: > >> 623: >> 624: // Either verifying both local and remote classes or just remote classes. >> 625: assert(BytecodeVerificationRemote, "Should not be here"); > > Rather than deleting the assertion can we expand it: > > assert(BytecodeVerificationRemote || _klass->should_verify_class(), "Should not be here"); > > ? The `_klass->should_verify_class()` is false when class is redefined. The '_klass' in fresh "scratch class". So the `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class)` is called for "scratch_class" with `should_verify_class = true`. The `should_verify_class = true` is needed because it is not possible to just call `scratch_class->set_should_verify_class(true);` in the safepoint. The stacktrace: ClassVerifier::verify_class(JavaThread* (verifier.cpp:625) Verifier::verify(InstanceKlass*, bool`should_verify_class = true` , JavaThread*) (verifier.cpp:223) VM_RedefineClasses::load_new_class_versions() (jvmtiRedefineClasses.cpp:1459) VM_RedefineClasses::doit_prologue() (jvmtiRedefineClasses.cpp:1334) VMThread::execute(VM_Operation*) (vmThread.cpp:541) JvmtiEnv::RedefineClasses(int, jvmtiClassDefinition const*)+0x18a (jvmtiEnv.cpp:505) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29476#discussion_r2740235533 From fyang at openjdk.org Thu Jan 29 07:34:43 2026 From: fyang at openjdk.org (Fei Yang) Date: Thu, 29 Jan 2026 07:34:43 GMT Subject: RFR: 8376575: aarch64: incorrect array index load in aastore In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 15:03:58 GMT, Andrew Haley wrote: > This appears to me to be an odd thing to do for just this one case. For example, looking at iload and its varinats they all use a plain ldr. Would we not want to change them as well? Good find. I only identified this index case while porting JEP 401. I didn't check other variants. > The template methods that load an int from the stack or locals area get away with using ldr because an int is only available to load from those locations if it has been put on the stack or into a local as an int -- the bytecode verifier plus correctness of the store operations will guarantee that on aarch64. So, use of ldrw is not strictly needed -- it merely ensures we don't detect a store that uses str by mistake. I also checked `TemplateTable::istore()` and I find this FIXME code comment [1]. Then it seems to me like a performance consideration for the iload and its variants to use 64-bit `ldr`. The purpose is to save one instructions on load/store addressing. void TemplateTable::istore() { transition(itos, vtos); locals_index(r1); // FIXME: We're being very pernickerty here storing a jint in a // local with strw, which costs an extra instruction over what we'd // be able to do with a simple str. We should just store the whole // word. __ lea(rscratch1, iaddress(r1)); __ strw(r0, Address(rscratch1)); } [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp#L992 > If we are going to enforce this then maybe we should do it everywhere just to be consistent. Half and half is arguably more likely to confuse. So maybe we should keep other places for performance reasons since it works in functionality? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29464#issuecomment-3815962887 From duke at openjdk.org Thu Jan 29 08:01:52 2026 From: duke at openjdk.org (duke) Date: Thu, 29 Jan 2026 08:01:52 GMT Subject: Withdrawn: 8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:17:52 GMT, Justin King wrote: > Ensure the compiler cannot optimize the copy loops by replacing them with `memcpy` which is allowed to copy byte by byte potentially introducing tearing. Currently there is nothing preventing the compiler from doing this. We add `volatile` which prevents the compiler from making this optimization in the future. > > Currently the code generates to `ldp` and `stp`, this change does have the side affect of forcing it to do `ldr` and `str`. If that seems unacceptable from a performance standpoint we can hand-roll assembly to do `ldp` and `stp`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27647 From sspitsyn at openjdk.org Thu Jan 29 08:28:47 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 08:28:47 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v33] In-Reply-To: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> References: <3RAOfnxLHzM2-yhOApDdKKl9oHTJzowlJpP2oR6l3o8=.4d5358cd-c06e-4cdd-9731-90e5359d4af5@github.com> Message-ID: On Wed, 28 Jan 2026 09:26:17 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8366659: Indentation fix. > - 8366659: Addressed reviewer's comments. I only have one minor change request. The fix looks good otherwise. Overall, it is a great work to sort this out. Thank you for your patience. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3721312113 From aartemov at openjdk.org Thu Jan 29 08:52:42 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 08:52:42 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] 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 following liveness issues can happen in the `ObjectMonitor::wait()` method. > > 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 three 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 > > 3: > https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 > > 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. > > Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. > > Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. > > Tests are added. > > Tested in tiers 1 - 7. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8366659: Extra check before posting the waited event. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27040/files - new: https://git.openjdk.org/jdk/pull/27040/files/6620a88f..c3f934b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=32-33 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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 aartemov at openjdk.org Thu Jan 29 08:52:43 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 08:52:43 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31] In-Reply-To: References: <-Wi_15UtJPLlWwYKKhoKKLvuoWe2vA7aW3dRBiTkETY=.b0d46ce9-5bd9-43fb-b059-ebc1e5a67ea0@github.com> <4W6eKGdTrP0xGkQ4GZAs5XPmGCAquVUGrMeGMcVWs-E=.d6619da2-20cc-4f91-a254-e9f016830258@github.com> <2aydu_siSxE_Jjep2YMsugyYoiRcmLHuePyHZB3qCyk=.fa0a7493-244d-4464-b87c-724971bee2d9@github.com> <_S0Fq0Dct6lJjH3Tn2_9Ew2ywoq0w3mKQx-oU5Zpo7I=.439c5e1e-bd63-4eba-8fd5-7868f6f29ac1@github.com> Message-ID: On Wed, 28 Jan 2026 21:30:15 GMT, Serguei Spitsyn wrote: >> Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > >> Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. > > Not sure, I fully understand this. The suspend point in TBIVM is where the event can be enabled or disabled. > Update: I see your point. You most likely suggested something like this: > > if (interruptible && JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) { > // Process suspend requests now if any, before posting the event > { > ThreadBlockInVM tbvm(current, true); > } > // Re-check the condition as the monitor waited events can be disabled whilst thread was suspended. > if (JvmtiExport::should_post_monitor_waited()) { > JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT); > } Thanks @sspitsyn, I added that extra check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2740557790 From sspitsyn at openjdk.org Thu Jan 29 08:56:32 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 08:56:32 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3721429996 From shade at openjdk.org Thu Jan 29 09:04:51 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Jan 2026 09:04:51 GMT Subject: RFR: 8376523: Move interned strings into AOT heap roots array In-Reply-To: References: Message-ID: <-yG4ISNpzhS_BD4zK-efNlPqkVmvRlcRxthkyOsUGiQ=.bbea8692-083d-4b10-8800-f8669148416e@github.com> On Wed, 28 Jan 2026 06:50:47 GMT, Ioi Lam wrote: > This is a small clean up that deletes about 200 lines of code. > > With AOTMappedHeapLoader, the interned strings are stored inside a cached ObjArray. Because cached ObjArrays cannot be larger than 256KB, we need to split this ObjArray into two levels when there are a lot of interned strings > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/classfile/stringTable.cpp#L81-L93 > > However, we already have a similar mechanism for storing heap roots in multiple ObjArrays that are no larger than 256KB: > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/cds/aotMappedHeapLoader.cpp#L403-L409 > > By storing the interned strings inside the heap roots array, we can get rid of the two-level ObjArray manipulation code in stringTables.cpp. I agree, very nice cleanup. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29459#pullrequestreview-3721455703 From stuefe at openjdk.org Thu Jan 29 09:14:51 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:14:51 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: References: Message-ID: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> On Fri, 12 Dec 2025 15:49:20 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. >> >> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. >> >> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. >> >> Testing: >> - Oracle tiers 1-8 > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into blocktree-intrusive > - Merge branch 'master' into blocktree-intrusive > - moved blocktree tree logic to intrusive rbtree Its shaping up nicely. Sorry for the long delays. src/hotspot/share/memory/metaspace/blockTree.cpp line 91: > 89: > 90: // Verifies node ordering (n1 < n2 => word_size1 < word_size2), > 91: // node vadility, and that the tree is balanced and not ill-formed. Question: in verify_self, what is the point of having `empty_verifier` as default arg for the verifier? (Unless its as a blueprint for copy pasting when writing an actual verifier)? src/hotspot/share/memory/metaspace/blockTree.cpp line 101: > 99: tree_assert_invalid_node(n->_word_size >= MinWordSize, n); > 100: tree_assert_invalid_node(n->_word_size <= chunklevel::MAX_CHUNK_WORD_SIZE, n); > 101: Can you leave the depth assert in, please? I understand that we should not degenerate anymore, but that depends on the tree working correctly. Can circularities not happen? User may still accidentally add a block twice. src/hotspot/share/memory/metaspace/blockTree.cpp line 136: > 134: } > 135: > 136: _tree.print_on(st, [&](outputStream *st, const TreeNode *tree_node, int depth) { Side note: It may be my unfamiliarity with heavily templated code, but I often find it difficult to deduce the interface a lambda function must implement from the prototype of the lambda-invoking function. As in this case, the printer function in `AbstractRBTree::print_node_on` resp. `AbstractRBTree::print_on`. Without finding and analyzing the invocation point, one does not know what the parameters have to be, or? It would be nice if there was a way to have this. Eg. as a prototype comment above the functions taking lambdas as parameters. src/hotspot/share/memory/metaspace/blockTree.cpp line 162: > 160: info2.depth = info.depth + 1; > 161: stack.push(info2); > 162: } Here we loose a bunch of verifications - basically all that compare with child nodes and the parent. I assume tests for this exist somewhere else, or that the verify_self does that already? src/hotspot/share/memory/metaspace/blockTree.hpp line 46: > 44: // > 45: // We store node pointer information in these blocks when storing them. That > 46: // imposes a minimum size to the managed memory blocks (1 word) Preexisting: I think the "1 word" comment was never correct, it was probably copy-pasted from the segregated fits lists I use for very small blocks. This should read `(1 MinWordSize)` src/hotspot/share/memory/metaspace/blockTree.hpp line 74: > 72: // swap payloads of their nodes at some point, see e.g. j.u.TreeSet). > 73: // A good example is the Linux kernel rbtree, which is a clean, easy-to-read > 74: // implementation. Nice to get rid of this comment :-) src/hotspot/share/memory/metaspace/blockTree.hpp line 93: > 91: // Word size of node. Note that size cannot be larger than max metaspace size, > 92: // so this could be very well a 32bit value (in case we ever make this a balancing > 93: // tree and need additional space for weighting information). Can you adjust this comment? The possible change to 32bit is still valid, but we now balance, so the rest can be removed. src/hotspot/share/memory/metaspace/blockTree.hpp line 131: > 129: if (a_word_size < b_word_size) { return true; } > 130: return false; > 131: } Why do I need both functions? And sort order of tree is stable, right? So, the relevant sorting is only done with `cmp`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27212#pullrequestreview-3721362395 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740527554 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740541792 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740582734 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740551692 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740643409 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740592751 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740632528 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740614780 From stuefe at openjdk.org Thu Jan 29 09:14:52 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:14:52 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> Message-ID: <6jpguv6O-VCQN7XZ3xjA8cJppWPhYp5U2HdkMr51C-M=.d61dd892-572b-4789-9317-76410b332047@github.com> On Thu, 29 Jan 2026 08:41:19 GMT, Thomas Stuefe wrote: >> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into blocktree-intrusive >> - Merge branch 'master' into blocktree-intrusive >> - moved blocktree tree logic to intrusive rbtree > > src/hotspot/share/memory/metaspace/blockTree.cpp line 101: > >> 99: tree_assert_invalid_node(n->_word_size >= MinWordSize, n); >> 100: tree_assert_invalid_node(n->_word_size <= chunklevel::MAX_CHUNK_WORD_SIZE, n); >> 101: > > Can you leave the depth assert in, please? I understand that we should not degenerate anymore, but that depends on the tree working correctly. Can circularities not happen? User may still accidentally add a block twice. Or is this tested inside tree::verify_self? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740543603 From stuefe at openjdk.org Thu Jan 29 09:14:54 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:14:54 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: References: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> Message-ID: On Thu, 9 Oct 2025 07:08:38 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/memory/metaspace/blockTree.hpp line 105: >> >>> 103: static Node* cast_to_node(const TreeNode* tree_node) { >>> 104: return (Node*)((uintptr_t)tree_node - offset_of(Node, _tree_node)); >>> 105: } >> >> We should really have this as a separate static function for the IntrusiveRBNode. It's also technically not a cast, it finds the outer data. > > We could use inheritance `struct Node : public IntrusiveRBNode` and actually have it be a cast. Simplifies some things, not sure if we see other issues. But seems like a valid abstraction that the BlockTree Node is a IntrusiveRBNode. > > We should probably do an assert that the node is valid() here (Should catch if any none Node IntrusiveRBNode ended up here). Can't we add the canary to the TreeNode instead? It would be a useful general feature. Maybe as a separate RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740601525 From stuefe at openjdk.org Thu Jan 29 09:39:25 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 09:39:25 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v4] In-Reply-To: References: <93J0DXbDwwQDYqasv9f9lF4NofBWMLb4NTiyMCXkdsM=.bc351bf6-8408-4c4d-990d-99df03a21649@github.com> Message-ID: On Fri, 23 Jan 2026 14:59:45 GMT, Ivan Bereziuk wrote: > The timestamping implemented in JCmd.java would print timestamp only once at the beginning. Good point. For me the biggest point would be to cleanly correlate time in logs, e.g. gc logs, with time from command invocations the analyst or customer does. Without wondering about offsets. > We also have DiagnosticCommandMBean for remove invokation. Keeping this timestamp on the client side means we don't need a project to look into what could happen there. Also good point. I know I am of no help here :-D My gut instinct is to keep jcmd client side simple and stupid, and put logic like this into hotspot. But I can live with both solutions. Having a timestamp always printed will be a good thing in any case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3816525840 From cnorrbin at openjdk.org Thu Jan 29 10:07:05 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:07:05 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> Message-ID: <0vqJdfkvkKbQXXJLixebSlEBlanKYxuw8O7DS5BBqck=.26a61b07-7dd3-4eb4-85c8-12389e66f84c@github.com> On Thu, 29 Jan 2026 08:37:09 GMT, Thomas Stuefe wrote: >> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into blocktree-intrusive >> - Merge branch 'master' into blocktree-intrusive >> - moved blocktree tree logic to intrusive rbtree > > src/hotspot/share/memory/metaspace/blockTree.cpp line 91: > >> 89: >> 90: // Verifies node ordering (n1 < n2 => word_size1 < word_size2), >> 91: // node vadility, and that the tree is balanced and not ill-formed. > > Question: in verify_self, what is the point of having `empty_verifier` as default arg for the verifier? (Unless its as a blueprint for copy pasting when writing an actual verifier)? It is for if you have no need for extra validation. Using `empty_verifier` (calling `_tree.verify_self()`) we still validate that all tree properties hold. The extra verifier is for providing additional user-defined validation, like in this case with the `MemRangeCounter` and checking same-sized blocks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740868240 From cnorrbin at openjdk.org Thu Jan 29 10:11:16 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:11:16 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <6jpguv6O-VCQN7XZ3xjA8cJppWPhYp5U2HdkMr51C-M=.d61dd892-572b-4789-9317-76410b332047@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> <6jpguv6O-VCQN7XZ3xjA8cJppWPhYp5U2HdkMr51C-M=.d61dd892-572b-4789-9317-76410b332047@github.com> Message-ID: <3NeuHp9W7n4NEUZ3HLEeqFsDjI72cMA4JmSheDP2pC4=.9d80de60-5792-43ee-8dd0-e195286ed635@github.com> On Thu, 29 Jan 2026 08:41:49 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/blockTree.cpp line 101: >> >>> 99: tree_assert_invalid_node(n->_word_size >= MinWordSize, n); >>> 100: tree_assert_invalid_node(n->_word_size <= chunklevel::MAX_CHUNK_WORD_SIZE, n); >>> 101: >> >> Can you leave the depth assert in, please? I understand that we should not degenerate anymore, but that depends on the tree working correctly. Can circularities not happen? User may still accidentally add a block twice. > > Or is this tested inside tree::verify_self? In `verify_self()` we both test that the tree is balanced and that each node appears exactly once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740883325 From cnorrbin at openjdk.org Thu Jan 29 10:17:43 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:17:43 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> Message-ID: <66FvJ6zMu8_tCXuwCL487r7lmVJZKuUT8F0meycJ6qM=.ee4151f7-2e28-4c9f-8fd2-a89e038b6ecf@github.com> On Thu, 29 Jan 2026 08:52:50 GMT, Thomas Stuefe wrote: >> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into blocktree-intrusive >> - Merge branch 'master' into blocktree-intrusive >> - moved blocktree tree logic to intrusive rbtree > > src/hotspot/share/memory/metaspace/blockTree.cpp line 136: > >> 134: } >> 135: >> 136: _tree.print_on(st, [&](outputStream *st, const TreeNode *tree_node, int depth) { > > Side note: It may be my unfamiliarity with heavily templated code, but I often find it difficult to deduce the interface a lambda function must implement from the prototype of the lambda-invoking function. > > As in this case, the printer function in `AbstractRBTree::print_node_on` resp. `AbstractRBTree::print_on`. Without finding and analyzing the invocation point, one does not know what the parameters have to be, or? > > It would be nice if there was a way to have this. Eg. as a prototype comment above the functions taking lambdas as parameters. There is this comment already above `AbstractRBTree::print_on` in `rbTree.hpp`, do you feel that is clear enough? // Accepts an optional printing callable `void node_printer(outputStream* st, const Node* n, int depth)`. // If provided, each node is printed through this callable rather than the default `print_on`. > src/hotspot/share/memory/metaspace/blockTree.cpp line 162: > >> 160: info2.depth = info.depth + 1; >> 161: stack.push(info2); >> 162: } > > Here we loose a bunch of verifications - basically all that compare with child nodes and the parent. I assume tests for this exist somewhere else, or that the verify_self does that already? `verify_self()` already does this! It compares child and parent node order and ensures pointers are correct. The node word size comparisons are kept, as the tree cannot test for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740905277 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740894556 From jsjolen at openjdk.org Thu Jan 29 10:19:41 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Jan 2026 10:19:41 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 09:02:19 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build LGTM, but please add the comment that Thomas suggested, I thought it was a good idea. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28503#pullrequestreview-3721820649 From cnorrbin at openjdk.org Thu Jan 29 10:27:16 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:27:16 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> Message-ID: On Thu, 29 Jan 2026 09:01:29 GMT, Thomas Stuefe wrote: >> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into blocktree-intrusive >> - Merge branch 'master' into blocktree-intrusive >> - moved blocktree tree logic to intrusive rbtree > > src/hotspot/share/memory/metaspace/blockTree.hpp line 131: > >> 129: if (a_word_size < b_word_size) { return true; } >> 130: return false; >> 131: } > > Why do I need both functions? > > And sort order of tree is stable, right? So, the relevant sorting is only done with `cmp`? `less_than` is only used during validation to ensure nodes are ordered correctly (You could omit it and we would just not do that check). All relevant sorting is only done with `cmp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2740946384 From cnorrbin at openjdk.org Thu Jan 29 10:45:07 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:45:07 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: References: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> Message-ID: On Thu, 29 Jan 2026 08:57:50 GMT, Thomas Stuefe wrote: >> We could use inheritance `struct Node : public IntrusiveRBNode` and actually have it be a cast. Simplifies some things, not sure if we see other issues. But seems like a valid abstraction that the BlockTree Node is a IntrusiveRBNode. >> >> We should probably do an assert that the node is valid() here (Should catch if any none Node IntrusiveRBNode ended up here). > > Can't we add the canary to the TreeNode instead? It would be a useful general feature. Maybe as a separate RFE. The problem with inheriting from `IntrusiveRBNode` is the canary then getting placed in the middle. We could move it to `IntrusiveRBNode`. That would solve it, but would also inflate its size by 33%. Here, we have space to spare, but it could potentially negatively impact other places the tree is used, as every single tree node (intrusive or not) would then become bigger. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2741015146 From cnorrbin at openjdk.org Thu Jan 29 10:59:40 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:59:40 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v3] In-Reply-To: References: Message-ID: > Hi everyone, > > Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. > > This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. > > Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. > > Testing: > - Oracle tiers 1-8 Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - feedback fixes - Merge branch 'master' into blocktree-intrusive - Merge branch 'master' into blocktree-intrusive - Merge branch 'master' into blocktree-intrusive - moved blocktree tree logic to intrusive rbtree ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27212/files - new: https://git.openjdk.org/jdk/pull/27212/files/fd0571a0..455c701d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27212&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27212&range=01-02 Stats: 116331 lines in 4191 files changed: 60653 ins; 21808 del; 33870 mod Patch: https://git.openjdk.org/jdk/pull/27212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27212/head:pull/27212 PR: https://git.openjdk.org/jdk/pull/27212 From cnorrbin at openjdk.org Thu Jan 29 10:59:41 2026 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 29 Jan 2026 10:59:41 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> Message-ID: On Thu, 29 Jan 2026 09:11:22 GMT, Thomas Stuefe wrote: > Its shaping up nicely. Sorry for the long delays. Thank you for the review! I just pushed some changes to comments. Hopefully I answered all your questions, but please let me know if there is anything that is still unclear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3816925386 From stuefe at openjdk.org Thu Jan 29 10:59:43 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 10:59:43 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v2] In-Reply-To: <0vqJdfkvkKbQXXJLixebSlEBlanKYxuw8O7DS5BBqck=.26a61b07-7dd3-4eb4-85c8-12389e66f84c@github.com> References: <5968ETIB9A5fEFso4lmXBXKTwBu57KiOOZF8A3A63bI=.4c3e73c6-56d2-46e1-872e-450ec51e7293@github.com> <0vqJdfkvkKbQXXJLixebSlEBlanKYxuw8O7DS5BBqck=.26a61b07-7dd3-4eb4-85c8-12389e66f84c@github.com> Message-ID: <_9FgjmJ_W9Fgs-9tNHs1gvkkkXc-rTATZFBi6-qXfAE=.8f0bd0ed-938e-45ff-8c37-08fdca201d8a@github.com> On Thu, 29 Jan 2026 10:04:22 GMT, Casper Norrbin wrote: >> src/hotspot/share/memory/metaspace/blockTree.cpp line 91: >> >>> 89: >>> 90: // Verifies node ordering (n1 < n2 => word_size1 < word_size2), >>> 91: // node vadility, and that the tree is balanced and not ill-formed. >> >> Question: in verify_self, what is the point of having `empty_verifier` as default arg for the verifier? (Unless its as a blueprint for copy pasting when writing an actual verifier)? > > It is for if you have no need for extra validation. Using `empty_verifier` (calling `_tree.verify_self()`) we still validate that all tree properties hold. The extra verifier is for providing additional user-defined validation, like in this case with the `MemRangeCounter` and checking same-sized blocks. Ah. Should have read the comment. >> src/hotspot/share/memory/metaspace/blockTree.cpp line 136: >> >>> 134: } >>> 135: >>> 136: _tree.print_on(st, [&](outputStream *st, const TreeNode *tree_node, int depth) { >> >> Side note: It may be my unfamiliarity with heavily templated code, but I often find it difficult to deduce the interface a lambda function must implement from the prototype of the lambda-invoking function. >> >> As in this case, the printer function in `AbstractRBTree::print_node_on` resp. `AbstractRBTree::print_on`. Without finding and analyzing the invocation point, one does not know what the parameters have to be, or? >> >> It would be nice if there was a way to have this. Eg. as a prototype comment above the functions taking lambdas as parameters. > > There is this comment already above `AbstractRBTree::print_on` in `rbTree.hpp`, do you feel that is clear enough? > > > // Accepts an optional printing callable `void node_printer(outputStream* st, const Node* n, int depth)`. > // If provided, each node is printed through this callable rather than the default `print_on`. Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2741050064 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2741053549 From azafari at openjdk.org Thu Jan 29 11:02:30 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 29 Jan 2026 11:02:30 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v3] In-Reply-To: References: Message-ID: > Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. > Checking the integrity of memory blocks is off under ASAN builds. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - added a comment for block integrity check switch - Merge remote-tracking branch 'origin' into asan_poison_malloc_hdr_ftr_v2 - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 - removed extra newlines. - fixes. - inlining - review comments applied. - revision - jtreg test excluded when ASAN is enabled. - 8369393: NMT: poison the malloc header and footer under ASAN build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28503/files - new: https://git.openjdk.org/jdk/pull/28503/files/b452979e..0fe2059f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=01-02 Stats: 110494 lines in 4252 files changed: 57167 ins; 19186 del; 34141 mod Patch: https://git.openjdk.org/jdk/pull/28503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28503/head:pull/28503 PR: https://git.openjdk.org/jdk/pull/28503 From azafari at openjdk.org Thu Jan 29 11:02:31 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 29 Jan 2026 11:02:31 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 14:08:46 GMT, Thomas Stuefe wrote: >> Dear @tstuefe, >> After your last comments on the previous version of this change, I have re-implemented the poisoning in a way aligned to your concerns. Please have a look and let me know if something is missed or can be improved. TIA > >> Dear @tstuefe, After your last comments on the previous version of this change, I have re-implemented the poisoning in a way aligned to your concerns. Please have a look and let me know if something is missed or can be improved. TIA > > Hi @afshin-zafari , I currently do not have the bandwidth to review this in depth. At first glance, omitting the integrity checks for ASAN is better, thanks for that. I don't want to hold this PR up. If @jdksjolen is fine with this change, that is good to me too. Thank you @tstuefe, @jdksjolen and @Arraying for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28503#issuecomment-3816924872 From azafari at openjdk.org Thu Jan 29 11:02:37 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 29 Jan 2026 11:02:37 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 14:03:09 GMT, Thomas Stuefe wrote: >> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 >> - removed extra newlines. >> - fixes. >> - inlining >> - review comments applied. >> - revision >> - jtreg test excluded when ASAN is enabled. >> - 8369393: NMT: poison the malloc header and footer under ASAN build > > src/hotspot/share/nmt/mallocHeader.hpp line 36: > >> 34: >> 35: #if INCLUDE_ASAN >> 36: #undef NMT_BLOCK_INTEGRITY_CHECKS > > Can you add a comment like this: > > // With ASAN, we omit NMT block integrity checks since ASAN does a better and faster > // job of alerting us to memory corruptions Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2741073289 From dholmes at openjdk.org Thu Jan 29 12:03:31 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 12:03:31 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. I think that is everything from me. Thanks. It has been a very tricky one to work through. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3722268994 From dholmes at openjdk.org Thu Jan 29 12:06:46 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 12:06:46 GMT Subject: RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote In-Reply-To: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> References: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> Message-ID: On Thu, 29 Jan 2026 01:35:57 GMT, Leonid Mesnik wrote: > Hi > > Please review following fix that remove incorrect assertion. > > Verification should be always done for redefined classes, and is called > `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class, TRAPS)` > where `should_verify_class` and `is_eligible_for_verification` define if verification should be done or not. > Thus, seems it doesn't make a sense to check `BytecodeVerificationRemote` during verification. > > Verified that class redefinition tests pass now with TEST_VM_OPTS="-XX:-BytecodeVerificationRemote" and fastdebug Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29476#pullrequestreview-3722281722 From dholmes at openjdk.org Thu Jan 29 12:06:48 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 12:06:48 GMT Subject: RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote In-Reply-To: References: <9OsGWWKHOFaLBT3xhaq-RMnrO7rUc2aq-reCXh4GJV4=.ae5dfcd5-6fa6-4981-a346-652e12b98d5e@github.com> <-Wdu_j4jW-ps3EsSXOA2gWy2rrE0-a13F4Qk9rIJdqE=.d317a55b-4de4-47b7-bf3e-b5a3444a3866@github.com> Message-ID: On Thu, 29 Jan 2026 07:00:00 GMT, Leonid Mesnik wrote: >> src/hotspot/share/classfile/verifier.cpp line 625: >> >>> 623: >>> 624: // Either verifying both local and remote classes or just remote classes. >>> 625: assert(BytecodeVerificationRemote, "Should not be here"); >> >> Rather than deleting the assertion can we expand it: >> >> assert(BytecodeVerificationRemote || _klass->should_verify_class(), "Should not be here"); >> >> ? > > The > `_klass->should_verify_class()` > is false when class is redefined. > The '_klass' in fresh "scratch class". So the `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class)` is called for "scratch_class" with `should_verify_class = true`. > The `should_verify_class = true` is needed because it is not possible to just call > `scratch_class->set_should_verify_class(true);` > in the safepoint. > > The stacktrace: > ClassVerifier::verify_class(JavaThread* (verifier.cpp:625) > Verifier::verify(InstanceKlass*, bool`should_verify_class = true` , JavaThread*) (verifier.cpp:223) > VM_RedefineClasses::load_new_class_versions() (jvmtiRedefineClasses.cpp:1459) > VM_RedefineClasses::doit_prologue() (jvmtiRedefineClasses.cpp:1334) > VMThread::execute(VM_Operation*) (vmThread.cpp:541) > JvmtiEnv::RedefineClasses(int, jvmtiClassDefinition const*)+0x18a (jvmtiEnv.cpp:505) Okay that is a pity. Thanks for explaining. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29476#discussion_r2741307164 From phubner at openjdk.org Thu Jan 29 12:11:18 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Thu, 29 Jan 2026 12:11:18 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:02:30 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - added a comment for block integrity check switch > - Merge remote-tracking branch 'origin' into asan_poison_malloc_hdr_ftr_v2 > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build Marked as reviewed by phubner (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28503#pullrequestreview-3722297574 From azafari at openjdk.org Thu Jan 29 12:11:42 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 29 Jan 2026 12:11:42 GMT Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure [v7] In-Reply-To: References: Message-ID: <64IhzMPugOmnhyBeJxjbYjfSh05pHI6Ld7Q1o9Q79O0=.18a295ba-11ca-4de4-945a-42fedd940c00@github.com> > The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`. > > Tests: > tiers1-5, main platforms, debug/product Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge remote-tracking branch 'origin' into _8366241_nmt_consolidate_structures - improved the VMR ctor for committed regions - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures - fixes - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures - master merge fix - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures - after merge with 8366363. - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures - ... and 1 more: https://git.openjdk.org/jdk/compare/681e4ec8...2d3faec1 ------------- Changes: https://git.openjdk.org/jdk/pull/27137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=06 Stats: 202 lines in 12 files changed: 40 ins; 93 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/27137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27137/head:pull/27137 PR: https://git.openjdk.org/jdk/pull/27137 From phubner at openjdk.org Thu Jan 29 12:25:29 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Thu, 29 Jan 2026 12:25:29 GMT Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure [v7] In-Reply-To: <64IhzMPugOmnhyBeJxjbYjfSh05pHI6Ld7Q1o9Q79O0=.18a295ba-11ca-4de4-945a-42fedd940c00@github.com> References: <64IhzMPugOmnhyBeJxjbYjfSh05pHI6Ld7Q1o9Q79O0=.18a295ba-11ca-4de4-945a-42fedd940c00@github.com> Message-ID: On Thu, 29 Jan 2026 12:11:42 GMT, Afshin Zafari wrote: >> The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`. >> >> Tests: >> tiers1-5, main platforms, debug/product > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge remote-tracking branch 'origin' into _8366241_nmt_consolidate_structures > - improved the VMR ctor for committed regions > - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures > - fixes > - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures > - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures > - master merge fix > - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures > - after merge with 8366363. > - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures > - ... and 1 more: https://git.openjdk.org/jdk/compare/681e4ec8...2d3faec1 Thanks for doing this and taking the feedback into account. There are a few places that use old variable names, I've highlighted a couple but I'm sure there are more. Overall, this looks good. src/hotspot/share/nmt/memReporter.cpp line 404: > 402: } > 403: > 404: void MemDetailReporter::report_virtual_memory_region(const VirtualMemoryRegion* reserved_rgn) { Nit: it's no longer `reserved_rgn` it's more like `memory_rgn`. src/hotspot/share/nmt/regionsTree.inline.hpp line 41: > 39: NodeHelper curr(node); > 40: if (prev.is_valid() && prev.is_committed_begin()) { > 41: VirtualMemoryRegion cmr((address)prev.position(), Nit: variable name. ------------- Marked as reviewed by phubner (Author). PR Review: https://git.openjdk.org/jdk/pull/27137#pullrequestreview-3722347788 PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2741365700 PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2741370810 From bulasevich at openjdk.org Thu Jan 29 12:38:12 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 29 Jan 2026 12:38:12 GMT Subject: RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 17:21:48 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. > > Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: > > Move runtime image check to early VM init > > Suggested-by: Ioi Lam Good. Ioi, David, thanks for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3817376779 From bulasevich at openjdk.org Thu Jan 29 12:40:58 2026 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 29 Jan 2026 12:40:58 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 48846744 Author: Boris Ulasevich URL: https://git.openjdk.org/jdk/commit/48846744ca96ce3c6464a1a440b9e46119dfbb88 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8374343: Fix SIGSEGV when lib/modules is unreadable Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28982 From azafari at openjdk.org Thu Jan 29 13:35:58 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 29 Jan 2026 13:35:58 GMT Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure [v8] In-Reply-To: References: Message-ID: > The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`. > > Tests: > tiers1-5, main platforms, debug/product Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: rmr/cmr/vmr --> rgn or crgn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27137/files - new: https://git.openjdk.org/jdk/pull/27137/files/2d3faec1..31c2ffe5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=06-07 Stats: 157 lines in 7 files changed: 0 ins; 1 del; 156 mod Patch: https://git.openjdk.org/jdk/pull/27137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27137/head:pull/27137 PR: https://git.openjdk.org/jdk/pull/27137 From stuefe at openjdk.org Thu Jan 29 14:35:27 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 14:35:27 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:59:40 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. >> >> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. >> >> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. >> >> Testing: >> - Oracle tiers 1-8 > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - feedback fixes > - Merge branch 'master' into blocktree-intrusive > - Merge branch 'master' into blocktree-intrusive > - Merge branch 'master' into blocktree-intrusive > - moved blocktree tree logic to intrusive rbtree All good. Thanks for doing this! Let's ship this now, to get some reasonable baking time before 27 is done. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27212#pullrequestreview-3722314770 From stuefe at openjdk.org Thu Jan 29 14:35:28 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 14:35:28 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v3] In-Reply-To: References: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> Message-ID: On Thu, 29 Jan 2026 10:41:20 GMT, Casper Norrbin wrote: >> Can't we add the canary to the TreeNode instead? It would be a useful general feature. Maybe as a separate RFE. > > The problem with inheriting from `IntrusiveRBNode` is the canary then getting placed in the middle. We could move it to `IntrusiveRBNode`. That would solve it, but would also inflate its size by 33%. Here, we have space to spare, but it could potentially negatively impact other places the tree is used, as every single tree node (intrusive or not) would then become bigger. But a general canary facility in the rb tree itself would be nice. Okay. Pity that it would affect non-intrusive nodes. A canary in the user payload structure is maybe not that useful anyway, since we walk the tree down to the node and only then call the user verification method, right? So any overwrite of the first bytes would already have crashed or misfunctioned before? Otherwise, I think moving the canaries to after the node pointers would be an okay compromise. --- But I approve now, patch is fine as it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2741336527 From iveresov at openjdk.org Thu Jan 29 14:41:34 2026 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 29 Jan 2026 14:41:34 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file In-Reply-To: References: Message-ID: <6KLgPNoSONCRKCiDF79CKyuH606ZB4LrrBI18uumq_k=.48a5058a-9e82-4b1e-bc25-3df17683af31@github.com> On Wed, 28 Jan 2026 21:04:14 GMT, Ioi Lam wrote: > The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. > > However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: > > - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). > > As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. > > - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. Looks good ------------- Marked as reviewed by iveresov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29472#pullrequestreview-3723154730 From jsjolen at openjdk.org Thu Jan 29 14:44:39 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Jan 2026 14:44:39 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:59:40 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. >> >> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. >> >> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. >> >> Testing: >> - Oracle tiers 1-8 > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - feedback fixes > - Merge branch 'master' into blocktree-intrusive > - Merge branch 'master' into blocktree-intrusive > - Merge branch 'master' into blocktree-intrusive > - moved blocktree tree logic to intrusive rbtree Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27212#pullrequestreview-3723164793 From sspitsyn at openjdk.org Thu Jan 29 15:52:06 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Jan 2026 15:52:06 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio Looks good. Strangely, I did not see this assert in my testing when the ThreadStateTest2 test was introduced. :) ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3723550698 From iklam at openjdk.org Thu Jan 29 16:29:34 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 16:29:34 GMT Subject: RFR: 8376523: Move interned strings into AOT heap roots array In-Reply-To: References: Message-ID: <9kzkk-sk9V_tKgFcLgCsg3nPKzy5gJAWX12PuGKkXpg=.3be3f808-c48f-4999-a620-f532afa0e4ca@github.com> On Wed, 28 Jan 2026 17:43:21 GMT, Vladimir Kozlov wrote: >> This is a small clean up that deletes about 200 lines of code. >> >> With AOTMappedHeapLoader, the interned strings are stored inside a cached ObjArray. Because cached ObjArrays cannot be larger than 256KB, we need to split this ObjArray into two levels when there are a lot of interned strings >> >> https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/classfile/stringTable.cpp#L81-L93 >> >> However, we already have a similar mechanism for storing heap roots in multiple ObjArrays that are no larger than 256KB: >> >> https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/cds/aotMappedHeapLoader.cpp#L403-L409 >> >> By storing the interned strings inside the heap roots array, we can get rid of the two-level ObjArray manipulation code in stringTables.cpp. > > Nice cleanup. Thanks @vnkozlov and @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29459#issuecomment-3818782422 From iklam at openjdk.org Thu Jan 29 16:33:17 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 16:33:17 GMT Subject: Integrated: 8376523: Move interned strings into AOT heap roots array In-Reply-To: References: Message-ID: <51X35FhkIRpSXMACbpnXvrGZnowm8DQV3E-gw4Jvsz0=.4a85a975-d547-4a7e-8001-7155359bcc38@github.com> On Wed, 28 Jan 2026 06:50:47 GMT, Ioi Lam wrote: > This is a small clean up that deletes about 200 lines of code. > > With AOTMappedHeapLoader, the interned strings are stored inside a cached ObjArray. Because cached ObjArrays cannot be larger than 256KB, we need to split this ObjArray into two levels when there are a lot of interned strings > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/classfile/stringTable.cpp#L81-L93 > > However, we already have a similar mechanism for storing heap roots in multiple ObjArrays that are no larger than 256KB: > > https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/src/hotspot/share/cds/aotMappedHeapLoader.cpp#L403-L409 > > By storing the interned strings inside the heap roots array, we can get rid of the two-level ObjArray manipulation code in stringTables.cpp. This pull request has now been integrated. Changeset: a54ff1bf Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/a54ff1bff45e1cb30100cbaa253494c3462f7abd Stats: 236 lines in 7 files changed: 7 ins; 209 del; 20 mod 8376523: Move interned strings into AOT heap roots array Reviewed-by: kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/29459 From phubner at openjdk.org Thu Jan 29 16:38:23 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Thu, 29 Jan 2026 16:38:23 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 13:25:51 GMT, Joel Sikstr?m wrote: >> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision: >> >> Ignore inlining with MSVC. > > test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarf.c line 35: > >> 33: __attribute__((noinline)) >> 34: #endif >> 35: void foo(int x) { > > Now that we are explicitly NOT inlining this method, we could follow-up with simplifying this instead of doing "some random things" as the old comment stated. Good idea, I'll see if I can simplify it a bit while retaining the same semantics. > test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 46: > >> 44: #if !defined(_MSC_VER) >> 45: __attribute__((noinline)) >> 46: #endif > > If I understand this correctly, we relied upon this not being inlined before, but now we want to guarantee this. This is so that we can check that the line-numer in the produced hs_err matches the line-numer in this file to see that we crash at the "correct" place. Yep! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29451#discussion_r2742535323 PR Review Comment: https://git.openjdk.org/jdk/pull/29451#discussion_r2742536286 From iklam at openjdk.org Thu Jan 29 16:44:21 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 16:44:21 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file [v2] In-Reply-To: References: Message-ID: > The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. > > However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: > > - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). > > As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. > > - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29472/files - new: https://git.openjdk.org/jdk/pull/29472/files/0df60c53..0df60c53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29472&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29472&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29472/head:pull/29472 PR: https://git.openjdk.org/jdk/pull/29472 From duke at openjdk.org Thu Jan 29 17:33:14 2026 From: duke at openjdk.org (Jaromir Hamala) Date: Thu, 29 Jan 2026 17:33:14 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime Message-ID: This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. The current code in master has 2 phases: 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` 2. Use the timer in `clock_gettime()` Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. Potential concerns 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. 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 @JonasNorlinder: this is what I raised on the mailing-list. ------------- Commit messages: - readability + assumption check - faster getCurrentThreadUserTime Changes: https://git.openjdk.org/jdk/pull/29032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375446 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29032/head:pull/29032 PR: https://git.openjdk.org/jdk/pull/29032 From duke at openjdk.org Thu Jan 29 17:33:16 2026 From: duke at openjdk.org (Jaromir Hamala) Date: Thu, 29 Jan 2026 17:33:16 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> References: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> Message-ID: On Thu, 15 Jan 2026 14:56:13 GMT, Evgeny Astigeevich wrote: >> Signing the Oracle CLA is tricky. I secured a confirmation that my client does not claim any IP on this contribution so I can sign it as an individual. >> >> The Oracle CLA assistant says the Czech Republic is not supported for electronic signature and that I have to print, sign and scan a PDF. But the same assistant returns 404 when trying to download the PDF. >> Screenshot From 2026-01-05 20-03-47 >> >> >> edit: I was able to download and signed the agreement after all. > > @jerrinot > I have created a JBS issue on your behalf: https://bugs.openjdk.org/browse/JDK-8375446 @eastig many thanks for the review. I have never created (or even ran) gtest / jtreg. I will look around how to do that, but any pointer is appreciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3755438125 From eastigeevich at openjdk.org Thu Jan 29 17:33:15 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 29 Jan 2026 17:33:15 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> On Mon, 5 Jan 2026 19:04:51 GMT, Jaromir Hamala wrote: >> This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. >> >> The current code in master has 2 phases: >> 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` >> 2. Use the timer in `clock_gettime()` >> >> Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. >> >> However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. >> >> Potential concerns >> 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. >> 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. >> >> 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.getCu... > > Signing the Oracle CLA is tricky. I secured a confirmation that my client does not claim any IP on this contribution so I can sign it as an individual. > > The Oracle CLA assistant says the Czech Republic is not supported for electronic signature and that I have to print, sign and scan a PDF. But the same assistant returns 404 when trying to download the PDF. > Screenshot From 2026-01-05 20-03-47 > > > edit: I was able to download and signed the agreement after all. @jerrinot I have created a JBS issue on your behalf: https://bugs.openjdk.org/browse/JDK-8375446 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3755265384 From eastigeevich at openjdk.org Thu Jan 29 17:33:17 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 29 Jan 2026 17:33:17 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> References: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> Message-ID: On Thu, 15 Jan 2026 14:56:13 GMT, Evgeny Astigeevich wrote: >> Signing the Oracle CLA is tricky. I secured a confirmation that my client does not claim any IP on this contribution so I can sign it as an individual. >> >> The Oracle CLA assistant says the Czech Republic is not supported for electronic signature and that I have to print, sign and scan a PDF. But the same assistant returns 404 when trying to download the PDF. >> Screenshot From 2026-01-05 20-03-47 >> >> >> edit: I was able to download and signed the agreement after all. > > @jerrinot > I have created a JBS issue on your behalf: https://bugs.openjdk.org/browse/JDK-8375446 > @eastig many thanks for the review. I have never created (or even ran) gtest / jtreg. I will look around how to do that, but any pointer is appreciated! I found a jtreg test which checks `getCurrentThreadUserTime`: - `test/jdk/java/lang/management/ThreadMXBean/ThreadUserTime.java` The main questions are: - If kernel changes the logic behind 0 TIDs, intentionally or accidentally, will we detect those changes? If not, what the cost of debugging would be to identify that `getCurrentThreadUserTime` has been broken? I think it's possible to write a jtreg test which will detect changes: - If the current thread does not go into the kernel, `getCurrentThreadCpuTime()` should be similar to `getCurrentThreadUserTime`. `getCurrentThreadCpuTime()` has a different execution path vs `getCurrentThreadUserTime`. Maybe writing a gtest (google test) doing checks would be simpler than a jtreg test. You can call `os::current_thread_cpu_time`. See how `test/hotspot/gtest/runtime` tests use 'os::*'. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3784251521 From duke at openjdk.org Thu Jan 29 17:33:15 2026 From: duke at openjdk.org (Jaromir Hamala) Date: Thu, 29 Jan 2026 17:33:15 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:29:22 GMT, Jaromir Hamala wrote: > This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. > > The current code in master has 2 phases: > 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` > 2. Use the timer in `clock_gettime()` > > Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. > > However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. > > Potential concerns > 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. > 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. > > 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.0... Signing the Oracle CLA is tricky. I secured a confirmation that my client does not claim any IP on this contribution so I can sign it as an individual. The Oracle CLA assistant says the Czech Republic is not supported for electronic signature and that I have to print, sign and scan a PDF. But the same assistant returns 404 when trying to download the PDF. Screenshot From 2026-01-05 20-03-47 edit: I was able to download and signed the agreement after all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3711726154 From eastigeevich at openjdk.org Thu Jan 29 17:33:19 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 29 Jan 2026 17:33:19 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:29:22 GMT, Jaromir Hamala wrote: > This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. > > The current code in master has 2 phases: > 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` > 2. Use the timer in `clock_gettime()` > > Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. > > However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. > > Potential concerns > 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. > 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. > > 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.0... src/hotspot/os/linux/os_linux.cpp line 4962: > 4960: // [31:3] : Bitwise NOT of the PID or TID (~0 for current thread) > 4961: // [2] : 1 = Per-thread clock, 0 = Per-process clock > 4962: // [1:0] : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED) Need a note: - This is based on knowledge of kernel sources not public API/ABI docs. - Why will `os::Linux::thread_cpu_time(CLOCK_CURRENT_THREAD_USERTIME)` work correctly with it? - What is the minimum kernel version required for this to work? There are `os::Linux::kernel_version*` API you can use in `guarantee` to check kernel version meets the requirements. Could we have a gtest or a jtreg test for this change? src/hotspot/os/linux/os_linux.cpp line 4964: > 4962: // [1:0] : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED) > 4963: static_assert(sizeof(clockid_t) == 4, "Linux clockid_t must be 32-bit"); > 4964: constexpr clockid_t CLOCK_CURRENT_THREAD_USERTIME = static_cast(~0u << 3 | 4 | 1); It's difficult to read the expression to extract bits to check they correspond to values in the comment. I suggest: static_cast((~0u << 3) | 0b101); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29032#discussion_r2694676455 PR Review Comment: https://git.openjdk.org/jdk/pull/29032#discussion_r2694589741 From dcubed at openjdk.org Thu Jan 29 17:46:22 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 29 Jan 2026 17:46:22 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Re-reviewed v33. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3724159576 From dcubed at openjdk.org Thu Jan 29 17:46:24 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 29 Jan 2026 17:46:24 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v9] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 21:50:07 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1950: >> >>> 1948: // as having "-locked" the monitor, but the OS and java.lang.Thread >>> 1949: // states will still report that the thread is blocked trying to >>> 1950: // acquire it. >> >> Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). @dcubed-ojdk, could you comment on this, please? > > Sorry for the long delay in getting back to this review. > > Hmmmm... I'm wondering if that comment is correct: > - We've creat `ExitOnSuspend eos` on L1961. > - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`. > - We reenter the monitor on L1964. > - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below: > - We call the `eos` object on the current thread BEFORE we `call process_if_requested` > > So it looks to me like we exit the monitor before we block for the safepoint so we should not > be showing the monitor as "locked" by our "blocked" thread. I think the comment addition on L1974-1976 addresses this review thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2742799060 From pchilanomate at openjdk.org Thu Jan 29 18:35:24 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 18:35:24 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 00:19:05 GMT, David Holmes wrote: > So we are logically suspended (`is_suspended()` is true) but we haven't actually done a check for suspension that would cause us to actually block, due to the transition-disabler? > Exactly. Suspending inside a `MountUnmountDisabler` scope would lead to a deadlock since the resumer won't be able to run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3819515604 From pchilanomate at openjdk.org Thu Jan 29 18:35:27 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 18:35:27 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: <_OP5TGNtsbOYEF8gDLDTV_0qDnvNZUtLWB9jE0cYkyA=.a97957ff-8c49-4bd9-a4fa-09e800918443@github.com> On Thu, 29 Jan 2026 15:48:50 GMT, Serguei Spitsyn wrote: > Looks good. Strangely, I did not see this assert in my testing when the ThreadStateTest2 test was introduced. :) > Makes sense because it's intermittent. I'm able to reproduce it by running the test in a loop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3819521683 From asmehra at openjdk.org Thu Jan 29 19:30:53 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 29 Jan 2026 19:30:53 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file [v2] In-Reply-To: References: Message-ID: <994jlMIX92OFLMv2WOwnrSbsVaRwSwwJ_gjXIL6X55k=.4ffbd3e3-b014-4b79-a25f-03885a7e7422@github.com> On Thu, 29 Jan 2026 16:44:21 GMT, Ioi Lam wrote: >> The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. >> >> However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: >> >> - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). >> >> As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. >> >> - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/29472#pullrequestreview-3724584941 From iklam at openjdk.org Thu Jan 29 20:03:56 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 20:03:56 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file [v3] In-Reply-To: References: Message-ID: > The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. > > However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: > > - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). > > As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. > > - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8375569-store-java-mirrors-in-aot-config-file-v3 - dump heap oop in aot config file - 8376523: Move interned strings into AOT roots array ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29472/files - new: https://git.openjdk.org/jdk/pull/29472/files/0df60c53..26e83600 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29472&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29472&range=01-02 Stats: 4227 lines in 89 files changed: 3224 ins; 683 del; 320 mod Patch: https://git.openjdk.org/jdk/pull/29472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29472/head:pull/29472 PR: https://git.openjdk.org/jdk/pull/29472 From iklam at openjdk.org Thu Jan 29 21:37:15 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 21:37:15 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file [v2] In-Reply-To: <6KLgPNoSONCRKCiDF79CKyuH606ZB4LrrBI18uumq_k=.48a5058a-9e82-4b1e-bc25-3df17683af31@github.com> References: <6KLgPNoSONCRKCiDF79CKyuH606ZB4LrrBI18uumq_k=.48a5058a-9e82-4b1e-bc25-3df17683af31@github.com> Message-ID: <0BH9uVKUE4e9toMlZEA3xLvwgnHIRzTR7E-0-bYxwxU=.15956846-91f5-4925-8b57-6170caa4f277@github.com> On Thu, 29 Jan 2026 14:39:04 GMT, Igor Veresov wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. > > Looks good Thanks @veresov @vnkozlov @ashu-mehra for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29472#issuecomment-3820487168 From duke at openjdk.org Thu Jan 29 22:04:48 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 29 Jan 2026 22:04:48 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v9] In-Reply-To: References: Message-ID: <4B04_CHU7c80isClKUBlLeoD_V9eVAEUENUC0FZp_Xo=.f3b2e176-3106-47dc-b7a7-1bef56859b0f@github.com> > ### Summary > This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. > > ### Description > The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. > > Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. > > The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. > > The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). > > Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. > > ### Performance > See https://github.com/openjdk/jdk/pull/28934#issuecomment-3820151693 for performance results. > > This was also tested internally with a real workload and showed up to a 20% latency reduction with a large CodeCache (512 MB). > > ### Testing > * CodeCache tests have been updated to cover... Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Add more configuration flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27858/files - new: https://git.openjdk.org/jdk/pull/27858/files/b5a5c71b..6933c0a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27858&range=07-08 Stats: 25 lines in 3 files changed: 16 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27858/head:pull/27858 PR: https://git.openjdk.org/jdk/pull/27858 From duke at openjdk.org Thu Jan 29 22:04:56 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Thu, 29 Jan 2026 22:04:56 GMT Subject: RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v8] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 00:24:33 GMT, Chad Rakoczy wrote: >> ### Summary >> This PR implements [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205), introducing experimental support for grouping hot code within the CodeCache. >> >> ### Description >> The feature works by periodically sampling the execution of C2-compiled methods to identify hot code, then relocating those methods into a dedicated `HotCodeHeap` section of the CodeCache. >> >> Sampling is performed by the `HotCodeSampler`, which runs on a new dedicated `HotCodeGrouper` thread. The thread wakes up every `HotCodeIntervalSeconds` (default 300s) and collects samples for a duration of `HotCodeSampleSeconds` (default 120s). During each sampling period, it iterates over all Java threads, inspects their last Java frame, obtains the current program counter (PC), and maps it to the corresponding nmethod. This allows the sampler to maintain a profile of the most frequently executed methods. >> >> The `HotCodeGrouper` uses the sampling data to select methods for grouping. Methods are ranked by sample count to form the candidate set. The grouper then relocates these methods (along with their callees, which has been shown to improve performance on AArch64 due to better branch prediction) into the `HotCodeHeap` in descending order of hotness, continuing until the fraction of samples attributable to hot methods exceeds `HotCodeSampleRatio` (default 0.8). The process continues to ensure that the hot-method ratio remains above the threshold. >> >> The `HotCodeHeap` is a new code heap segment with a default size of 20% of the non-profiled heap, though this can be overridden. This size was chosen based on the principle that roughly 20% of methods contribute to 80% of the work. Only C2-compiled nmethods are eligible for relocation, and the relocation process leverages existing infrastructure from [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). >> >> Relocation occurs entirely on the grouper thread and runs concurrently with the application. To maintain correctness, the thread acquires the `CodeCache_lock` and `Compile_lock` during relocation but releases these locks between individual relocations to avoid blocking GC safepoints. Removal of nmethods from the `HotCodeHeap` is handled by the GC. >> >> ### Performance >> See https://github.com/openjdk/jdk/pull/28934#issuecomment-3820151693 for performance results. >> >> This was also tested internally with a real workload and showed up to a 20% latency reduction with a large CodeCache (512 MB). >> >> ### Testing >> * ... > > Chad Rakoczy 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 30 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8326205 > - Fix test failure > - Fix builds > - Fix merge > - Merge remote-tracking branch 'origin/master' into JDK-8326205 > - Add check for full HotCodeHeap > - Add HotCodeGrouperMoveFunction test > - Add StessHotCodeGrouper test > - Update blob checks > - Merge fix > - ... and 20 more: https://git.openjdk.org/jdk/compare/1e1e132d...b5a5c71b I created an agent that fragments the code cache to better demonstrate the benefits of this feature: https://github.com/openjdk/jdk/pull/28934 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3820647704 From iveresov at openjdk.org Thu Jan 29 22:04:58 2026 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 29 Jan 2026 22:04:58 GMT Subject: RFR: 8375569: Store Java mirrors in AOT configuration file [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:03:56 GMT, Ioi Lam wrote: >> The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. >> >> However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: >> >> - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). >> >> As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. >> >> - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8375569-store-java-mirrors-in-aot-config-file-v3 > - dump heap oop in aot config file > - 8376523: Move interned strings into AOT roots array Marked as reviewed by iveresov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29472#pullrequestreview-3725277798 From iklam at openjdk.org Thu Jan 29 22:42:27 2026 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 Jan 2026 22:42:27 GMT Subject: Integrated: 8375569: Store Java mirrors in AOT configuration file In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:04:14 GMT, Ioi Lam wrote: > The AOT configuration file is currently implemented as a special AOT cache that doesn't have archived heap objects. > > However, in both Valhalla and Leyden, we have found the need to store heap objects into the AOT configuration file: > > - In Valhalla, meta information related to a class can be stored as injected fields in the class's Java mirror. For example, Valhalla-specific `acmp` operations requires certain classes to have a property called `.acmp_maps` which is represented as an integer array. Because the acmp operation is implemented in Java code, this array needs to be a regular Java `int[]` (not the usual C++ type of `Array` traditionally used by HotSpot). > > As we expect more JVM capabilities to be implemented in Java code in future evolution of HotSpot, we should expect more "metadata" related to a Java class to be represented as Java objects. > > - In Leyden, we are trying improve support for custom class loaders. While the design is not finalized, it's likely that we will need to store the classes defined by custom loaders from the training run into the AOT configuration file. In the production run, we must properly restore these classes with the correct `ProtectionDomain` and `CodeSource` objects. A simple solution will be to store the {Java mirror + `ProtectionDomain`) for these classes into the AOT configuration during the training run, and pass these into the AOT cache during the AOT assembly phase. This pull request has now been integrated. Changeset: 175bbb14 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/175bbb143e9fd2e596eb234d46ef9259f2bc4c1a Stats: 106 lines in 10 files changed: 78 ins; 10 del; 18 mod 8375569: Store Java mirrors in AOT configuration file Reviewed-by: iveresov, kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/29472 From dholmes at openjdk.org Fri Jan 30 00:28:20 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 00:28:20 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg wrote: > Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. > > By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. > > Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. > > Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. > > We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. > > After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. > > Tests are running okay tier1-7 on supported platforms. > > The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. > I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` Not a review, just a couple of drive-by comments. There is no high-level design doc description for the OMT itself - nothing to describe what "tombstones" and "relocations" are. Maybe such things are well known if you write CHTs ... src/hotspot/share/runtime/objectMonitorTable.cpp line 417: > 415: if (result != curr) { > 416: // Somebody else racingly started rehashing; try again. > 417: new_table = result; First, how is this "trying again"? I see no loop or repeated action. Second, you seem to be leaking the table you just allocated. src/hotspot/share/runtime/synchronizer.cpp line 1204: > 1202: } > 1203: } > 1204: #endif I find it very hard to see how rebuilding relates to the deleted debug code? Maybe this is just a quirk of the diff: we don't need the old debug code; we do need the new rebuild code - they aren't actually related in any way. ? ------------- PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3725612723 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2744053892 PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2744045743 From dholmes at openjdk.org Fri Jan 30 03:27:26 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 03:27:26 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:29:22 GMT, Jaromir Hamala wrote: > This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. > > The current code in master has 2 phases: > 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` > 2. Use the timer in `clock_gettime()` > > Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. > > However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. > > Potential concerns > 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. > 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. > > 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.0... This seems like a good shortcut for the current thread. Only minor change requested. Thanks ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29032#pullrequestreview-3726125175 From dholmes at openjdk.org Fri Jan 30 03:27:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 03:27:29 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 14:46:26 GMT, Evgeny Astigeevich wrote: >> This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. >> >> The current code in master has 2 phases: >> 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` >> 2. Use the timer in `clock_gettime()` >> >> Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. >> >> However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. >> >> Potential concerns >> 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. >> 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. >> >> 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.getCu... > > src/hotspot/os/linux/os_linux.cpp line 4962: > >> 4960: // [31:3] : Bitwise NOT of the PID or TID (~0 for current thread) >> 4961: // [2] : 1 = Per-thread clock, 0 = Per-process clock >> 4962: // [1:0] : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED) > > Need a note: > - This is based on knowledge of kernel sources not public API/ABI docs. > - Why will `os::Linux::thread_cpu_time(CLOCK_CURRENT_THREAD_USERTIME)` work correctly with it? > - What is the minimum kernel version required for this to work? There are `os::Linux::kernel_version*` API you can use in `guarantee` to check kernel version meets the requirements. > > Could we have a gtest or a jtreg test for this change? This surely is just an extension of what we already have and assume as per the previous comment block. My only suggestion here is to combine the two comment blocks so we are not repeating the part about the bit encoding. // Since kernel v2.6.12 the Linux ABI has had support for encoding the clock // types in the last three bits of the clock identifier. The full encoding is: // [31:3] : Bitwise NOT of the PID or TID (~0 for current thread), or a file descriptor // [2] : 1 = Per-thread clock, 0 = Per-process clock // [1:0] : Clock type (0 = PROF, 1 = VIRT, 2 = SCHED, 3 = FD) // // The clock CPUCLOCK_VIRT (0b001) reports the thread's consumed user // time. POSIX compliant implementations of pthread_getcpuclockid return the // clock CPUCLOCK_SCHED (0b010) which reports the thread's consumed system+user // time (as mandated by the POSIX standard POSIX.1-2024/IEEE Std 1003.1-2024 // ?3.90). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29032#discussion_r2744443080 From dholmes at openjdk.org Fri Jan 30 04:21:09 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:21:09 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> Message-ID: On Thu, 22 Jan 2026 12:53:36 GMT, Evgeny Astigeevich wrote: > If kernel changes the logic behind 0 TIDs, intentionally or accidentally, will we detect those changes? @eastig I think this is being overly cautious. and no more risky then them deciding to change the values of the clock bits. This is the defined format for clockid_t and any change would have major implications. That said I ran a simple test comparing the cpu time obtained via both techniques and it did report a zero difference, so such a gtest is quite feasible - I just worry that once in a blue moon we will take a signal between the two reads and so the diff will be unexpectedly large. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3821720586 From dholmes at openjdk.org Fri Jan 30 04:39:23 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:39:23 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo wrote: > Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed. > > Thanks, > Patricio Seems reasonable. One suggestion that may not be worthwhile so feel free to ignore. Thanks src/hotspot/share/runtime/continuation.cpp line 92: > 90: assert(!_current->is_suspended() || > 91: (_current->is_vthread_transition_disabler() && _result != freeze_ok), "must be"); > 92: #endif Suggestion: assert(!_current->is_suspended() JVMTI_ONLY(|| (_current->is_vthread_transition_disabler() && _result != freeze_ok)) , "must be"); Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ?? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3726282698 PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2744568340 From sspitsyn at openjdk.org Fri Jan 30 07:10:27 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 07:10:27 GMT Subject: RFR: 8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 04:36:21 GMT, David Holmes wrote: > Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ?? Good suggestion. JVMTI is the only way to suspend threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2744955251 From fjiang at openjdk.org Fri Jan 30 08:29:19 2026 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 30 Jan 2026 08:29:19 GMT Subject: RFR: 8376572: RISC-V: Interpreter: Load array index as signed int [v2] In-Reply-To: References: Message-ID: > Please consider. > We should use the `lw` instruction (which loads a 32-bit index from the operand stack and performs sign extension) instead of the `ld` instruction for the array index loading. > > Testing: > > - [x] tier1 with linux-riscv64 release build Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: use lw/sw to load/store local variable for iinc() and wide_iinc() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29458/files - new: https://git.openjdk.org/jdk/pull/29458/files/9cd6f3dd..92af2e9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29458&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29458&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29458/head:pull/29458 PR: https://git.openjdk.org/jdk/pull/29458 From aartemov at openjdk.org Fri Jan 30 09:24:19 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 30 Jan 2026 09:24:19 GMT Subject: RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v34] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:52:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor (OM), then a following liveness issues can happen in the `ObjectMonitor::wait()` method. >> >> 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 three 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 >> >> 3: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951 >> >> 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. >> >> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. >> >> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event. >> >> Tests are added. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8366659: Extra check before posting the waited event. Thank you all for reviews. I am going to integrate it in the beginning of the next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3822699886 From jsjolen at openjdk.org Fri Jan 30 12:53:16 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 30 Jan 2026 12:53:16 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:02:30 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - added a comment for block integrity check switch > - Merge remote-tracking branch 'origin' into asan_poison_malloc_hdr_ftr_v2 > - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 > - removed extra newlines. > - fixes. > - inlining > - review comments applied. > - revision > - jtreg test excluded when ASAN is enabled. > - 8369393: NMT: poison the malloc header and footer under ASAN build Please remove the extra added whitespace :-). src/hotspot/share/nmt/mallocHeader.cpp line 79: > 77: } > 78: } > 79: Remove test/hotspot/gtest/nmt/test_nmt_cornercases.cpp line 161: > 159: } > 160: #endif // !INCLUDE_ASAN > 161: Remove! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28503#pullrequestreview-3728117983 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2746124402 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2746125215 From azafari at openjdk.org Fri Jan 30 13:25:32 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 30 Jan 2026 13:25:32 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v4] In-Reply-To: References: Message-ID: > Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. > Checking the integrity of memory blocks is off under ASAN builds. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: whitespaces removed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28503/files - new: https://git.openjdk.org/jdk/pull/28503/files/0fe2059f..8b3d2131 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=02-03 Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28503/head:pull/28503 PR: https://git.openjdk.org/jdk/pull/28503 From jsjolen at openjdk.org Fri Jan 30 13:25:32 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 30 Jan 2026 13:25:32 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 13:22:09 GMT, Afshin Zafari wrote: >> Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times. >> Checking the integrity of memory blocks is off under ASAN builds. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > whitespaces removed. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28503#pullrequestreview-3728241908 From azafari at openjdk.org Fri Jan 30 13:25:37 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 30 Jan 2026 13:25:37 GMT Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN build [v3] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 12:49:38 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - added a comment for block integrity check switch >> - Merge remote-tracking branch 'origin' into asan_poison_malloc_hdr_ftr_v2 >> - Merge remote-tracking branch 'origin/master' into asan_poison_malloc_hdr_ftr_v2 >> - removed extra newlines. >> - fixes. >> - inlining >> - review comments applied. >> - revision >> - jtreg test excluded when ASAN is enabled. >> - 8369393: NMT: poison the malloc header and footer under ASAN build > > src/hotspot/share/nmt/mallocHeader.cpp line 79: > >> 77: } >> 78: } >> 79: > > Remove Removed. > test/hotspot/gtest/nmt/test_nmt_cornercases.cpp line 161: > >> 159: } >> 160: #endif // !INCLUDE_ASAN >> 161: > > Remove! Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2746235590 PR Review Comment: https://git.openjdk.org/jdk/pull/28503#discussion_r2746237361 From stefank at openjdk.org Fri Jan 30 14:33:03 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 30 Jan 2026 14:33:03 GMT Subject: RFR: 8376810: Make Atomic default constructor non-explicit Message-ID: While rewriting GC code to use Atomic we have seen compilation failures like this: src/hotspot/share/gc/g1/g1ConcurrentMark.cpp:562:54: error: chosen constructor is explicit in copy-initialization make: *** [product-bundles] Error 2 562 | ::new (&_region_mark_stats[i]) G1RegionMarkStats{}; | ^ src/hotspot/share/runtime/atomic.hpp:346:22: note: explicit constructor declared here 346 | explicit constexpr Atomic(T value = 0) : SupportsArithmetic(value) {} | ^ src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp:44:18: note: in implicit initialization of field '_live_words' with omitted initializer 44 | Atomic _live_words; | ^ 1 error generated. This case be worked around by adding a constructor `G1RegionMarkStats`, and explicitly initializing the atomic variable. It turns out that under certain conditions the `explicit` qualifier causes classes to not compile. I propose that we split the constructor into two, and only keep the `explicit` qualifier for the one-arg constructor. I've verified that this solved the above compilation error. ------------- Commit messages: - 8376810: Make Atomic default constructor non-explicit Changes: https://git.openjdk.org/jdk/pull/29505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376810 Stats: 59 lines in 2 files changed: 54 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29505/head:pull/29505 PR: https://git.openjdk.org/jdk/pull/29505 From fyang at openjdk.org Fri Jan 30 14:47:35 2026 From: fyang at openjdk.org (Fei Yang) Date: Fri, 30 Jan 2026 14:47:35 GMT Subject: RFR: 8373595: A new ObjectMonitorTable implementation In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 13:51:42 GMT, Fredrik Bredberg wrote: >> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path. >> >> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression. >> >> Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object. >> >> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64. >> >> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements. >> >> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic. >> >> Tests are running okay tier1-7 on supported platforms. >> >> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU. >> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java ` > > @TheRealMDoerr, @RealFYang, @offamitkumar > Hi guys! > So here we have a new Object Monitor Table implementation. As stated above I've smoke tested `ppc`, `riscv` and `s390` using QEMU. However I haven't been able to run proper performance tests on "your" platforms, but all the assembler stuff is follows the same scheme as x86 and aarch64, which I have run performance tests on, so hopefully it's good on all platforms. Anyhow, please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance. @fbredber : Hi, Thanks for the ping! I checked the RISC-V part and seems that several minor improvements could be made by making use of the extra temp register `tmp4`. Also we can make use of `shadd` from the bit-manipulation extension to calculate address of the bucket when available. Please consider the following add-on change for this platform. diff --git a/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp b/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp index 4a7669eee1d..0c437b45852 100644 --- a/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp +++ b/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp @@ -138,9 +138,9 @@ void C2_MacroAssembler::fast_lock(Register obj, Register box, const int num_unrolled = OMCache::CAPACITY; for (int i = 0; i < num_unrolled; i++) { - ld(t0, Address(tmp3_t)); + ld(tmp4, Address(tmp3_t)); ld(tmp1_monitor, Address(tmp3_t, OMCache::oop_to_monitor_difference())); - beq(obj, t0, monitor_found); + beq(obj, tmp4, monitor_found); add(tmp3_t, tmp3_t, in_bytes(OMCache::oop_to_oop_difference())); } @@ -155,14 +155,13 @@ void C2_MacroAssembler::fast_lock(Register obj, Register box, ld(tmp1, Address(tmp3_t, ObjectMonitorTable::table_capacity_mask_offset())); andr(tmp2_hash, tmp2_hash, tmp1); ld(tmp3_t, Address(tmp3_t, ObjectMonitorTable::table_buckets_offset())); - slli(tmp2_hash, tmp2_hash, LogBytesPerWord); - add(tmp3_bucket, tmp3_t, tmp2_hash); // Read the monitor from the bucket. + shadd(tmp3_bucket, tmp2_hash, tmp3_t, tmp4, LogBytesPerWord); ld(tmp1_monitor, Address(tmp3_bucket)); // Check if the monitor in the bucket is special (empty, tombstone or removed). - li(tmp2, ObjectMonitorTable::SpecialPointerValues::below_is_special); + mv(tmp2, ObjectMonitorTable::SpecialPointerValues::below_is_special); bltu(tmp1_monitor, tmp2, slow_path); // Check if object matches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29383#issuecomment-3824124034 From phubner at openjdk.org Fri Jan 30 15:00:06 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 30 Jan 2026 15:00:06 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v3] In-Reply-To: References: Message-ID: > Hi all, > > This fixes `runtime/ErrorHandling/TestDwarf.java` failing on Linux+Clang. Two sub-tests are patched. There are some macros that guard against MSVC. This is due to the fact that although the test will only run on Linux, the native library may also get compiled with Windows when running tiered testing. With MSVC, `__attribute__((noinline))` is a syntax error, whereas this is legal for Clang and GCC. > > #### `crashNativeMultipleMethods` > > Disallow inlining of `foo` to ensure it appears in the native frames stack, where it can be picked up by the test process analyser. > > #### `crashNativeDereferenceNull` > > Preventatively also disable inlining for `dereference_null` since it's searched for in the stack. With Clang, the JVM process can exit without an hs_err file, so skip the subtest. `crashNativeMultipleMethods` already checks the stack frames, so we are not losing coverage. Furthermore, the vast majority of the world uses a GCC-built JDK anyway. > > Testing: Ran the test for 20 iterations on Linux+GCC and Linux+Clang without failure. Also tier1 on Linux, macOS and Windows as a sanity test. Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8371590 - Ignore inlining with MSVC. - Fix failing test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29451/files - new: https://git.openjdk.org/jdk/pull/29451/files/7b6e6578..798bdd44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=01-02 Stats: 21241 lines in 622 files changed: 9431 ins; 4446 del; 7364 mod Patch: https://git.openjdk.org/jdk/pull/29451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29451/head:pull/29451 PR: https://git.openjdk.org/jdk/pull/29451 From phubner at openjdk.org Fri Jan 30 15:14:23 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 30 Jan 2026 15:14:23 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v4] In-Reply-To: References: Message-ID: > Hi all, > > This fixes `runtime/ErrorHandling/TestDwarf.java` failing on Linux+Clang. Two sub-tests are patched. There are some macros that guard against MSVC. This is due to the fact that although the test will only run on Linux, the native library may also get compiled with Windows when running tiered testing. With MSVC, `__attribute__((noinline))` is a syntax error, whereas this is legal for Clang and GCC. > > #### `crashNativeMultipleMethods` > > Disallow inlining of `foo` to ensure it appears in the native frames stack, where it can be picked up by the test process analyser. > > #### `crashNativeDereferenceNull` > > Preventatively also disable inlining for `dereference_null` since it's searched for in the stack. With Clang, the JVM process can exit without an hs_err file, so skip the subtest. `crashNativeMultipleMethods` already checks the stack frames, so we are not losing coverage. Furthermore, the vast majority of the world uses a GCC-built JDK anyway. > > Testing: Ran the test for 20 iterations on Linux+GCC and Linux+Clang without failure. Also tier1 on Linux, macOS and Windows as a sanity test. Paul H?bner has updated the pull request incrementally with one additional commit since the last revision: Change comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29451/files - new: https://git.openjdk.org/jdk/pull/29451/files/798bdd44..51973812 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29451&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29451/head:pull/29451 PR: https://git.openjdk.org/jdk/pull/29451 From phubner at openjdk.org Fri Jan 30 15:14:25 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 30 Jan 2026 15:14:25 GMT Subject: RFR: 8371590: runtime/ErrorHandling/TestDwarf.java fails with clang toolchain [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 16:35:28 GMT, Paul H?bner wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarf.c line 35: >> >>> 33: __attribute__((noinline)) >>> 34: #endif >>> 35: void foo(int x) { >> >> Now that we are explicitly NOT inlining this method, we could follow-up with simplifying this instead of doing "some random things" as the old comment stated. > > Good idea, I'll see if I can simplify it a bit while retaining the same semantics. It turns out we can't, because the compiler will start to optimize things away and the stack traces change. I'm going to keep as-is, but I've changed the comment. Hope that works, I'll re-run testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29451#discussion_r2746738016 From eastigeevich at openjdk.org Fri Jan 30 15:18:27 2026 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 30 Jan 2026 15:18:27 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: <_-YUts9f8NCXeK4p5jMg81GRTfabbnFjXEwkm6IajZM=.e6694a58-a9ad-4a71-813b-cb5261f5099a@github.com> Message-ID: On Thu, 22 Jan 2026 12:53:36 GMT, Evgeny Astigeevich wrote: >> @jerrinot >> I have created a JBS issue on your behalf: https://bugs.openjdk.org/browse/JDK-8375446 > >> @eastig many thanks for the review. I have never created (or even ran) gtest / jtreg. I will look around how to do that, but any pointer is appreciated! > > I found a jtreg test which checks `getCurrentThreadUserTime`: > - `test/jdk/java/lang/management/ThreadMXBean/ThreadUserTime.java` > > The main questions are: > - If kernel changes the logic behind 0 TIDs, intentionally or accidentally, will we detect those changes? If not, what the cost of debugging would be to identify that `getCurrentThreadUserTime` has been broken? > > I think it's possible to write a jtreg test which will detect changes: > - If the current thread does not go into the kernel, `getCurrentThreadCpuTime()` should be similar to `getCurrentThreadUserTime`. `getCurrentThreadCpuTime()` has a different execution path vs `getCurrentThreadUserTime`. > > Maybe writing a gtest (google test) doing checks would be simpler than a jtreg test. You can call `os::current_thread_cpu_time`. See how `test/hotspot/gtest/runtime` tests use 'os::*'. > @eastig I think this is being overly cautious. and no more risky then them deciding to change the values of the clock bits. :) Agree, maybe a little bit overcautious. > That said I ran a simple test comparing the cpu time obtained via both techniques and it did report a zero difference, so such a gtest is quite feasible - I just worry that once in a blue moon we will take a signal between the two reads and so the diff will be unexpectedly large. If the difference is unexpectedly large, maybe just rerun. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29032#issuecomment-3824263373 From xuelei at openjdk.org Fri Jan 30 16:13:54 2026 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 30 Jan 2026 16:13:54 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes Message-ID: **Summary** This change extends the CDS/AOT archive size limit from 2GB to 32GB by using scaled offset encoding. **Problem** Applications with a large number of classes (e.g., 300,000+) can exceed the current 2GB archive size limit, causing archive creation to fail with: [error][aot] Out of memory in the CDS archive: Please reduce the number of shared classes. **Solution** Instead of storing raw byte offsets in u4 fields (limited to ~2GB), we now store scaled offset units where each unit represents 8 bytes (OFFSET_SHIFT = 3). This allows addressing up to 32GB (2^32 ? 8 bytes) while maintaining backward compatibility with the existing u4 offset fields. Current: address = base + offset_bytes (max ~2GB) Proposed: address = base + (offset_units << 3) (max 32GB) All archived objects are guaranteed to be 8-byte aligned. This means the lower 3 bits of any valid byte offset are always zero ? we're wasting them! Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000! Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000!Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! By storing `offset_bytes >> 3` instead of `offset_bytes`, we use all 32 bits of the u4 field to represent meaningful data, extending the addressable range from 2GB to 32GB. **Test** All tier1 and tier2 tests passed. No visible performance impact. Local benchmark shows significant performance improvement for CDS, Dynamic CDS and AOT Cache archive loading, with huge archive size (>2GB). Archive: - 300000 simple classes - 2000 mega-classes - 5000 FieldObject classes - Total: 307000 classes AOT Cache: Times (wall): create=250020ms verify=2771ms baseline=15470ms perf_with_aot=2388ms Times (classload): verify=965ms baseline=14771ms perf_with_aot=969ms Static CDS: Times (wall): create=161859ms verify=2055ms baseline=15592ms perf_with_cds=1996ms Times (classload): verify=1027ms baseline=14852ms perf_with_cds=1010ms Base static CDS + Dynamic CDS: Times (wall): base_create=157186ms dynamic_create=2336ms verify=2026ms baseline=15223ms perf_with_dynamic=2031ms Times (classload): verify=965ms baseline=14513ms perf_with_dynamic=937ms Where `create` is the archive creation time, and `verify` (with `-Xlog:cds=info`) and `perf_with_*` is the application loading time from archive, and `baseline` is the application loading time without archive. ------------- Commit messages: - 8376125: Out of memory in the CDS archive error with lot of classes Changes: https://git.openjdk.org/jdk/pull/29494/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376125 Stats: 647 lines in 15 files changed: 620 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29494.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29494/head:pull/29494 PR: https://git.openjdk.org/jdk/pull/29494 From mbaesken at openjdk.org Fri Jan 30 17:00:11 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jan 2026 17:00:11 GMT Subject: RFR: 8376688: gtest os.attempt_reserve_memory_between_small_range_fill_hole_vm fails on AIX 7.3 Message-ID: On AIX we run into this error [ RUN ] os.attempt_reserve_memory_between_small_range_fill_hole_vm /test/jdk/test/hotspot/gtest/runtime/test_os_reserve_between.cpp:108: Failure Value of: expectation.check_reality(addr) Actual: false Expected: true addr: (null) min: 400010000000 max: 400210000000 bytes: 268435456 alignment: 268435456 randomized: false L347 ---- repeated 26 times ---- [ FAILED ] os.attempt_reserve_memory_between_small_range_fill_hole_vm (31 ms) Looks like this test is not really suited to the allocation granularity on AIX , so better do not do this test on AIX . ------------- Commit messages: - JDK-8376688 Changes: https://git.openjdk.org/jdk/pull/29508/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29508&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376688 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29508/head:pull/29508 PR: https://git.openjdk.org/jdk/pull/29508 From mdoerr at openjdk.org Fri Jan 30 17:34:45 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 30 Jan 2026 17:34:45 GMT Subject: RFR: 8376688: gtest os.attempt_reserve_memory_between_small_range_fill_hole_vm fails on AIX 7.3 In-Reply-To: References: Message-ID: <_C2dEJETNUc6GyJJ8DYgpbNuEDMFi4-RPG6C0q_9Bfs=.0291fa15-86b1-4a74-aa9c-4765f963c305@github.com> On Fri, 30 Jan 2026 16:50:18 GMT, Matthias Baesken wrote: > On AIX we run into this error > > > [ RUN ] os.attempt_reserve_memory_between_small_range_fill_hole_vm > /test/jdk/test/hotspot/gtest/runtime/test_os_reserve_between.cpp:108: Failure > Value of: expectation.check_reality(addr) > Actual: false > Expected: true > addr: (null) min: 400010000000 max: 400210000000 bytes: 268435456 alignment: 268435456 randomized: false L347 > > ---- repeated 26 times ---- > > [ FAILED ] os.attempt_reserve_memory_between_small_range_fill_hole_vm (31 ms) > > > Looks like this test is not really suited to the allocation granularity on AIX , so better do not do this test on AIX . Is the problem dependent on `g_multipage_support.can_use_64K_mmap_pages`? Should we disable it for all AIX configurations? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29508#issuecomment-3824854881 From eosterlund at openjdk.org Fri Jan 30 18:23:30 2026 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 30 Jan 2026 18:23:30 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: References: Message-ID: <13hhgsZhuwpwvEkQEHjDiDga8zsgwcUI7pmOF_VNX20=.052b587f-38bd-483e-abc9-c6d04b6dc116@github.com> On Thu, 29 Jan 2026 22:44:46 GMT, Xue-Lei Andrew Fan wrote: > **Summary** > This change extends the CDS/AOT archive size limit from 2GB to 32GB by using scaled offset encoding. > > **Problem** > Applications with a large number of classes (e.g., 300,000+) can exceed the current 2GB archive size limit, causing archive creation to fail with: > > [error][aot] Out of memory in the CDS archive: Please reduce the number of shared classes. > > > **Solution** > Instead of storing raw byte offsets in u4 fields (limited to ~2GB), we now store scaled offset units where each unit represents 8 bytes (OFFSET_SHIFT = 3). This allows addressing up to 32GB (2^32 ? 8 bytes) while maintaining backward compatibility with the existing u4 offset fields. > > Current: address = base + offset_bytes (max ~2GB) > Proposed: address = base + (offset_units << 3) (max 32GB) > > All archived objects are guaranteed to be 8-byte aligned. This means the lower 3 bits of any valid byte offset are always zero ? we're wasting them! > > Current byte offset (aligned to 8 bytes): > 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 > ??? Always 000! > > Scaled offset (shift=3): > 0x00000200 = Same address, but stored in 29 bits instead of 32 > Frees up 3 bits ? 8x larger range! > Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000!Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! > > By storing `offset_bytes >> 3` instead of `offset_bytes`, we use all 32 bits of the u4 field to represent meaningful data, extending the addressable range from 2GB to 32GB. > > **Test** > All tier1 and tier2 tests passed. No visible performance impact. Local benchmark shows significant performance improvement for CDS, Dynamic CDS and AOT Cache archive loading, with huge archive size (>2GB). > > Archive: > - 300000 simple classes > - 2000 mega-classes > - 5000 FieldObject classes > - Total: 307000 classes > > AOT Cache: > Times (wall): create=250020ms verify=2771ms baseline=15470ms perf_with_aot=2388ms > Times (classload): verify=965ms baseline=14771ms perf_with_aot=969ms > > Static CDS: > Times (wall): create=161859ms verify=2055ms baseline=15592ms perf_with_cds=1996ms > Times (classload): verify=1027ms baseline=14852ms perf_with_cds=1010ms > > Base static CDS + Dynamic CDS: > Times (wall): base_create=157186ms dynamic_... I have to wonder... if we are bumping the archive size in a way that makes us have to update a lot of things, should we go straight to 64 bit offsets instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29494#issuecomment-3825044875 From xuelei at openjdk.org Fri Jan 30 19:37:32 2026 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 30 Jan 2026 19:37:32 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: <13hhgsZhuwpwvEkQEHjDiDga8zsgwcUI7pmOF_VNX20=.052b587f-38bd-483e-abc9-c6d04b6dc116@github.com> References: <13hhgsZhuwpwvEkQEHjDiDga8zsgwcUI7pmOF_VNX20=.052b587f-38bd-483e-abc9-c6d04b6dc116@github.com> Message-ID: On Fri, 30 Jan 2026 18:20:34 GMT, Erik ?sterlund wrote: > I have to wonder... if we are bumping the archive size in a way that makes us have to update a lot of things, should we go straight to 64 bit offsets instead? Some alternative solutions were discussed, for example adding an additional offset field instead of using offset-shift. But there are performance concerns. The offset shift solution add no extra expense except the offset and shift calculation. 32GB archive size may be good at this moment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29494#issuecomment-3825386217 From kbarrett at openjdk.org Fri Jan 30 19:46:30 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 30 Jan 2026 19:46:30 GMT Subject: RFR: 8376810: Make Atomic default constructor non-explicit In-Reply-To: References: Message-ID: <3VVNWzgw1JJUXmhJPGwngRdBWWTcVNVzwLrqTZ2IjTY=.d0218d63-c5fc-4510-b47d-ad32f4d62730@github.com> On Fri, 30 Jan 2026 14:24:58 GMT, Stefan Karlsson wrote: > While rewriting GC code to use Atomic we have seen compilation failures like this: > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp:562:54: error: chosen constructor is explicit in copy-initialization > make: *** [product-bundles] Error 2 > 562 | ::new (&_region_mark_stats[i]) G1RegionMarkStats{}; > | ^ > src/hotspot/share/runtime/atomic.hpp:346:22: note: explicit constructor declared here > 346 | explicit constexpr Atomic(T value = 0) : SupportsArithmetic(value) {} > | ^ > src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp:44:18: note: in implicit initialization of field '_live_words' with omitted initializer > 44 | Atomic _live_words; > | ^ > 1 error generated. > > > This case be worked around by adding a constructor `G1RegionMarkStats`, and explicitly initializing the atomic variable. > > It turns out that under certain conditions the `explicit` qualifier causes classes to not compile. I propose that we split the constructor into two, and only keep the `explicit` qualifier for the one-arg constructor. > > I've verified that this solved the above compilation error. Looks good, except for a IWYU nit. test/hotspot/gtest/runtime/test_atomic.cpp line 63: > 61: alignas(Holder) char mem[sizeof(Holder)]; > 62: memset(mem, 0xFF, sizeof(Holder)); > 63: Holder* h = new (mem) Holder(); Add `#include "cppstdlib/new.hpp"` ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29505#pullrequestreview-3730049397 PR Review Comment: https://git.openjdk.org/jdk/pull/29505#discussion_r2747696842 From dcubed at openjdk.org Fri Jan 30 20:47:42 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 20:47:42 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files Message-ID: A trivial fix to add preview project anchors to main-line ProblemList files. Also backports changes from the Valhalla repo to make/RunTests.gmk to support ProblemList-coh.txt files. This PR also includes the new ProblemList-coh.txt file, but it contains no entries (yet). Since this is NOT a complete backport of the changes for: - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 I'm not handling it as a backport issue. I've also added missing Copyright headers to some files. ------------- Commit messages: - Merge branch 'master' into JDK-8376751 - 8376751: add preview project anchors to main-line ProblemList files Changes: https://git.openjdk.org/jdk/pull/29509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376751 Stats: 402 lines in 26 files changed: 380 ins; 2 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29509/head:pull/29509 PR: https://git.openjdk.org/jdk/pull/29509 From jnorlinder at openjdk.org Fri Jan 30 21:39:13 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Fri, 30 Jan 2026 21:39:13 GMT Subject: RFR: 8375446: [Linux] Avoid radix lookup in kernel pid_for_clock to speedup getCurrentThreadUserTime In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:29:22 GMT, Jaromir Hamala wrote: > This PR further optimizes os::current_thread_cpu_time (used by ThreadMXBean.getCurrentThreadUserTime()) on Linux by using the kernel's fast-path for the calling thread. I see it as a continuation of https://github.com/openjdk/jdk/pull/28556. > > The current code in master has 2 phases: > 1. Create a timer bound to the current Thread ID (TID) + massage the timer to switch from `CPUCLOCK_SCHED` timer to `CPUCLOCK_VIRT` > 2. Use the timer in `clock_gettime()` > > Within the kernel, a routine exists to extract the TID from the timer, followed by a radix lookup to find booking structures for the specified TID. > > However, the kernel also has a fast-path: When TID is `0`, then the kernel avoids the radix lookup and instead treats the timer as bound to 'the current thread' (or a process, depending on lower bits of the clock). The current thread/task has bookkeeping structures more readily available and the radix lookup is avoided. The result is around 13% faster `getCurrentThreadUserTime()`. > > Potential concerns > 1. ABI stability. I believe [Linux policy on ABI stability](https://lkml.org/lkml/2012/12/23/75) is simple: **"WE DO NOT BREAK USERSPACE!"** Changing the behaviour when `TID` is 0 would break user-space. > 2. I am not fluent in C++ and I am not entirely sure if the expression to build the timer is UB-free. Perhaps there is a better way which does not rely on a specific size of `clockid_t`. Feedback here is very much appreciated. > > 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.0... Since the kernel part we are referencing is not explicitly defined in uapi, we need to be extra careful to confirm whether it is indeed part of user space. For the previous code change this PR builds on, glibc/musl was found to rely on this bit encoding for a very long time, making it the de facto user space. Can we find any similar usage here? src/hotspot/os/linux/os_linux.cpp line 4963: > 4961: // [2] : 1 = Per-thread clock, 0 = Per-process clock > 4962: // [1:0] : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED) > 4963: static_assert(sizeof(clockid_t) == 4, "Linux clockid_t must be 32-bit"); I think `clockid_t` could expand to 64-bits without breaking any user space as long as the last bits remain to have the same encoding. Therefore, I think we should remove this assert. Suggestion: ------------- Changes requested by jnorlinder (Author). PR Review: https://git.openjdk.org/jdk/pull/29032#pullrequestreview-3730467907 PR Review Comment: https://git.openjdk.org/jdk/pull/29032#discussion_r2748034281 From kvn at openjdk.org Fri Jan 30 21:44:27 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 30 Jan 2026 21:44:27 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by kvn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730502656 From liach at openjdk.org Fri Jan 30 21:44:29 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 21:44:29 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. test/langtools/ProblemList-enable-preview.txt line 2: > 1: # > 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. Suggestion: # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748067121 From rriggs at openjdk.org Fri Jan 30 22:11:03 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 30 Jan 2026 22:11:03 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730618431 From liach at openjdk.org Fri Jan 30 22:11:05 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:11:05 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730624896 From dcubed at openjdk.org Fri Jan 30 22:11:07 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:11:07 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> On Fri, 30 Jan 2026 21:40:57 GMT, Chen Liang wrote: >> A trivial fix to add preview project anchors to main-line ProblemList files. >> >> Also backports changes from the Valhalla repo to make/RunTests.gmk >> to support ProblemList-coh.txt files. This PR also includes the new >> ProblemList-coh.txt file, but it contains no entries (yet). Since this is >> NOT a complete backport of the changes for: >> >> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 >> >> I'm not handling it as a backport issue. >> >> I've also added missing Copyright headers to some files. > > test/langtools/ProblemList-enable-preview.txt line 2: > >> 1: # >> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748155579 From liach at openjdk.org Fri Jan 30 22:11:07 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:11:07 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> References: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> Message-ID: On Fri, 30 Jan 2026 22:04:58 GMT, Daniel D. Daugherty wrote: >> test/langtools/ProblemList-enable-preview.txt line 2: >> >>> 1: # >>> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. >> >> Suggestion: >> >> # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. > > Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"... Sure, we can inherit the valhalla copyright years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748166677 From dcubed at openjdk.org Fri Jan 30 22:28:51 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:28:51 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 21:40:15 GMT, Vladimir Kozlov wrote: >> A trivial fix to add preview project anchors to main-line ProblemList files. >> >> Also backports changes from the Valhalla repo to make/RunTests.gmk >> to support ProblemList-coh.txt files. This PR also includes the new >> ProblemList-coh.txt file, but it contains no entries (yet). Since this is >> NOT a complete backport of the changes for: >> >> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 >> >> I'm not handling it as a backport issue. >> >> I've also added missing Copyright headers to some files. > > Marked as reviewed by kvn (Reviewer). @vnkozlov, @liach, and @RogerRiggs - Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29509#issuecomment-3826088183 From dcubed at openjdk.org Fri Jan 30 22:40:52 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:40:52 GMT Subject: Integrated: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. This pull request has now been integrated. Changeset: 6ce2f3e1 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/6ce2f3e18f31d1dbffc2c4f5adbb5dfe91613989 Stats: 402 lines in 26 files changed: 380 ins; 2 del; 20 mod 8376751: add preview project anchors to main-line ProblemList files Reviewed-by: kvn, rriggs, liach ------------- PR: https://git.openjdk.org/jdk/pull/29509 From iklam at openjdk.org Fri Jan 30 23:06:50 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 30 Jan 2026 23:06:50 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 22:44:46 GMT, Xue-Lei Andrew Fan wrote: > **Summary** > This change extends the CDS/AOT archive size limit from 2GB to 32GB by using scaled offset encoding. > > **Problem** > Applications with a large number of classes (e.g., 300,000+) can exceed the current 2GB archive size limit, causing archive creation to fail with: > > [error][aot] Out of memory in the CDS archive: Please reduce the number of shared classes. > > > **Solution** > Instead of storing raw byte offsets in u4 fields (limited to ~2GB), we now store scaled offset units where each unit represents 8 bytes (OFFSET_SHIFT = 3). This allows addressing up to 32GB (2^32 ? 8 bytes) while maintaining backward compatibility with the existing u4 offset fields. > > Current: address = base + offset_bytes (max ~2GB) > Proposed: address = base + (offset_units << 3) (max 32GB) > > All archived objects are guaranteed to be 8-byte aligned. This means the lower 3 bits of any valid byte offset are always zero ? we're wasting them! > > Current byte offset (aligned to 8 bytes): > 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 > ??? Always 000! > > Scaled offset (shift=3): > 0x00000200 = Same address, but stored in 29 bits instead of 32 > Frees up 3 bits ? 8x larger range! > Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000!Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! > > By storing `offset_bytes >> 3` instead of `offset_bytes`, we use all 32 bits of the u4 field to represent meaningful data, extending the addressable range from 2GB to 32GB. > > **Test** > All tier1 and tier2 tests passed. No visible performance impact. Local benchmark shows significant performance improvement for CDS, Dynamic CDS and AOT Cache archive loading, with huge archive size (>2GB). > > Archive: > - 300000 simple classes > - 2000 mega-classes > - 5000 FieldObject classes > - Total: 307000 classes > > AOT Cache: > Times (wall): create=250020ms verify=2771ms baseline=15470ms perf_with_aot=2388ms > Times (classload): verify=965ms baseline=14771ms perf_with_aot=969ms > > Static CDS: > Times (wall): create=161859ms verify=2055ms baseline=15592ms perf_with_cds=1996ms > Times (classload): verify=1027ms baseline=14852ms perf_with_cds=1010ms > > Base static CDS + Dynamic CDS: > Times (wall): base_create=157186ms dynamic_... src/hotspot/share/cds/aotMetaspace.cpp line 2102: > 2100: unmap_archive(mapinfo); > 2101: return MAP_ARCHIVE_OTHER_FAILURE; > 2102: } Since `ArchiveUtils::OFFSET_SHIFT` is a constant for this JVM build, there's no need to save it into the archive and validate the saved value at runtime. We don't perform such checks for other constants. The archive contains the VM version string, so it cannot be used by a different JVM build. src/hotspot/share/cds/archiveBuilder.hpp line 337: > 335: uintx offset_units = offset_bytes >> ArchiveUtils::OFFSET_SHIFT; > 336: guarantee(offset_units <= 0xFFFFFFFF, "offset units must fit in u4"); > 337: return (u4)offset_units; Can be replaced with `return checked_cast(offset_units);` src/hotspot/share/cds/archiveUtils.hpp line 264: > 262: public: > 263: static constexpr int OFFSET_SHIFT = 3; > 264: static constexpr uintx MAX_SHARED_DELTA = LP64_ONLY(32ULL * G) NOT_LP64(0x7FFFFFFF); There's no need to shift in 32-bit. Also, we are moving away from the terminology of "cds" and "share". I think we should rename these constants: Also, in newer code we are changing constants from `ALL_CAPS` to `CamelCase`. // For space saving, we can encode the location of metadata objects in the "rw" and "ro" // regions using a 32-bit offset from the bottom of the "rw" region. Since the metadata // objects are 8-byte aligned, we can encode with a 3-bit shift on 64-bit platforms // to accomodate a maximum of 32GB of metadata objects. There's no need for shifts on // 32-bit builds as the size of the AOT cache is limited. static constexpr int MetadataOffsetShift = LP64_ONLY(3) NOT_LP64(0); static constexpr uintx MaxMetadataOffsetBytes = LP64_ONLY(0x1000000000ULL << OFFSET_SHIFT) NOT_LP64(0x7FFFFFFFF); src/hotspot/share/cds/archiveUtils.hpp line 320: > 318: uintx offset_units = offset_bytes >> OFFSET_SHIFT; > 319: assert(offset_units <= 0xFFFFFFFF, "offset units must fit in u4"); > 320: return static_cast(offset_units); These two lines can be replaced as return checked_cast(offset_units); test/hotspot/jtreg/resourcehogs/runtime/cds/LargeAOTCache.java line 33: > 31: * @compile LargeCDSUtil.java LargeCDSApp.java LargeAOTCache.java > 32: * @run driver jdk.test.lib.helpers.ClassFileInstaller -jar app.jar LargeCDSApp LargeCDSUtil > 33: * @run driver/timeout=20000 LargeAOTCache I worry that this test will take too long to run. It's better to add a new debug flag like this so the test can run very quickly with just a small number of simple classes. product(uint, AOTKlassObjectPadding, 0, \ "For testing large AOT caches -- prepend each Klass object in the" \ "AOT cache with this number of bytes") And in `ArchiveBuilder::make_shallow_copy()` char* oldtop = dump_region->top(); if (src_info->type() == MetaspaceClosureType::ClassType) { DEBUG_ONLY({if (AOTKlassObjectPadding > 0) { // Add padding in front of each class so we can easily create large // gigabyte-sized AOT cache. dump_region->allocate(AOTKlassObjectPadding); }; Add add `@requires vm.debug` to this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748126439 PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748116393 PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748142299 PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748152043 PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748293189 From iklam at openjdk.org Fri Jan 30 23:06:52 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 30 Jan 2026 23:06:52 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 22:52:58 GMT, Ioi Lam wrote: >> **Summary** >> This change extends the CDS/AOT archive size limit from 2GB to 32GB by using scaled offset encoding. >> >> **Problem** >> Applications with a large number of classes (e.g., 300,000+) can exceed the current 2GB archive size limit, causing archive creation to fail with: >> >> [error][aot] Out of memory in the CDS archive: Please reduce the number of shared classes. >> >> >> **Solution** >> Instead of storing raw byte offsets in u4 fields (limited to ~2GB), we now store scaled offset units where each unit represents 8 bytes (OFFSET_SHIFT = 3). This allows addressing up to 32GB (2^32 ? 8 bytes) while maintaining backward compatibility with the existing u4 offset fields. >> >> Current: address = base + offset_bytes (max ~2GB) >> Proposed: address = base + (offset_units << 3) (max 32GB) >> >> All archived objects are guaranteed to be 8-byte aligned. This means the lower 3 bits of any valid byte offset are always zero ? we're wasting them! >> >> Current byte offset (aligned to 8 bytes): >> 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 >> ??? Always 000! >> >> Scaled offset (shift=3): >> 0x00000200 = Same address, but stored in 29 bits instead of 32 >> Frees up 3 bits ? 8x larger range! >> Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000!Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! >> >> By storing `offset_bytes >> 3` instead of `offset_bytes`, we use all 32 bits of the u4 field to represent meaningful data, extending the addressable range from 2GB to 32GB. >> >> **Test** >> All tier1 and tier2 tests passed. No visible performance impact. Local benchmark shows significant performance improvement for CDS, Dynamic CDS and AOT Cache archive loading, with huge archive size (>2GB). >> >> Archive: >> - 300000 simple classes >> - 2000 mega-classes >> - 5000 FieldObject classes >> - Total: 307000 classes >> >> AOT Cache: >> Times (wall): create=250020ms verify=2771ms baseline=15470ms perf_with_aot=2388ms >> Times (classload): verify=965ms baseline=14771ms perf_with_aot=969ms >> >> Static CDS: >> Times (wall): create=161859ms verify=2055ms baseline=15592ms perf_with_cds=1996ms >> Times (classload): verify=1027ms baseline=14852ms perf_with_cds=1... > > test/hotspot/jtreg/resourcehogs/runtime/cds/LargeAOTCache.java line 33: > >> 31: * @compile LargeCDSUtil.java LargeCDSApp.java LargeAOTCache.java >> 32: * @run driver jdk.test.lib.helpers.ClassFileInstaller -jar app.jar LargeCDSApp LargeCDSUtil >> 33: * @run driver/timeout=20000 LargeAOTCache > > I worry that this test will take too long to run. > > It's better to add a new debug flag like this so the test can run very quickly with just a small number of simple classes. > > > product(uint, AOTKlassObjectPadding, 0, \ > "For testing large AOT caches -- prepend each Klass object in the" \ > "AOT cache with this number of bytes") > > > And in `ArchiveBuilder::make_shallow_copy()` > > > char* oldtop = dump_region->top(); > if (src_info->type() == MetaspaceClosureType::ClassType) { > DEBUG_ONLY({if (AOTKlassObjectPadding > 0) { > // Add padding in front of each class so we can easily create large > // gigabyte-sized AOT cache. > dump_region->allocate(AOTKlassObjectPadding); > }; > > > > Add add `@requires vm.debug` to this test. Also, this test should be moved to `test/hotspot/jtreg/resourcehogs/runtime/aot/LargeAOTCache.java` because it consumes a lot of RAM. We have set up our CI pipeline to run tests under `resourcehogs` without concurrency so they won't cause OOM in other tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748309661 From iklam at openjdk.org Fri Jan 30 23:06:53 2026 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 30 Jan 2026 23:06:53 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 23:00:04 GMT, Ioi Lam wrote: >> test/hotspot/jtreg/resourcehogs/runtime/cds/LargeAOTCache.java line 33: >> >>> 31: * @compile LargeCDSUtil.java LargeCDSApp.java LargeAOTCache.java >>> 32: * @run driver jdk.test.lib.helpers.ClassFileInstaller -jar app.jar LargeCDSApp LargeCDSUtil >>> 33: * @run driver/timeout=20000 LargeAOTCache >> >> I worry that this test will take too long to run. >> >> It's better to add a new debug flag like this so the test can run very quickly with just a small number of simple classes. >> >> >> product(uint, AOTKlassObjectPadding, 0, \ >> "For testing large AOT caches -- prepend each Klass object in the" \ >> "AOT cache with this number of bytes") >> >> >> And in `ArchiveBuilder::make_shallow_copy()` >> >> >> char* oldtop = dump_region->top(); >> if (src_info->type() == MetaspaceClosureType::ClassType) { >> DEBUG_ONLY({if (AOTKlassObjectPadding > 0) { >> // Add padding in front of each class so we can easily create large >> // gigabyte-sized AOT cache. >> dump_region->allocate(AOTKlassObjectPadding); >> }; >> >> >> >> Add add `@requires vm.debug` to this test. > > Also, this test should be moved to `test/hotspot/jtreg/resourcehogs/runtime/aot/LargeAOTCache.java` because it consumes a lot of RAM. We have set up our CI pipeline to run tests under `resourcehogs` without concurrency so they won't cause OOM in other tests. Can you combine the three tests cases into a single file, driven by three different `@test` blocks? You can see an example in `test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29494#discussion_r2748319775 From asmehra at openjdk.org Sat Jan 31 22:32:00 2026 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Sat, 31 Jan 2026 22:32:00 GMT Subject: RFR: 8376125: Out of memory in the CDS archive error with lot of classes In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 22:44:46 GMT, Xue-Lei Andrew Fan wrote: > **Summary** > This change extends the CDS/AOT archive size limit from 2GB to 32GB by using scaled offset encoding. > > **Problem** > Applications with a large number of classes (e.g., 300,000+) can exceed the current 2GB archive size limit, causing archive creation to fail with: > > [error][aot] Out of memory in the CDS archive: Please reduce the number of shared classes. > > > **Solution** > Instead of storing raw byte offsets in u4 fields (limited to ~2GB), we now store scaled offset units where each unit represents 8 bytes (OFFSET_SHIFT = 3). This allows addressing up to 32GB (2^32 ? 8 bytes) while maintaining backward compatibility with the existing u4 offset fields. > > Current: address = base + offset_bytes (max ~2GB) > Proposed: address = base + (offset_units << 3) (max 32GB) > > All archived objects are guaranteed to be 8-byte aligned. This means the lower 3 bits of any valid byte offset are always zero ? we're wasting them! > > Current byte offset (aligned to 8 bytes): > 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 > ??? Always 000! > > Scaled offset (shift=3): > 0x00000200 = Same address, but stored in 29 bits instead of 32 > Frees up 3 bits ? 8x larger range! > Current byte offset (aligned to 8 bytes): 0x00001000 = 0000 0000 0000 0000 0001 0000 0000 0|000 ??? Always 000!Scaled offset (shift=3): 0x00000200 = Same address, but stored in 29 bits instead of 32 Frees up 3 bits ? 8x larger range! > > By storing `offset_bytes >> 3` instead of `offset_bytes`, we use all 32 bits of the u4 field to represent meaningful data, extending the addressable range from 2GB to 32GB. > > **Test** > All tier1 and tier2 tests passed. No visible performance impact. Local benchmark shows significant performance improvement for CDS, Dynamic CDS and AOT Cache archive loading, with huge archive size (>2GB). > > Archive: > - 300000 simple classes > - 2000 mega-classes > - 5000 FieldObject classes > - Total: 307000 classes > > AOT Cache: > Times (wall): create=250020ms verify=2771ms baseline=15470ms perf_with_aot=2388ms > Times (classload): verify=965ms baseline=14771ms perf_with_aot=969ms > > Static CDS: > Times (wall): create=161859ms verify=2055ms baseline=15592ms perf_with_cds=1996ms > Times (classload): verify=1027ms baseline=14852ms perf_with_cds=1010ms > > Base static CDS + Dynamic CDS: > Times (wall): base_create=157186ms dynamic_... There are two more apis that return "unchecked" offset: `ArchiveBuilder::buffer_to_offset()` and `ArchiveBuilder::any_to_offset()`. These apis are not returning the scaled offset. I think it is better to get rid of these apis and replace their usage with `_u4` version which has the offset range check. I noticed there are only 1-2 instances that use these "unchecked" apis. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29494#issuecomment-3829483397