From haosun at openjdk.org Fri Aug 1 00:04:02 2025 From: haosun at openjdk.org (Hao Sun) Date: Fri, 1 Aug 2025 00:04:02 GMT Subject: RFR: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: <6CRZBpGwS69ZgWKLmIG7UOj9jPqVxvieJKEAT9lao-Y=.af3bdd20-0a45-4928-8c5b-197b377e8ba3@github.com> On Wed, 30 Jul 2025 16:26:55 GMT, Jaikiran Pai wrote: > Hello Hao, > > > Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms. > > Note that these two jtreg cases can pass with jtreg `7.5.2+1` version. > > Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on. Thanks for your confirm, Jaikiran. Forgot to mention that I tested `jdk_all, hotspot_all, langtools_all` with jtreg `8` and only found these two test failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3141675024 From dlong at openjdk.org Fri Aug 1 00:49:22 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Aug 2025 00:49:22 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v9] In-Reply-To: References: Message-ID: > The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. Dean Long 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: - Merge branch 'openjdk:master' into 8278874-verifystack - more cleanup - simplify is_top_frame - readability suggestion - reviewer suggestions - Update src/hotspot/share/runtime/vframeArray.cpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/runtime/vframeArray.cpp Co-authored-by: Manuel H?ssig - better name for frame index - Update src/hotspot/share/runtime/deoptimization.cpp Co-authored-by: Manuel H?ssig - fix optimized build - ... and 2 more: https://git.openjdk.org/jdk/compare/91c07ccd...6bfda158 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26121/files - new: https://git.openjdk.org/jdk/pull/26121/files/6257de6c..6bfda158 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=07-08 Stats: 59108 lines in 1555 files changed: 33964 ins; 16451 del; 8693 mod Patch: https://git.openjdk.org/jdk/pull/26121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121 PR: https://git.openjdk.org/jdk/pull/26121 From dlong at openjdk.org Fri Aug 1 02:38:59 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Aug 2025 02:38:59 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v9] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 00:49:22 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long 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: > > - Merge branch 'openjdk:master' into 8278874-verifystack > - more cleanup > - simplify is_top_frame > - readability suggestion > - reviewer suggestions > - Update src/hotspot/share/runtime/vframeArray.cpp > > Co-authored-by: Manuel H?ssig > - Update src/hotspot/share/runtime/vframeArray.cpp > > Co-authored-by: Manuel H?ssig > - better name for frame index > - Update src/hotspot/share/runtime/deoptimization.cpp > > Co-authored-by: Manuel H?ssig > - fix optimized build > - ... and 2 more: https://git.openjdk.org/jdk/compare/ad91eaa9...6bfda158 I'm running Graal testing now and I've hit at least one of my new asserts so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3141966534 From missa at openjdk.org Fri Aug 1 02:47:00 2025 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 1 Aug 2025 02:47:00 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3] In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> References: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> Message-ID: On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa wrote: >> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. >> >> The command to run all range specific micro-benchmarks is posted below. >> >> `make test TEST="micro:SinhPerf.SinhPerfRanges"` >> >> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. >> >> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. >> >> | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | >> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | >> | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | >> | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | >> | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | >> | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | >> | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | >> >> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2 @eme64 Available to run the additional tests? Also, a couple of the pre-submit checks had failures unrelated to the code changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3141980741 From stuefe at openjdk.org Fri Aug 1 04:42:53 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 1 Aug 2025 04:42:53 GMT Subject: RFR: 8343218: Disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Good ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3077618779 From kbarrett at openjdk.org Fri Aug 1 05:00:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 1 Aug 2025 05:00:59 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v13] In-Reply-To: <2HazQXRv2W1X8noflzufBpZEZtxURBLlelofJz36G18=.8f9d4c0e-9af4-4c70-a156-b57b6c9a39d4@github.com> References: <2HazQXRv2W1X8noflzufBpZEZtxURBLlelofJz36G18=.8f9d4c0e-9af4-4c70-a156-b57b6c9a39d4@github.com> Message-ID: On Wed, 30 Jul 2025 14:08:09 GMT, Anton Artemov wrote: > > Maybe we should have an `ATTRIBUTE_NODISCARD` macro with an always empty > > definition, and add it to all the functions being changed? Otherwise, once > > `[[nodiscard]]` becomes available, someone is going to have to hunt down all > > the relevant functions. Once we have C++17 we can revisit. It might take some > > preliminary call-site fixes before we can change the macro (or more likely, > > remove it and just use `[[nodiscard]]` directly). > > @kimbarrett How about to change the return type from bool to some enum class? They are not implicitly convertible to integers, so one should not be able to ignore the return value of a function then. And we will not need a `[[nodiscard]]` in this case. I don't see how that helps at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3142176108 From kbarrett at openjdk.org Fri Aug 1 05:05:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 1 Aug 2025 05:05:58 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v13] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 14:42:24 GMT, Anton Artemov wrote: >> Note that the main point here was the cast to (void) used to indicate that the return value is explicitly discarded. Does that not work with the [[nodiscard]]? > > Sorry, I completely missed that point. Need to check this. Explicitly casting to void is the canonical idiom for ignoring [[nodiscard]]. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2246914427 From kbarrett at openjdk.org Fri Aug 1 05:08:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 1 Aug 2025 05:08:59 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v13] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 13:32:20 GMT, Anton Artemov wrote: > > 1. I really would like to see all the UL "X failed" log lines removed from this patch. > > @stefank I understand your concerns. I can remove the logging for failed cases, but it will demise the proposed pattern. Without consensus on how to log such cases for JVM users, which is to be done in a later phase, I suggest to put TODO comments to the places where such logging should be done. What do you think? The point of my suggested "dummy" ATTRIBUTE_NODISCARD is that it serves the purpose of such TODO comments. If you undummify that macro then you get warnings at any places that haven't addressed the use of the return value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3142188027 From jsikstro at openjdk.org Fri Aug 1 07:46:00 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:46:00 GMT Subject: RFR: 8364248: Separate commit and reservation limit detection [v6] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m wrote: >> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space on Windows, and also the virtual address space cannot be limited. >> >> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited (i.e. if there's a limit on how much memory can be reserved). To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::reserve_memory_limit(), which returns the upper-bound of how much memory can be reserved. This should just be SIZE_MAX on Windows, since the virtual address space cannot be limited. >> >> Additionally, we should rename os::has_allocatable_memory_limit() to os::commit_memory_limit(), to be more in line with os::reserve_memory_limit() and read nicely next to the os::commit_memory() and os::reserve_memory() functions. The return type of the new os::commit_memory_limit() should also only be size_t, not bool + out-parameter, to fit better next to os::reserve_memory_limit(). >> >> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() (will be os::commit_memory_limit()) on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V). >> >> Testing: >> * Oracle's tier1-2 >> * Manual testing on Linux by limiting the virtual address space: >> >> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > commit_memory_limit return size_t instead of bool + out-parameter I've rerun testing, both some manual limit-setting and tier1-2, and looks good. Thank you for the reviews! @albertnetymk @tstuefe @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3143569133 From jsikstro at openjdk.org Fri Aug 1 07:46:01 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 1 Aug 2025 07:46:01 GMT Subject: Integrated: 8364248: Separate commit and reservation limit detection In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 11:24:48 GMT, Joel Sikstr?m wrote: > The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space on Windows, and also the virtual address space cannot be limited. > > ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited (i.e. if there's a limit on how much memory can be reserved). To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::reserve_memory_limit(), which returns the upper-bound of how much memory can be reserved. This should just be SIZE_MAX on Windows, since the virtual address space cannot be limited. > > Additionally, we should rename os::has_allocatable_memory_limit() to os::commit_memory_limit(), to be more in line with os::reserve_memory_limit() and read nicely next to the os::commit_memory() and os::reserve_memory() functions. The return type of the new os::commit_memory_limit() should also only be size_t, not bool + out-parameter, to fit better next to os::reserve_memory_limit(). > > As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() (will be os::commit_memory_limit()) on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V). > > Testing: > * Oracle's tier1-2 > * Manual testing on Linux by limiting the virtual address space: > > $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version This pull request has now been integrated. Changeset: ae11d8f4 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/ae11d8f44689502d35cb511e9ce288ab7cc0acae Stats: 107 lines in 5 files changed: 45 ins; 38 del; 24 mod 8364248: Separate commit and reservation limit detection Reviewed-by: stuefe, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26530 From duke at openjdk.org Fri Aug 1 09:11:54 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 1 Aug 2025 09:11:54 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v22] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8357086: Removed extra line - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/22c752c2..ab62a520 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=20-21 Stats: 50 lines in 14 files changed: 5 ins; 15 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Fri Aug 1 09:11:55 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 1 Aug 2025 09:11:55 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v18] In-Reply-To: References: <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com> <24xIFc0iPvkbR2lM-x92rIDage4gZ2_VZVu036XKc1o=.d554b735-d60a-4723-a5ac-85c431d0db5e@github.com> Message-ID: On Thu, 31 Jul 2025 15:23:51 GMT, Stefan Karlsson wrote: >> Okay, makes sense, it looks like a failure of `os::physical_memory()` is something very unlikely to happen. So I made this function `void`, but, to be consistent with the rest, it provides the value by writing to the input parameter. > > 1) I had hoped for some kind of sanity check in the initialization code that sets up _physical_memory. We can handle that as a separate RFE. > > 2) I really would prefer if os::physical_memory() returned size_t via the normal means and only use output parameters for the functions that require more than one return value. And on that note ... > > 3) Do the other functions (free_memory and available_memory) ever fail or could we fix those as well? Windows and AIX are using the same APIs that are used for os::physical_memory. Linux uses sysinfo, which only seems to fail if we pass in an incorrect value. BSD has an assert that would trigger if this fails. 1) As for sanity checks: - In `os::init()` in os_linux.cpp there is a sanity check for sysconf. It is done just before calling` Linux::initialize_system_info()` where `_physical_memory` is set. - In `os::Aix::initialize_system_info()` there is already a sanity check. - In `os::Bsd::initialize_system_info()` there is a check for success of `sysctl`, but a default value 256 * 1024 * 1024 is assigned to `_physical_memory`. I do not know why it is done this way. Maybe this needs to be addressed separately. - In `os::win32::initialize_system_info()` there is a call to `GlobalMemoryStatusEx`, but above we've came to conclusion that it never fails. So all OS sysinfo init routines have a sort of sanity check, except BSD, but I guess it was done intentionally. 2) Addressed. 3) As for the rest of the methods: - `available_memory()` can fail on Linux only if sysinfo fails, which can happen. Since it can fail on one OS, then the function should return both success/failure and the resulting value. - `used_memory()` is never used in the code. Maybe it should be completely removed? - `free_memory()`: the same argument applies as to `available_memory()`. - `total_swap_space()`: the same argument applies as to `available_memory()`. - `free_swap_space()`: the same argument applies as to `available_memory()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2247391028 From duke at openjdk.org Fri Aug 1 09:19:55 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 1 Aug 2025 09:19:55 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v23] In-Reply-To: References: Message-ID: <-SbK2XJEVxUmf9O-3-mnb3-ULRDnmxT-U3RUs_LDdVQ=.1e31ff6e-3455-4cbe-b323-cdecb94fe08e@github.com> > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - 8357086: Fixed merge conflict - 8357086: Removed extra line - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD - 8357086: Small fixes - 8357086: Made physical_memory() return void - 8357086: Fixed behavior of total_swap_space on Linux - 8357086: Addressed reviewer's comments. - 8357086: Fixed void conversion. - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - ... and 14 more: https://git.openjdk.org/jdk/compare/d80b5c87...f9b2c6d8 ------------- Changes: https://git.openjdk.org/jdk/pull/25450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=22 Stats: 253 lines in 23 files changed: 92 ins; 2 del; 159 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Fri Aug 1 09:53:55 2025 From: duke at openjdk.org (duke) Date: Fri, 1 Aug 2025 09:53:55 GMT Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 16:27:42 GMT, Oli Gillespie wrote: > We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected. > > > Intel(R) Xeon(R) Platinum 8259CL > java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc > Before: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {default} > After: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {ergonomic} > > > Even worse when it's actually false, but shows as true: > > > AMD EPYC 7R13 > java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc > Before: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {default} > After: > bool IntelJccErratumMitigation = false {ARCH diagnostic} {ergonomic} @olivergillespie Your change (at version 7f4f5debaa24ce4784372d96d37400de65489481) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26560#issuecomment-3143948732 From duke at openjdk.org Fri Aug 1 10:09:04 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 1 Aug 2025 10:09:04 GMT Subject: RFR: 8364519: Sort share/classfile includes Message-ID: This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. Passes tier1. ------------- Commit messages: - sort Changes: https://git.openjdk.org/jdk/pull/26590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364519 Stats: 44 lines in 18 files changed: 22 ins; 21 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26590/head:pull/26590 PR: https://git.openjdk.org/jdk/pull/26590 From mbaesken at openjdk.org Fri Aug 1 10:27:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Aug 2025 10:27:01 GMT Subject: RFR: 8364199: Enhance list of environment variables printed in hserr/hsinfo file In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 15:09:12 GMT, Matthias Baesken wrote: > We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file. > JAVA_OPTS is used by lots of tools . > WAYLAND_DISPLAY ( https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L492) > and JDK_AOT_VM_OPTIONS (https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.base/share/man/java.md?plain=1#L4052) are referenced in the codebase. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26509#issuecomment-3144065194 From mbaesken at openjdk.org Fri Aug 1 10:27:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Aug 2025 10:27:01 GMT Subject: Integrated: 8364199: Enhance list of environment variables printed in hserr/hsinfo file In-Reply-To: References: Message-ID: <55hHU099PxC1szUKel9i8vJxmU4CBbFSczs_3aDMPfA=.d9a5fd6a-f6ba-4313-9e1d-a1737f16275d@github.com> On Mon, 28 Jul 2025 15:09:12 GMT, Matthias Baesken wrote: > We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file. > JAVA_OPTS is used by lots of tools . > WAYLAND_DISPLAY ( https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L492) > and JDK_AOT_VM_OPTIONS (https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.base/share/man/java.md?plain=1#L4052) are referenced in the codebase. This pull request has now been integrated. Changeset: 812bd8e9 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/812bd8e94d22f9751651e28a2ef8affdf6a33220 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8364199: Enhance list of environment variables printed in hserr/hsinfo file Reviewed-by: lucy, clanger ------------- PR: https://git.openjdk.org/jdk/pull/26509 From ogillespie at openjdk.org Fri Aug 1 10:30:00 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Fri, 1 Aug 2025 10:30:00 GMT Subject: Integrated: 8364296: Set IntelJccErratumMitigation flag ergonomically In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 16:27:42 GMT, Oli Gillespie wrote: > We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected. > > > Intel(R) Xeon(R) Platinum 8259CL > java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc > Before: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {default} > After: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {ergonomic} > > > Even worse when it's actually false, but shows as true: > > > AMD EPYC 7R13 > java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc > Before: > bool IntelJccErratumMitigation = true {ARCH diagnostic} {default} > After: > bool IntelJccErratumMitigation = false {ARCH diagnostic} {ergonomic} This pull request has now been integrated. Changeset: 6c580472 Author: Oli Gillespie Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/6c5804722b5b2064e0d6ade2180c3126d8f2dabc Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8364296: Set IntelJccErratumMitigation flag ergonomically Reviewed-by: shade, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/26560 From shade at openjdk.org Fri Aug 1 11:08:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 11:08:54 GMT Subject: RFR: 8364519: Sort share/classfile includes In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:03:39 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. > > Passes tier1. Looks fine, with a nit. src/hotspot/share/classfile/systemDictionary.cpp line 63: > 61: #include "oops/objArrayOop.inline.hpp" > 62: #include "oops/oop.hpp" > 63: #include "oops/oop.inline.hpp" Take this opportunity to remove the include of `oop.hpp`, since we are including `oop.inline.hpp` anyway? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26590#pullrequestreview-3078791694 PR Review Comment: https://git.openjdk.org/jdk/pull/26590#discussion_r2247700897 From duke at openjdk.org Fri Aug 1 13:03:11 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 1 Aug 2025 13:03:11 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: > This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. > > Passes tier1. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: remove redundant includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26590/files - new: https://git.openjdk.org/jdk/pull/26590/files/4629ccf9..3477cbce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26590&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26590&range=00-01 Stats: 6 lines in 5 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26590/head:pull/26590 PR: https://git.openjdk.org/jdk/pull/26590 From duke at openjdk.org Fri Aug 1 13:03:12 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 1 Aug 2025 13:03:12 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 11:05:35 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> remove redundant includes > > src/hotspot/share/classfile/systemDictionary.cpp line 63: > >> 61: #include "oops/objArrayOop.inline.hpp" >> 62: #include "oops/oop.hpp" >> 63: #include "oops/oop.inline.hpp" > > Take this opportunity to remove the include of `oop.hpp`, since we are including `oop.inline.hpp` anyway? Sure, I got a few here: 3477cbce67776546bbb0cbc0cf18302a6dab2c97 Could this be a possible improvement of `SortIncludes.java`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26590#discussion_r2247927317 From shade at openjdk.org Fri Aug 1 13:07:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 13:07:53 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 13:03:11 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant includes Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26590#pullrequestreview-3079171165 From shade at openjdk.org Fri Aug 1 13:07:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 13:07:54 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 13:00:24 GMT, Francesco Andreuzzi wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 63: >> >>> 61: #include "oops/objArrayOop.inline.hpp" >>> 62: #include "oops/oop.hpp" >>> 63: #include "oops/oop.inline.hpp" >> >> Take this opportunity to remove the include of `oop.hpp`, since we are including `oop.inline.hpp` anyway? > > Sure, I got a few here: 3477cbce67776546bbb0cbc0cf18302a6dab2c97 > > Could this be a possible improvement of `SortIncludes.java`? Maybe, but it is not exactly the include order issue. We do these clean ups opportunistically, when it is glaringly obvious it is an unnecessary include. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26590#discussion_r2247940487 From shade at openjdk.org Fri Aug 1 14:00:03 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 14:00:03 GMT Subject: RFR: 8343218: Disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Generally looks fine. Stylistic/process note, though: the RFE synopsis still reads that we are disabling the optimization. We are not doing it here, we are only guarding it with a flag. Either submit a new RFE or rename this bug? ------------- PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3079349456 From coleenp at openjdk.org Fri Aug 1 14:58:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 14:58:53 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: <89cyGwzQ6a3VsmWbL0U2tW-gmDryL6BTqeH8GHUjCQU=.65e2d51f-7250-4e41-a5e3-297a806d5a79@github.com> On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Okay, I fixed the titles and will discuss with @vnkozlov and @TobiHartmann next week about getting this into JDK 25 or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26579#issuecomment-3144862351 From duke at openjdk.org Fri Aug 1 15:00:03 2025 From: duke at openjdk.org (ExE Boss) Date: Fri, 1 Aug 2025 15:00:03 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2] In-Reply-To: <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com> References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com> <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com> Message-ID: On Wed, 30 Jul 2025 10:57:33 GMT, Coleen Phillimore wrote: >> I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class. >> >> Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition. >> >> [^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92 > > I don't think inner class attributes can be changed via JVMTI RedefineClasses either. I'm pretty sure we check and that's considered a change of schema. File an RFE to make SharedSecrets fields @Stable though for a different change. I?don?t?have a?**JBS**?account, and?I?don?t?like going?through , so?could someone?else file?said?**RFE**? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248196045 From rriggs at openjdk.org Fri Aug 1 15:12:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Aug 2025 15:12:59 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com> <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com> Message-ID: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com> On Fri, 1 Aug 2025 14:57:03 GMT, ExE Boss wrote: >> I don't think inner class attributes can be changed via JVMTI RedefineClasses either. I'm pretty sure we check and that's considered a change of schema. File an RFE to make SharedSecrets fields @Stable though for a different change. > > I?don?t?have a?**JBS**?account, and?I?don?t?like going?through , so?could someone?else file?said?**RFE**? Created https://bugs.openjdk.org/browse/JDK-8364540 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248224660 From coleenp at openjdk.org Fri Aug 1 15:25:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 15:25:02 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore wrote: >> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Restore c2 optimization. Thank you for reviewing Tobias, Roger and Chen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26517#issuecomment-3144938447 From coleenp at openjdk.org Fri Aug 1 15:25:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 15:25:03 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2] In-Reply-To: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com> References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com> <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com> <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com> Message-ID: On Fri, 1 Aug 2025 15:10:02 GMT, Roger Riggs wrote: >> I?don?t?have a?**JBS**?account, and?I?don?t?like going?through , so?could someone?else file?said?**RFE**? > > Created https://bugs.openjdk.org/browse/JDK-8364540 Thanks Roger. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248246788 From coleenp at openjdk.org Fri Aug 1 15:25:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 15:25:04 GMT Subject: Integrated: 8364187: Make getClassAccessFlagsRaw non-native In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: <2HVJZKZ8FwStZduaGH4jA-zQsd8VDH4VF_1lnO1lDlY=.790ad8b0-d8da-43c5-81d5-97387b6ddcad@github.com> On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore wrote: > This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access. > Tested with tier1-4. This pull request has now been integrated. Changeset: ee3665bc Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/ee3665bca026fe53409df8391d49477c64ae23a2 Stats: 128 lines in 16 files changed: 61 ins; 36 del; 31 mod 8364187: Make getClassAccessFlagsRaw non-native Reviewed-by: thartmann, rriggs, liach ------------- PR: https://git.openjdk.org/jdk/pull/26517 From coleenp at openjdk.org Fri Aug 1 15:25:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 15:25:03 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: On Tue, 29 Jul 2025 14:35:06 GMT, Chen Liang wrote: >> This is a good suggestion but I made it Raw to match getRawClassAnnotations this name. > > Thanks for the rename. I think `raw annotations` means the uninterpreted byte data in the attribute is carried over raw; this concept is less applicable to the access_flags u2 value. Thank you for the suggested name change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248245044 From shade at openjdk.org Fri Aug 1 15:37:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 1 Aug 2025 15:37:53 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3079681502 From ayang at openjdk.org Fri Aug 1 15:53:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Aug 2025 15:53:04 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 13:03:11 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant includes Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26590#pullrequestreview-3079734419 From duke at openjdk.org Fri Aug 1 16:04:54 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 1 Aug 2025 16:04:54 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: <7vOMHTGdPPZzFKxyspJufQsdfHwdFtrO_PUv9ihZatw=.0912751b-c695-4fa4-9b9b-c2544e6bdd58@github.com> On Fri, 1 Aug 2025 13:03:11 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant includes The test failure does not seem to be related to the changes in this PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/26590#issuecomment-3145054636 From duke at openjdk.org Fri Aug 1 16:04:55 2025 From: duke at openjdk.org (duke) Date: Fri, 1 Aug 2025 16:04:55 GMT Subject: RFR: 8364519: Sort share/classfile includes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 13:03:11 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant includes @fandreuz Your change (at version 3477cbce67776546bbb0cbc0cf18302a6dab2c97) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26590#issuecomment-3145056176 From mablakatov at openjdk.org Fri Aug 1 16:05:42 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Fri, 1 Aug 2025 16:05:42 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> Message-ID: <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> > Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. > > This has passed tier1-3 and jcstress testing on AArch64. Mikhail Ablakatov 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 'master' - Address review comments from @theRealAph and @eastig - use relocInfo::relocType instead of TrampolineCallKind - move rtype from keys to values; reduce the footprint of the patch - Lift the vm.opt.TieredCompilation == null requirement from the tests - Combine the two shared trampoline request hash tables - 8359359: AArch64: share trampolines between static calls to the same method Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. ------------- Changes: https://git.openjdk.org/jdk/pull/25954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=02 Stats: 431 lines in 9 files changed: 311 ins; 110 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954 PR: https://git.openjdk.org/jdk/pull/25954 From aph at openjdk.org Fri Aug 1 17:38:59 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 1 Aug 2025 17:38:59 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> Message-ID: On Fri, 1 Aug 2025 16:05:42 GMT, Mikhail Ablakatov wrote: >> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. >> >> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. >> >> This has passed tier1-3 and jcstress testing on AArch64. > > Mikhail Ablakatov 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 'master' > - Address review comments from @theRealAph and @eastig > - use relocInfo::relocType instead of TrampolineCallKind > - move rtype from keys to values; reduce the footprint of the patch > - Lift the vm.opt.TieredCompilation == null requirement from the tests > - Combine the two shared trampoline request hash tables > - 8359359: AArch64: share trampolines between static calls to the same method > > Modify the C2 compiler to share trampoline stubs between static calls > that resolve to the same callee method. Since the relocation target for > all static calls is initially set to the static call resolver stub, the > call's target alone cannot be used to distinguish between different > static method calls. Instead, trampoline stubs should be shared based > on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of > trampolines among static calls. However, due to imprecise log analysis, > the test currently passes even when trampolines are not shared. > Additionally, comments within the test suggest ambiguity regarding > whether it was intended to assess trampoline sharing for static calls > or runtime calls. To address these issues and eliminate ambiguity, this > patch renames and updates the existing test. Furthermore, a new test is > introduced, using the existing one as a foundation, to accurately > evaluate trampoline sharing for both static and runtime calls. src/hotspot/cpu/aarch64/codeBuffer_aarch64.hpp line 46: > 44: void share_sc_trampoline_for(const ciMethod *callee, int caller_offset) { > 45: share_trampoline_for(relocInfo::static_call_type, (address)callee, caller_offset); > 46: } I don't think we need these two methods. They're only called once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2248517098 From erik.joelsson at oracle.com Fri Aug 1 17:54:56 2025 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Aug 2025 10:54:56 -0700 Subject: hotspot jtreg tests take WARNING_CFLAGS_JDK_CONLY flags In-Reply-To: References: Message-ID: <6a386790-d220-4e7a-8fdb-f0ddaf421035@oracle.com> Not sure about intended. The 'JDK' variable naming was introduced to basically mean not Hotspot. What flags that should apply to tests isn't always clear. I don't think that flags currently assigned to variables with JVM in the name should apply to hotspot tests. I think we just treat all native tests the same here and give them the JDK flags. This area could probably still need some careful sorting out and cleanup. /Erik On 7/10/25 08:23, Baesken, Matthias wrote: > > When? trying the GCC static analyzer (-fanalyzer flag) > > diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4 > > index e80d9a98957..9d1ae60047b 100644 > > --- a/make/autoconf/flags-cflags.m4 > > +++ b/make/autoconf/flags-cflags.m4 > > @@ -610,7 +610,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER], > > ?? # CFLAGS WARNINGS STUFF > > ?? # Set JVM_CFLAGS warning handling > > ?? if test "x$TOOLCHAIN_TYPE" = xgcc; then > > - WARNING_CFLAGS_JDK_CONLY="$WARNINGS_ENABLE_ALL_CFLAGS" > > +??? # enable -fanalyzer (but better only for gcc12 + , and also only > for C) > > +??? # too many strange / shaky fd leak warnings > > +??? WARNING_CFLAGS_JDK_CONLY="-fanalyzer -Wno-analyzer-fd-leak > $WARNINGS_ENABLE_ALL_CFLAGS" > > WARNING_CFLAGS_JDK_CXXONLY="$WARNINGS_ENABLE_ALL_CXXFLAGS" > > WARNING_CFLAGS_JVM="$WARNINGS_ENABLE_ALL_CXXFLAGS" > > I noticed that the WARNING_CFLAGS_JDK_CONLY? go into the? hotspot?? > jtreg tests, e.g.? : > > /jdk/test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h:46:6: > error: dereference of NULL '0' [CWE-476] > [-Werror=analyzer-null-dereference] > > ?? 46 |?? *x = 34; // Crash > > ????? |?? ~~~^~~~ > > ? 'dereference_null': event 1 > > ??? | > > ??? |?? 46 |?? *x = 34; // Crash > > ??? |????? |?? ~~~^~~~ > > ??? |????? |????? | > > ??? |????? |????? (1) dereference of NULL '0' > > This might be intended but?? I was surprised that the HS? C tests take > WARNING_CFLAGS_JDK_CONLY? ??!??? Is this intended or not ? > > Best regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Fri Aug 1 18:29:57 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 1 Aug 2025 18:29:57 GMT Subject: RFR: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3080178709 From mdoerr at openjdk.org Fri Aug 1 18:36:56 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 18:36:56 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove NMethodEntryBarrier_lock Thanks for implementing it for PPC64! The instruction sequence needs to be modified (see below). I'd like to have https://github.com/TheRealMDoerr/jdk/commit/522b1ef2e75509d91ac18a1acd27275fc0305e8e, too. Should I file a separate RFE for that? src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp line 195: > 193: // This is a compound instruction. Patching support is provided by NativeMovRegMem. > 194: // Actual patching is done in (platform-specific part of) BarrierSetNMethod. > 195: __ align(8); // align for atomic update We can't do this within this fixed size instruction sequence. But, it can be fixed like this: https://github.com/TheRealMDoerr/jdk/commit/a06b34468f5cb063892f92b66d058a8f444f05a1 ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080187466 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248603769 From mdoerr at openjdk.org Fri Aug 1 18:46:55 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 18:46:55 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove NMethodEntryBarrier_lock src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113: > 111: } > 112: > 113: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, Thread::current())); This looks also ok as alternative to my proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248631958 From coleenp at openjdk.org Fri Aug 1 19:35:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Aug 2025 19:35:55 GMT Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 07:02:10 GMT, Thomas Stuefe wrote: >> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2]. >> >> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. >> >> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that. >> >> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit. >> >> ------- >> >> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases. >> >> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops. >> >> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`. >> >> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Fix some jtreg tests on arm > - fix arm gtests > - fix CompressedKlass* gtests on arm > - Merge master > - get rid of NEEDS_CLASS_SPACE define > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - since to because > > Co-authored-by: Andrew Haley > - Remove stray include > - Update src/hotspot/share/oops/compressedKlass.cpp > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f Yes, this is better without NEEDS_CLASS_SPACE. Thanks. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26491#pullrequestreview-3080360029 From dlong at openjdk.org Fri Aug 1 20:09:11 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Aug 2025 20:09:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: References: Message-ID: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: Fix PPC64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/e05605eb..a06b3446 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=01-02 Stats: 24 lines in 2 files changed: 11 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From mdoerr at openjdk.org Fri Aug 1 20:09:11 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 20:09:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: On Fri, 1 Aug 2025 20:05:56 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC64 Thanks for integrating my fix! ------------- PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080433000 From mdoerr at openjdk.org Fri Aug 1 21:58:56 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Aug 2025 21:58:56 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: On Fri, 1 Aug 2025 20:09:11 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC64 PPC64 code looks correct, now, but I have minor proposals. src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: > 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); > 83: // Swap in the new value > 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 88: > 86: old_mov_instr.u64 = v; > 87: } > 88: ICache::ppc64_flush_icache_bytes(addr_at(0), NativeMovRegMem::instruction_size); Maybe only use flushing if `cmpxchg` succeeded? Otherwise, we didn't modify the code. ------------- PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3080627303 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248909656 PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2248925985 From dholmes at openjdk.org Sat Aug 2 01:49:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Sat, 2 Aug 2025 01:49:59 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Looks fine for an added safety-guard. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3080841140 From stuefe at openjdk.org Sat Aug 2 05:51:56 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 2 Aug 2025 05:51:56 GMT Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5] In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 19:33:22 GMT, Coleen Phillimore wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Fix some jtreg tests on arm >> - fix arm gtests >> - fix CompressedKlass* gtests on arm >> - Merge master >> - get rid of NEEDS_CLASS_SPACE define >> - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms >> - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms >> - since to because >> >> Co-authored-by: Andrew Haley >> - Remove stray include >> - Update src/hotspot/share/oops/compressedKlass.cpp >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f > > Yes, this is better without NEEDS_CLASS_SPACE. Thanks. Thanks @coleenp ! May I have a second approval, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26491#issuecomment-3146247662 From rkennke at openjdk.org Sat Aug 2 06:30:04 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Sat, 2 Aug 2025 06:30:04 GMT Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 07:02:10 GMT, Thomas Stuefe wrote: >> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2]. >> >> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. >> >> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that. >> >> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit. >> >> ------- >> >> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases. >> >> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops. >> >> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`. >> >> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Fix some jtreg tests on arm > - fix arm gtests > - fix CompressedKlass* gtests on arm > - Merge master > - get rid of NEEDS_CLASS_SPACE define > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - since to because > > Co-authored-by: Andrew Haley > - Remove stray include > - Update src/hotspot/share/oops/compressedKlass.cpp > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f Looks good to me! Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26491#pullrequestreview-3080936692 From stuefe at openjdk.org Sun Aug 3 06:46:03 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 3 Aug 2025 06:46:03 GMT Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 07:02:10 GMT, Thomas Stuefe wrote: >> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2]. >> >> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. >> >> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that. >> >> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit. >> >> ------- >> >> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases. >> >> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops. >> >> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`. >> >> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Fix some jtreg tests on arm > - fix arm gtests > - fix CompressedKlass* gtests on arm > - Merge master > - get rid of NEEDS_CLASS_SPACE define > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms > - since to because > > Co-authored-by: Andrew Haley > - Remove stray include > - Update src/hotspot/share/oops/compressedKlass.cpp > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f Thanks Roman! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26491#issuecomment-3147510019 From stuefe at openjdk.org Sun Aug 3 06:46:04 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 3 Aug 2025 06:46:04 GMT Subject: Integrated: 8363998: Implement Compressed Class Pointers for 32-bit In-Reply-To: References: Message-ID: On Sat, 26 Jul 2025 12:17:50 GMT, Thomas Stuefe wrote: > We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2]. > > A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. > > Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that. > > So we need to find a way to support `+UseCompressedClassPointers` on 32-bit. > > ------- > > This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases. > > How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops. > > We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`. > > We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design... This pull request has now been integrated. Changeset: 819de071 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/819de071176623448ceba8065ed6f2aac40ae193 Stats: 196 lines in 17 files changed: 123 ins; 45 del; 28 mod 8363998: Implement Compressed Class Pointers for 32-bit Reviewed-by: rkennke, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/26491 From yzheng at openjdk.org Sun Aug 3 20:56:02 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Sun, 3 Aug 2025 20:56:02 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Could you please apply the following patch? diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java index 55d5492c2f8..fd08361f682 100644 --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, 2024, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2025, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -95,7 +95,7 @@ public boolean isCompressible() { } private boolean canBeStoredInCompressibleMetaSpace() { - if (metaspaceObject instanceof HotSpotResolvedJavaType t && !t.isArray()) { + if (!HotSpotVMConfig.config().useClassMetaspaceForAllClasses && metaspaceObject instanceof HotSpotResolvedJavaType t && !t.isArray()) { // As of JDK-8338526, interface and abstract types are not stored // in compressible metaspace. return !t.isInterface() && !t.isAbstract(); diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java index bc2e121fe90..449b315e467 100644 --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -67,6 +67,8 @@ static String getHostArchitectureName() { final boolean useCompressedOops = getFlag("UseCompressedOops", Boolean.class); + final boolean useClassMetaspaceForAllClasses = getFlag("UseClassMetaspaceForAllClasses", Boolean.class); + final int objectAlignment = getFlag("ObjectAlignmentInBytes", Integer.class); final int klassOffsetInBytes = getFieldValue("CompilerToVM::Data::oopDesc_klass_offset_in_bytes", Integer.class, "int"); ------------- PR Comment: https://git.openjdk.org/jdk/pull/26579#issuecomment-3148692596 From liach at openjdk.org Mon Aug 4 00:24:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 4 Aug 2025 00:24:15 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs Message-ID: Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). ------------- Commit messages: - Years - Roll back Objects.rNN for now - Review remarks - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Bork - Try generify the NPE tracing API - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Perf concerns - Tests, MPs based prints - Objects rNN better message Changes: https://git.openjdk.org/jdk/pull/26600/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364588 Stats: 390 lines in 12 files changed: 335 ins; 13 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/26600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600 PR: https://git.openjdk.org/jdk/pull/26600 From liach at openjdk.org Mon Aug 4 00:24:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 4 Aug 2025 00:24:15 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). Thanks for the preliminary review. After some thinking, to avoid wasting review cycles, I am pulling the common infrastructure for requireNonNull and Checks::nullCheck into a JDK-internal API, and the changes here are mostly confined to runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3148805289 From dholmes at openjdk.org Mon Aug 4 00:24:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Aug 2025 00:24:15 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). src/hotspot/share/classfile/javaClasses.cpp line 3060: > 3058: } > 3059: > 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) { Suggestion: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) { src/hotspot/share/interpreter/bytecodeUtils.hpp line 40: > 38: static bool get_NPE_message_at(outputStream* ss, Method* method, int bci); > 39: // NPE extended message. Return true if string is printed. > 40: static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot); Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248868942 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248881502 From liach at openjdk.org Mon Aug 4 00:24:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 4 Aug 2025 00:24:15 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 21:05:53 GMT, David Holmes wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). > > src/hotspot/share/classfile/javaClasses.cpp line 3060: > >> 3058: } >> 3059: >> 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) { > > Suggestion: > > bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) { Done. > src/hotspot/share/interpreter/bytecodeUtils.hpp line 40: > >> 38: static bool get_NPE_message_at(outputStream* ss, Method* method, int bci); >> 39: // NPE extended message. Return true if string is printed. >> 40: static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot); > > Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ. Done, and documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250200947 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250201005 From david.holmes at oracle.com Mon Aug 4 02:20:38 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Aug 2025 12:20:38 +1000 Subject: RFC: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <281f2b83-30ad-46c2-9a5b-c445d57d3784@oracle.com> References: <281f2b83-30ad-46c2-9a5b-c445d57d3784@oracle.com> Message-ID: <4384da3a-26af-441e-a1b1-ba33dbe2b90f@oracle.com> Seems there is no real interest in a pre-discussion so I will make the PR non-draft. David On 25/07/2025 11:54 am, David Holmes wrote: > This is a proposal to standardize on the use of os::snprintf and > os::snprintf_checked across the hotspot code base, and to disallow use > of the C library variants. (It does not touch use of jio_printf at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the > buffer is large enough returns the number of bytes written (excluding > the null byte), else (buffer is too small) the number of characters > (excluding the terminating null byte) which would have been written to > the final string if enough space had been available. Thus, a return > value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation > management, we provide `os::xxx` wrapper functions as described below > and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should > encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character > sets > - invalid parameters (null buffers, specifying a limit > size of the > buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as > we return `int`). > > As these should simply never occur, we handle the checks for -1 at the > lowest-level (`os::vsnprintf`) with an assertion, and accompanying > precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return > value for subsequent use, and for whom truncation (if it were possible) > would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns > nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return > value for subsequent operations (e.g. chains of `snprintf` where you > advance the buffer pointer based on previous writes), but again for whom > truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own > assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, > but don't need to do anything about it themselves, and for whom the > return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion > can be useful for guiding buffer sizing decisions, but in product mode > truncation is not an error. > > 4. Those who present a buffer but know that truncation is a possibility, > and either need to handle it themselves, or else need to use the return > value in subsequent operations. > > These clients are also directed to use `os::snprintf`. > > In summary we provide the following API: > - `[[nodiscard]] int os::vsnprintf` is the building block for the other > methods, it: > ? - asserts on precondition failures > ? - asserts on error > ? - guarantees null-termination in the case of unexpected errors (as > the standards are still unclear on that point > ? - is declared `[[nodiscard[]]` so that callers cannot ignore the > return value (they can explicitly cast to `void` to indicate they dn't > need it) > - `void os::snprintf_checked` > ? - calls `os::vnsprintf`` so asserts on errors > ? - asserts on truncation > - [[nodiscard]] int os::snprintf > ? - calls `os::vnsprintf`` so asserts on errors > > In terms of the effects on the existing code we: > - Change callers of `::snprintf`/`os::snprintf` that ignore the return > value and ensure the buffer is large enough to use `os::snprintf_checked` > ? - those that allow truncation to happen must use `os::snprintf`. > - Change all callers of `::snprintf`/`os::snprintf` that use the return > value to use `os::snprintf`, plus any additional assertions needed > - Change the 9 callers of `os::snprintf_checked` that do use the return > value, to use `os::snprintf` with their own assertions added > - Callers of `os::vnsprintf` are adjusted as needed > > There is a draft PR comprising of multiple dependent commits so that you > can view things in stages. There has been a suggestion to integrate this > in a staged way under different JBS issues to make reviewing easier. > There are 46 modified files. The bulk of changes replace calls to > snprintf/os::snprintf with calls to os::snprintf_checked. > > https://github.com/openjdk/jdk/pull/26470 > > Comments welcomed. > > Thanks, > David > From dholmes at openjdk.org Mon Aug 4 02:25:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Aug 2025 02:25:37 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked Message-ID: TBD ------------- Commit messages: - Make os::snprintf "nodiscard" and adjust final callsites - Convert os::snprintf() to os::snprintf_checked() where appropriate. - Forbid C library snprintf - Change return-value using snprintf to explicit os::snprintf - Change raw snprintf to os::snprintf_checked, whereever truncation would not - Change os::snprintf_checked to be void function. - Mark os::vsnprintf as nodiscard and update the callsites. Changes: https://git.openjdk.org/jdk/pull/26470/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26470&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347707 Stats: 197 lines in 46 files changed: 15 ins; 5 del; 177 mod Patch: https://git.openjdk.org/jdk/pull/26470.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26470/head:pull/26470 PR: https://git.openjdk.org/jdk/pull/26470 From jjiang at openjdk.org Mon Aug 4 07:43:35 2025 From: jjiang at openjdk.org (John Jiang) Date: Mon, 4 Aug 2025 07:43:35 GMT Subject: RFR: 8364597: Replace THL A29 Limited with Tencent Message-ID: `THL A29 Limited` was a `Tencent` company but was dissolved. So, the copyright notes just use `Tencent` directly. ------------- Commit messages: - 8364597: Replace THL A29 Limited with Tencent Changes: https://git.openjdk.org/jdk/pull/26614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26614&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364597 Stats: 67 lines in 58 files changed: 0 ins; 9 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/26614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26614/head:pull/26614 PR: https://git.openjdk.org/jdk/pull/26614 From dholmes at openjdk.org Mon Aug 4 07:44:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Aug 2025 07:44:06 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v23] In-Reply-To: <-SbK2XJEVxUmf9O-3-mnb3-ULRDnmxT-U3RUs_LDdVQ=.1e31ff6e-3455-4cbe-b323-cdecb94fe08e@github.com> References: <-SbK2XJEVxUmf9O-3-mnb3-ULRDnmxT-U3RUs_LDdVQ=.1e31ff6e-3455-4cbe-b323-cdecb94fe08e@github.com> Message-ID: On Fri, 1 Aug 2025 09:19:55 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - 8357086: Fixed merge conflict > - 8357086: Removed extra line > - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD > - 8357086: Small fixes > - 8357086: Made physical_memory() return void > - 8357086: Fixed behavior of total_swap_space on Linux > - 8357086: Addressed reviewer's comments. > - 8357086: Fixed void conversion. > - 8357086: Addressed reviewer's comments > - 8357086: Addressed reviewer's comments > - ... and 14 more: https://git.openjdk.org/jdk/compare/d80b5c87...f9b2c6d8 src/hotspot/share/runtime/arguments.cpp line 1507: > 1505: void Arguments::set_heap_size() { > 1506: julong phys_mem; > 1507: size_t physical_mem_val = 0; I'm not seeing why you needed to introduce this as a temporary. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2250670601 From duke at openjdk.org Mon Aug 4 08:23:00 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 4 Aug 2025 08:23:00 GMT Subject: Integrated: 8364519: Sort share/classfile includes In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 10:03:39 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in hotspot/share/classfile using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted. > > Passes tier1. This pull request has now been integrated. Changeset: 3387b319 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/3387b3195c8f2a9faa3c93322f6e11ce2aad3e2b Stats: 48 lines in 20 files changed: 21 ins; 26 del; 1 mod 8364519: Sort share/classfile includes Reviewed-by: shade, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26590 From duke at openjdk.org Mon Aug 4 08:43:48 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 4 Aug 2025 08:43:48 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - 8357086: Addressed reviewer's comments - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Fixed merge conflict - 8357086: Removed extra line - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD - 8357086: Small fixes - 8357086: Made physical_memory() return void - 8357086: Fixed behavior of total_swap_space on Linux - 8357086: Addressed reviewer's comments. - 8357086: Fixed void conversion. - ... and 16 more: https://git.openjdk.org/jdk/compare/57553ca1...a3898f43 ------------- Changes: https://git.openjdk.org/jdk/pull/25450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=23 Stats: 250 lines in 23 files changed: 89 ins; 2 del; 159 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From mgronlun at openjdk.org Mon Aug 4 09:58:36 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 4 Aug 2025 09:58:36 GMT Subject: [jdk25] RFR: 8364258: ThreadGroup constant pool serialization is not normalized Message-ID: 8364258: ThreadGroup constant pool serialization is not normalized ------------- Commit messages: - Backport 3bc449797eb59f9770d2a06d260b23b6efd5ff0f Changes: https://git.openjdk.org/jdk/pull/26618/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26618&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364258 Stats: 938 lines in 12 files changed: 431 ins; 482 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26618/head:pull/26618 PR: https://git.openjdk.org/jdk/pull/26618 From ayang at openjdk.org Mon Aug 4 13:49:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Aug 2025 13:49:14 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: > Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into sgc-whitebox - sgc-whitebox ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26528/files - new: https://git.openjdk.org/jdk/pull/26528/files/d95ce7ed..7be7d3de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26528&range=00-01 Stats: 13614 lines in 375 files changed: 8956 ins; 3887 del; 771 mod Patch: https://git.openjdk.org/jdk/pull/26528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26528/head:pull/26528 PR: https://git.openjdk.org/jdk/pull/26528 From dnsimon at openjdk.org Mon Aug 4 15:04:04 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 4 Aug 2025 15:04:04 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore wrote: >> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Restore c2 optimization. src/hotspot/share/prims/jvm.cpp line 1744: > 1742: JVM_END > 1743: > 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls)) What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2251770425 From sangheki at openjdk.org Mon Aug 4 16:26:55 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 4 Aug 2025 16:26:55 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:49:14 GMT, Albert Mingkun Yang wrote: >> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-whitebox > - sgc-whitebox LGTM ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26528#pullrequestreview-3084933418 From kvn at openjdk.org Mon Aug 4 16:46:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Aug 2025 16:46:53 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3084984596 From eastigeevich at openjdk.org Mon Aug 4 17:14:58 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 4 Aug 2025 17:14:58 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> Message-ID: On Fri, 1 Aug 2025 16:05:42 GMT, Mikhail Ablakatov wrote: >> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. >> >> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. >> >> This has passed tier1-3 and jcstress testing on AArch64. > > Mikhail Ablakatov 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 'master' > - Address review comments from @theRealAph and @eastig > - use relocInfo::relocType instead of TrampolineCallKind > - move rtype from keys to values; reduce the footprint of the patch > - Lift the vm.opt.TieredCompilation == null requirement from the tests > - Combine the two shared trampoline request hash tables > - 8359359: AArch64: share trampolines between static calls to the same method > > Modify the C2 compiler to share trampoline stubs between static calls > that resolve to the same callee method. Since the relocation target for > all static calls is initially set to the static call resolver stub, the > call's target alone cannot be used to distinguish between different > static method calls. Instead, trampoline stubs should be shared based > on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of > trampolines among static calls. However, due to imprecise log analysis, > the test currently passes even when trampolines are not shared. > Additionally, comments within the test suggest ambiguity regarding > whether it was intended to assess trampoline sharing for static calls > or runtime calls. To address these issues and eliminate ambiguity, this > patch renames and updates the existing test. Furthermore, a new test is > introduced, using the existing one as a foundation, to accurately > evaluate trampoline sharing for both static and runtime calls. src/hotspot/share/asm/codeBuffer.hpp line 545: > 543: > 544: typedef Pair> Offsets; > 545: typedef ResizeableResourceHashtable SharedTrampolineRequests; I think code can be simplified. For example, let's a Java method `A` call a static Java method `B` twice and a static Java method `C` three times. You will be having the following in `SharedTrampilneRequests`: key -> value {B} -> {relocInfo::static_call_type, {call_B_offset1, call_B_offset2}} {C} -> {relocInfo::static_call_type, {call_C_offset1, call_C_offset2, call_C_offset3}} When you iterate trampoline requests, you don't use the key for a destination if it is for a static call. Instead you use `SharedRuntime::get_resolve_static_call_stub()` as a destination. This means your requests don't differ from requests for `runtime_call_type` trampolines. `runtime_call_type` trampolines have final destinations but `static_call_type` have a resolver as a destination. So you actually have: key -> value (trampoline_id1} -> {get_resolve_static_call_stub, {call_B_offset1, call_B_offset2}} {trampoline_id2} -> {get_resolve_static_call_stub, {call_C_offset1, call_C_offset2, call_C_offset3}} {trampoilen_id3} -> {some_runtime_call, {call_RT_offset1, call_RT_offset2, call_RT_offset3}} IMO based on `SharedRuntime::resolve_helper`, we can have shared trampolines for `relocInfo::opt_virtual_call_type` and `relocInfo::virtual_call_type`. Their trampolines have the corresponding resolver set. I don't see we write anything specific to a call site into a trampoline. We can have the following: class SharedTrampolineRequest { LinkedListImpl _offsets; address _dest; #ifndef PRODUCT relocInfo::relocType; // This can be used in asserts to check a shared trampoline is for the same relocType #endif }; // A set of requests for shared trampolines. // We use a hash table to implement the set. // A trampoline id is a key in the table. // We don't store an id in SharedTrampolineRequest because it is only used for the table. typedef uintptr_t SharedTrampolineId; typedef ResizeableResourceHashtable SharedTrampolineRequests; You will need to modify `MacroAssembler::trampoline_call`: SharedTrampolineId tramp_id = (entry.rspec().type() == relocInfo::runtime_call_type) ? target : callee; code()->share_trampoline_for(tramp_id, entry.target(), offset()); New code for `share_trampoline_for(NOT_PRODUCT_ARG(relocInfo::relocType rel_type) tramp_id, target, offset )`: bool created; SharedTrampolineRequest tramp_req = _shared_trampoline_requests->put_if_absent(tramp_id, &created); if (created) { _shared_trampoline_requests->maybe_grow(); tramp_req->set_target(target); NOT_PRODUCT(tramp_req->set_reloc_type(rel_type)); } assert(tramp_req->reloc_type() == rel_type); tramp_req->offsets()->add(offset); _finalize_stubs = true; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2252117186 From eastigeevich at openjdk.org Mon Aug 4 17:42:57 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 4 Aug 2025 17:42:57 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> Message-ID: <4j3wCRqhS-5nHML4TYbpQnfsuxcC3Rj9T49riuifGYw=.5fd293d8-db70-4461-ab0c-5aea817171f2@github.com> On Fri, 1 Aug 2025 16:05:42 GMT, Mikhail Ablakatov wrote: >> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. >> >> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. >> >> This has passed tier1-3 and jcstress testing on AArch64. > > Mikhail Ablakatov 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 'master' > - Address review comments from @theRealAph and @eastig > - use relocInfo::relocType instead of TrampolineCallKind > - move rtype from keys to values; reduce the footprint of the patch > - Lift the vm.opt.TieredCompilation == null requirement from the tests > - Combine the two shared trampoline request hash tables > - 8359359: AArch64: share trampolines between static calls to the same method > > Modify the C2 compiler to share trampoline stubs between static calls > that resolve to the same callee method. Since the relocation target for > all static calls is initially set to the static call resolver stub, the > call's target alone cannot be used to distinguish between different > static method calls. Instead, trampoline stubs should be shared based > on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of > trampolines among static calls. However, due to imprecise log analysis, > the test currently passes even when trampolines are not shared. > Additionally, comments within the test suggest ambiguity regarding > whether it was intended to assess trampoline sharing for static calls > or runtime calls. To address these issues and eliminate ambiguity, this > patch renames and updates the existing test. Furthermore, a new test is > introduced, using the existing one as a foundation, to accurately > evaluate trampoline sharing for both static and runtime calls. This PR needs additional research and changes. ------------- Changes requested by eastigeevich (Committer). PR Review: https://git.openjdk.org/jdk/pull/25954#pullrequestreview-3085207313 From duke at openjdk.org Mon Aug 4 17:45:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 17:45:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic Message-ID: Hi all, This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() CPUTimeUsage::GC::gc_threads() CPUTimeUsage::GC::vm_thread() CPUTimeUsage::GC::stringdedup() CPUTimeUsage::Runtime::vm_thread() I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: [12.517s][info][cpu] === CPU time Statistics ============================================================= [12.517s][info][cpu] CPUs [12.517s][info][cpu] s % utilized [12.517s][info][cpu] Process [12.517s][info][cpu] Total 175.7628 100.00 14.0 [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 [12.518s][info][cpu] ===================================================================================== Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. ------------- Commit messages: - Make GC CPU time framework generic Changes: https://git.openjdk.org/jdk/pull/26621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364638 Stats: 229 lines in 11 files changed: 170 ins; 44 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 4 17:53:59 2025 From: duke at openjdk.org (duke) Date: Mon, 4 Aug 2025 17:53:59 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3] In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> References: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> Message-ID: On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa wrote: >> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. >> >> The command to run all range specific micro-benchmarks is posted below. >> >> `make test TEST="micro:SinhPerf.SinhPerfRanges"` >> >> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. >> >> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. >> >> | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | >> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | >> | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | >> | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | >> | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | >> | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | >> | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | >> >> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2 @missa-prime Your change (at version 3ab7ab3e752991e2eb7f43af68380f1e66be9bec) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3151813299 From asmehra at openjdk.org Mon Aug 4 18:18:58 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 4 Aug 2025 18:18:58 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using FormatBuffer [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 29 Jul 2025 07:19:31 GMT, Johan Sj?len wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> More compile failure fix >> >> Signed-off-by: Ashutosh Mehra > > It seems like we can just use a `stringStream` instead and not have to deal with any overflow of some buffer, since we strdup at the end. @jdksjolen I updated the code as per your suggestion. Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26515#issuecomment-3137144691 From duke at openjdk.org Mon Aug 4 18:24:09 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 4 Aug 2025 18:24:09 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v23] In-Reply-To: References: <-SbK2XJEVxUmf9O-3-mnb3-ULRDnmxT-U3RUs_LDdVQ=.1e31ff6e-3455-4cbe-b323-cdecb94fe08e@github.com> Message-ID: On Mon, 4 Aug 2025 07:41:03 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 24 commits: >> >> - 8357086: Fixed merge conflict >> - 8357086: Removed extra line >> - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD >> - 8357086: Small fixes >> - 8357086: Made physical_memory() return void >> - 8357086: Fixed behavior of total_swap_space on Linux >> - 8357086: Addressed reviewer's comments. >> - 8357086: Fixed void conversion. >> - 8357086: Addressed reviewer's comments >> - 8357086: Addressed reviewer's comments >> - ... and 14 more: https://git.openjdk.org/jdk/compare/d80b5c87...f9b2c6d8 > > src/hotspot/share/runtime/arguments.cpp line 1507: > >> 1505: void Arguments::set_heap_size() { >> 1506: julong phys_mem; >> 1507: size_t physical_mem_val = 0; > > I'm not seeing why you needed to introduce this as a temporary. ?? This is a leftover from the latest change `os::physical_memory(size_t& val) -> size_t os::physical_memory()`. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2250811229 From coleenp at openjdk.org Mon Aug 4 18:41:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Aug 2025 18:41:20 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Apply Yudi patch for graal. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26579/files - new: https://git.openjdk.org/jdk/pull/26579/files/79399d5d..b9e2e166 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26579&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26579&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26579.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26579/head:pull/26579 PR: https://git.openjdk.org/jdk/pull/26579 From yzheng at openjdk.org Mon Aug 4 18:41:20 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 4 Aug 2025 18:41:20 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: <_xyH5Qpo3w84dlxoEDONYOSiBRIFAkkibBxrQTwd6QE=.7be2eecc-f390-4cdc-9bd0-de35d84f0242@github.com> On Mon, 4 Aug 2025 18:34:52 GMT, Coleen Phillimore wrote: >> This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. >> Tested with tier1-4 with the flag off, and 1-4 with the flag on. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Apply Yudi patch for graal. LGTM ------------- Marked as reviewed by yzheng (Committer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3085349076 From kvn at openjdk.org Mon Aug 4 18:41:21 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Aug 2025 18:41:21 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 18:34:52 GMT, Coleen Phillimore wrote: >> This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. >> Tested with tier1-4 with the flag off, and 1-4 with the flag on. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Apply Yudi patch for graal. Re-approved. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3085351452 From shade at openjdk.org Mon Aug 4 18:44:31 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Aug 2025 18:44:31 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 18:41:20 GMT, Coleen Phillimore wrote: >> This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. >> Tested with tier1-4 with the flag off, and 1-4 with the flag on. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Apply Yudi patch for graal. Let's go! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26579#pullrequestreview-3085368923 From missa at openjdk.org Mon Aug 4 18:51:28 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 4 Aug 2025 18:51:28 GMT Subject: Integrated: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. > > The command to run all range specific micro-benchmarks is posted below. > > `make test TEST="micro:SinhPerf.SinhPerfRanges"` > > The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. > > For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. > > | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | > | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | > | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | > | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | > | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | > | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | > | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | > > Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. This pull request has now been integrated. Changeset: 05f8a6fc Author: Mohamed Issa Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/05f8a6fca87d472a80e5952ddc90d8fa6589c75c Stats: 742 lines in 26 files changed: 739 ins; 0 del; 3 mod 8360559: Optimize Math.sinh for x86 64 bit platforms Reviewed-by: sviswanathan, sparasa ------------- PR: https://git.openjdk.org/jdk/pull/26152 From rriggs at openjdk.org Mon Aug 4 19:11:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 4 Aug 2025 19:11:16 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3] In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> References: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> Message-ID: On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa wrote: >> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. >> >> The command to run all range specific micro-benchmarks is posted below. >> >> `make test TEST="micro:SinhPerf.SinhPerfRanges"` >> >> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. >> >> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. >> >> | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | >> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | >> | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | >> | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | >> | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | >> | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | >> | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | >> >> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2 This seems to be failing in the CI on the build of: linux-x64-debug-nopch [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'? [2025-08-04T19:02:29,373Z] 293 | StubCodeMark mark(this, stub_id); [2025-08-04T19:02:29,373Z] | ^~~~~~~ [2025-08-04T19:02:29,373Z] | StubId [2025-08-04T19:02:29,373Z] ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3152016875 From duke at openjdk.org Mon Aug 4 19:34:01 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 19:34:01 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove assert which may not hold in tests that exists very fast It takes some time before the OS updates the underlying counters so process CPU time may be out of sync with regards to magnitude order compared to thread CPU time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/4f74c2bd..6a6e3996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From missa at openjdk.org Mon Aug 4 19:50:11 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 4 Aug 2025 19:50:11 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3] In-Reply-To: References: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> Message-ID: On Mon, 4 Aug 2025 19:06:10 GMT, Roger Riggs wrote: > This seems to be failing in the CI on the build of: linux-x64-debug-nopch > > ``` > [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'? > [2025-08-04T19:02:29,373Z] 293 | StubCodeMark mark(this, stub_id); > [2025-08-04T19:02:29,373Z] | ^~~~~~~ > [2025-08-04T19:02:29,373Z] | StubId > [2025-08-04T19:02:29,373Z] > ``` Thanks for notification. It looks like an incorrect type declaration. I'll submit a fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3152125201 From duke at openjdk.org Mon Aug 4 19:53:24 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 4 Aug 2025 19:53:24 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Prefer returning 0 over +/-inf,nan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/6a6e3996..216ba811 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From coleenp at openjdk.org Mon Aug 4 20:15:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Aug 2025 20:15:19 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 18:41:20 GMT, Coleen Phillimore wrote: >> This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. >> Tested with tier1-4 with the flag off, and 1-4 with the flag on. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Apply Yudi patch for graal. GHA looks clean ------------- PR Comment: https://git.openjdk.org/jdk/pull/26579#issuecomment-3152203209 From coleenp at openjdk.org Mon Aug 4 20:15:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Aug 2025 20:15:20 GMT Subject: Integrated: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 18:13:30 GMT, Coleen Phillimore wrote: > This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. > Tested with tier1-4 with the flag off, and 1-4 with the flag on. This pull request has now been integrated. Changeset: da3a5da8 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/da3a5da81bc1d6fe1e47e3a4e65bf390ee1d39a0 Stats: 12 lines in 5 files changed: 6 ins; 0 del; 6 mod 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace Reviewed-by: shade, kvn, yzheng, stuefe, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26579 From coleenp at openjdk.org Mon Aug 4 21:20:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Aug 2025 21:20:11 GMT Subject: RFR: 8343218: Add option to disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 18:41:20 GMT, Coleen Phillimore wrote: >> This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace. Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this. A future change will be to remove this code. >> Tested with tier1-4 with the flag off, and 1-4 with the flag on. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Apply Yudi patch for graal. Thank you Aleksey,Thomas, David, Vladimir and Yudi. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26579#issuecomment-3152434736 From dlong at openjdk.org Mon Aug 4 21:22:57 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:22:57 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v4] In-Reply-To: References: Message-ID: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: skip icache flush if nothing changed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/a06b3446..840750ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From dlong at openjdk.org Mon Aug 4 21:26:22 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:26:22 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. Dean Long has updated the pull request incrementally with one additional commit since the last revision: one unconditional release should be enough ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26399/files - new: https://git.openjdk.org/jdk/pull/26399/files/840750ab..d9e93db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399 PR: https://git.openjdk.org/jdk/pull/26399 From dlong at openjdk.org Mon Aug 4 21:26:23 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Aug 2025 21:26:23 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> Message-ID: <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> On Fri, 1 Aug 2025 21:38:11 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PPC64 > > src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: > >> 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); >> 83: // Swap in the new value >> 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); > > We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? I think you are right. But your question about release is making me wonder if we need acquire as well. For example if two threads are racing to disarm, is there a memory visibility problem if we do not use acquire for the CAS, or if we did the release only on a successful CAS? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2252604613 From mdoerr at openjdk.org Mon Aug 4 21:50:09 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Aug 2025 21:50:09 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3] In-Reply-To: <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> References: <_8Z-PXaFqGay1pHqcJmeWXrOFv4QQVqnJG2RuZ7rzTk=.34cc6ecb-e189-461c-971b-f59f899372f5@github.com> <31qxrkcScTxkk9gjEGGuEZEyCnpLe9VapvbgIpOTpow=.5a8777ab-35bf-48e2-8900-3d6ed5c19cf7@github.com> Message-ID: On Mon, 4 Aug 2025 21:22:12 GMT, Dean Long wrote: >> src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84: >> >>> 82: nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */); >>> 83: // Swap in the new value >>> 84: uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release); >> >> We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here? > > I think you are right. But your question about release is making me wonder if we need acquire as well. For example if two threads are racing to disarm, is there a memory visibility problem if we do not use acquire for the CAS, or if we do the release only on a successful CAS on the other platforms. Correct. The acquire barrier is at the end of the nmethod entry barrier: https://github.com/openjdk/jdk/blob/f96b6bcd4ddbb1d0e0a76d9f4e3b43bec20dcb7a/src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp#L203 It's not needed if we use a GC with `stw_instruction_and_data_patch`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2252641681 From dcubed at openjdk.org Mon Aug 4 23:31:09 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 4 Aug 2025 23:31:09 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v3] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [12.517s][info][cpu] === CPU time Statistics ============================================================= >> [12.517s][info][cpu] CPUs >> [12.517s][info][cpu] s % utilized >> [12.517s][info][cpu] Process >> [12.517s][info][cpu] Total 175.7628 100.00 14.0 >> [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 >> [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 >> [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 >> [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 >> [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 >> [12.518s][info][cpu] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Prefer returning 0 over +/-inf,nan Seems like JVM/TI folks will be interested also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3152782164 From dholmes at openjdk.org Tue Aug 5 03:03:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 03:03:04 GMT Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template specialization for unit [v6] In-Reply-To: <4P-hI1f0bLknqyybmbVFKn4FbpP91ClS_nlpmgrvnEs=.0b2a81f2-0fdc-4b6e-9dda-d7ad0e38ac1f@github.com> References: <4P-hI1f0bLknqyybmbVFKn4FbpP91ClS_nlpmgrvnEs=.0b2a81f2-0fdc-4b6e-9dda-d7ad0e38ac1f@github.com> Message-ID: <6JSFYVujOVVppyA4tR_1Bw8C5K0J-50FBpqUE2dWahc=.a5aae512-3581-4dac-887c-09bfb125154e@github.com> On Wed, 30 Jul 2025 09:44:41 GMT, Joel Sikstr?m wrote: >> Hello, >> >> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type. >> >> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT. >> >> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead. >> >> Testing: >> * Oracle's tier1-2 > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Revert extra whitespace Sorry for the delay. This seems fine to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25975#pullrequestreview-3086352078 From dlong at openjdk.org Tue Aug 5 04:00:09 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 5 Aug 2025 04:00:09 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: On Tue, 1 Jul 2025 09:11:32 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig 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-8308094-timeout > - Fix SIGALRM test > - Add timeout functionality to compiler threads src/hotspot/share/compiler/compileBroker.cpp line 236: > 234: { > 235: MutexLocker notifier(thread, CompileTaskWait_lock); > 236: thread->timeout_disarm(); Is holding the lock above important for disasming? If not, can we move the disarms from the if/else branches and do it unconditionally before the if? src/hotspot/share/compiler/compilerThread.cpp line 97: > 95: switch (signo) { > 96: case TIMEOUT_SIGNAL: { > 97: assert(!Atomic::load_acquire(&_timeout_armed), "compile task timed out"); Why do we need acquire? Only the current thread is ever going to be looking at this value, right? src/hotspot/share/compiler/compilerThread.cpp line 157: > 155: // Start the timer. > 156: timer_settime(_timeout_timer, 0, &its, nullptr); > 157: Atomic::release_store(&_timeout_armed, (bool) true); Same questions about release. Are other threads reading/writing this value? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2253044899 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2253045931 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2253046604 From dlong at openjdk.org Tue Aug 5 04:07:04 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 5 Aug 2025 04:07:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: On Tue, 1 Jul 2025 09:11:32 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig 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-8308094-timeout > - Fix SIGALRM test > - Add timeout functionality to compiler threads This looks correct, but would it be possible to move the Linux-specific code out of src/hotspot/share? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3153200663 From dholmes at openjdk.org Tue Aug 5 05:19:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 05:19:17 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 08:43:48 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - 8357086: Addressed reviewer's comments > - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs > - 8357086: Fixed merge conflict > - 8357086: Removed extra line > - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD > - 8357086: Small fixes > - 8357086: Made physical_memory() return void > - 8357086: Fixed behavior of total_swap_space on Linux > - 8357086: Addressed reviewer's comments. > - 8357086: Fixed void conversion. > - ... and 16 more: https://git.openjdk.org/jdk/compare/57553ca1...a3898f43 Overall I'm okay with the way the API has turned out here. Naturally it would be better if no errors were possible, but I think containers prevent that from being the case. I have a lot of stylistic comments, many pre-existing, and some notes for future cleanups. But happy to hit approve as a vote of confidence. Thanks src/hotspot/os/bsd/os_bsd.cpp line 137: > 135: > 136: bool os::available_memory(size_t& value) { > 137: return Bsd::available_memory(value); Just an aside for a future cleanup, but there is really no reason to have the indirection through e.g. `Bsd::available_memory`. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 675: > 673: julong phys_mem = static_cast(os::Linux::physical_memory()); > 674: log_trace(os, container)("total physical memory: " JULONG_FORMAT, phys_mem); > 675: jlong mem_limit = contrl->controller()->read_memory_limit_in_bytes(phys_mem); Another aside for a future cleanup: the container methods should be taking size_t not julong. src/hotspot/os/linux/os_linux.cpp line 297: > 295: if (OSContainer::is_containerized() && OSContainer::memory_and_swap_limit_in_bytes() > 0) { > 296: if (OSContainer::memory_limit_in_bytes() > 0) { > 297: value = static_cast(OSContainer::memory_and_swap_limit_in_bytes() - OSContainer::memory_limit_in_bytes()); Pre-existing but we should really only calls these functions once and store the result in a local. src/hotspot/os/linux/os_linux.cpp line 328: > 326: bool host_free_swap_ok = host_free_swap_f(host_free_swap); > 327: if (!total_swap_space_ok || !host_free_swap_ok) { > 328: assert(false, "sysinfo failed ? "); Pre-existing: the assert should be pushed down to where the `sysinfo` calls are so you could see which one failed - not that they can actually fail if called correctly. src/hotspot/os/linux/os_linux.cpp line 330: > 328: assert(false, "sysinfo failed ? "); > 329: return false; > 330: } Suggestion: size_t total_swap_space = 0; size_t host_free_swap = 0; if (!os::total_swap_space(total_swap_space) || !host_free_swap_f(host_free_swap)) { assert(false, "sysinfo failed ? "); return false; } src/hotspot/os/windows/os_windows.cpp line 870: > 868: } else { > 869: return false; > 870: } Suggestion: BOOL res = GlobalMemoryStatusEx(&ms); if (res == TRUE) { value = static_cast(ms.ullAvailPhys); } return res == TRUE; } Unfortunately `BOOL` is an implicit boolean. This applies to all the Windows functions. You could also assert that `res == TRUE` and report `GetlastError` if not. src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 418: > 416: #else > 417: size_t phys_mem = os::physical_memory(); > 418: return static_cast(phys_mem); Suggestion: return static_cast(os::physical_memory()); src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 532: > 530: TRACE_REQUEST_FUNC(PhysicalMemory) { > 531: size_t phys_mem = os::physical_memory(); > 532: u8 totalPhysicalMemory = static_cast(phys_mem); Suggestion: u8 totalPhysicalMemory = static_cast(os::physical_memory()); src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 536: > 534: event.set_totalSize(totalPhysicalMemory); > 535: size_t avail_mem = 0; > 536: (void)os::available_memory(avail_mem); Suggestion: size_t avail_mem = 0; // Return value ignored - defaulting to 0 on failure. (void)os::available_memory(avail_mem); src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 547: > 545: event.set_totalSize(static_cast(total_swap_space)); > 546: size_t free_swap_space = 0; > 547: (void)os::free_swap_space(free_swap_space); Suggestion: size_t total_swap_space = 0; // Return value ignored - defaulting to 0 on failure. (void)os::total_swap_space(total_swap_space); event.set_totalSize(static_cast(total_swap_space)); size_t free_swap_space = 0; // Return value ignored - defaulting to 0 on failure. (void)os::free_swap_space(free_swap_space); src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1362: > 1360: InstanceKlass* the_class = get_ik(_class_defs[i].klass); > 1361: size_t avail_mem = 0; > 1362: (void)os::available_memory(avail_mem); Suggestion: size_t avail_mem = 0; // Return value ignored - defaulting to 0 on failure. (void)os::available_memory(avail_mem); src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1529: > 1527: } > 1528: } > 1529: (void)os::available_memory(avail_mem); Suggestion: avail_mem = 0; // Return value ignored - defaulting to 0 on failure. (void)os::available_memory(avail_mem); src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4440: > 4438: // direct and indirect subclasses of the_class > 4439: size_t avail_mem = 0; > 4440: (void)os::available_memory(avail_mem); Suggestion: size_t avail_mem = 0; // Return value ignored - defaulting to 0 on failure. (void)os::available_memory(avail_mem); src/hotspot/share/prims/whitebox.cpp line 2516: > 2514: LINUX_ONLY(return static_cast(os::Linux::physical_memory());) > 2515: size_t phys_mem = os::physical_memory(); > 2516: return static_cast(phys_mem); Suggestion: return static_cast(LINUX_ONLY(os::Linux::physical_memory()) NOT_LINUX(os::physical_memory())); Though this seems like a bad code "smell" to me - there is something wrong with our notion of "physical memory" if we have to make this distinction. src/hotspot/share/runtime/os.hpp line 343: > 341: > 342: static size_t physical_memory(); > 343: static bool has_allocatable_memory_limit(size_t* limit); Future cleanup: for consistency should this now also take a reference? src/hotspot/share/services/heapDumper.cpp line 2616: > 2614: // Lets ensure we have at least 20MB per thread. > 2615: size_t free_memory = 0; > 2616: (void)os::free_memory(free_memory); Suggestion: size_t free_memory = 0; // Return value ignored - defaulting to 0 on failure. (void)os::free_memory(free_memory); src/hotspot/share/utilities/globalDefinitions.hpp line 1366: > 1364: > 1365: // Dummy placeholder for use of [[nodiscard]] > 1366: #define ATTRIBUTE_NODISCARD Stay-tuned we may actually be able to use `[[nodiscard]]` for real. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3086467651 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253073149 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253077906 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253087855 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253092957 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253089924 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253099723 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253104891 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253106908 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253108762 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253109375 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253109727 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253112611 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253113166 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253115953 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253125260 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253126156 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253127032 From dholmes at openjdk.org Tue Aug 5 05:45:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 05:45:06 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v6] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 01:43:37 GMT, Alex Menkov wrote: >> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. >> >> Testing: tier1..5 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > fix broken build src/hotspot/share/classfile/javaClasses.cpp line 1885: > 1883: } > 1884: > 1885: oop java_lang_Thread::async_get_stack_trace(jobject jthread, TRAPS) { Please add a comment describing how the method works for virtual threads, and what returning null implies. src/hotspot/share/classfile/javaClasses.cpp line 1897: > 1895: class GetStackTraceHandshakeClosure : public HandshakeClosure { > 1896: public: > 1897: const Handle _thread_oop; Thanks for making this change! Very confusing otherwise. src/hotspot/share/classfile/javaClasses.cpp line 1939: > 1937: // Target thread has been unmounted. > 1938: return; > 1939: } Shouldn't we set `carrier = true` if we don't return here? Or am I misunderstanding what "carrier" means here? src/hotspot/share/classfile/javaClasses.cpp line 1941: > 1939: bool carrier = false; > 1940: if (java_lang_VirtualThread::is_instance(_java_thread())) { > 1941: // if (thread->vthread() != _java_thread()) // We might be inside a System.executeOnCarrierThread Need to check with @AlanBateman whether this check is also needed (he does both in his draft PR). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2253138892 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2253140711 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2253161591 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2253160696 From alanb at openjdk.org Tue Aug 5 06:32:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Aug 2025 06:32:07 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v6] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 05:39:03 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> fix broken build > > src/hotspot/share/classfile/javaClasses.cpp line 1941: > >> 1939: bool carrier = false; >> 1940: if (java_lang_VirtualThread::is_instance(_java_thread())) { >> 1941: // if (thread->vthread() != _java_thread()) // We might be inside a System.executeOnCarrierThread > > Need to check with @AlanBateman whether this check is also needed (he does both in his draft PR). ThreadSnapshotFactory::get_thread_snapshot needs to fail (and the caller retry) if called while the target virtual thread is in transition. This is because it captures the thread state in addition to the stack trace, and several other properties. So this is why (in the draft changes) it checks that thread identity is set and that the continuation is mounted. java_lang_Thread::async_get_stack_trace just needs to walk the continuation stack so checking that the continuation is mounted should be enough here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2253284124 From jsikstro at openjdk.org Tue Aug 5 07:47:13 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 5 Aug 2025 07:47:13 GMT Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template specialization for unit [v7] In-Reply-To: References: Message-ID: <_FLCi2eIdu0hzKrNBb08oFhVXcHZ5EFFo-mC53i12h8=.1b6c0c6a-22ed-4f6a-a8fb-eb0aadd83c6a@github.com> > Hello, > > PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type. > > To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT. > > ProcSmapsSummary::print_on in memMapPrinter_macosx and PSAdaptiveSizePolicy::print_stats in psAdaptiveSizePolicy.cpp are the only places that use PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead. > > Testing: > * Oracle's tier1-2 Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into JDK-8360515_properfmtargs - Revert extra whitespace - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp - Other alternative - More consistency - Merge branch 'master' into JDK-8360515_properfmtargs - Merge branch 'master' into JDK-8360515_properfmtargs - 8360515: PROPERFMTARGS should always use size_t template specialization for unit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25975/files - new: https://git.openjdk.org/jdk/pull/25975/files/b4f7c18e..b5bb4b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=05-06 Stats: 16883 lines in 442 files changed: 10489 ins; 5424 del; 970 mod Patch: https://git.openjdk.org/jdk/pull/25975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25975/head:pull/25975 PR: https://git.openjdk.org/jdk/pull/25975 From jsikstro at openjdk.org Tue Aug 5 07:47:14 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 5 Aug 2025 07:47:14 GMT Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template specialization for unit [v5] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 14:15:11 GMT, Thomas Stuefe wrote: >> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp >> - Other alternative > > Why is the cast needed, now? Thank you for the reviews! @tstuefe @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/25975#issuecomment-3153883668 From jsikstro at openjdk.org Tue Aug 5 07:47:15 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 5 Aug 2025 07:47:15 GMT Subject: Integrated: 8360515: PROPERFMTARGS should always use size_t template specialization for unit In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 11:10:41 GMT, Joel Sikstr?m wrote: > Hello, > > PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type. > > To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT. > > ProcSmapsSummary::print_on in memMapPrinter_macosx and PSAdaptiveSizePolicy::print_stats in psAdaptiveSizePolicy.cpp are the only places that use PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead. > > Testing: > * Oracle's tier1-2 This pull request has now been integrated. Changeset: febd4b26 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/febd4b26b2c87030affd9f93524e0d951cbe74e7 Stats: 8 lines in 3 files changed: 1 ins; 0 del; 7 mod 8360515: PROPERFMTARGS should always use size_t template specialization for unit Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/25975 From duke at openjdk.org Tue Aug 5 08:27:08 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 5 Aug 2025 08:27:08 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v25] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/a3898f43..fbceea99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=23-24 Stats: 28 lines in 7 files changed: 15 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Tue Aug 5 08:27:16 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 5 Aug 2025 08:27:16 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 04:51:10 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 26 commits: >> >> - 8357086: Addressed reviewer's comments >> - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs >> - 8357086: Fixed merge conflict >> - 8357086: Removed extra line >> - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD >> - 8357086: Small fixes >> - 8357086: Made physical_memory() return void >> - 8357086: Fixed behavior of total_swap_space on Linux >> - 8357086: Addressed reviewer's comments. >> - 8357086: Fixed void conversion. >> - ... and 16 more: https://git.openjdk.org/jdk/compare/57553ca1...a3898f43 > > src/hotspot/os/windows/os_windows.cpp line 870: > >> 868: } else { >> 869: return false; >> 870: } > > Suggestion: > > BOOL res = GlobalMemoryStatusEx(&ms); > if (res == TRUE) { > value = static_cast(ms.ullAvailPhys); > } > return res == TRUE; > } > > Unfortunately `BOOL` is an implicit boolean. > > This applies to all the Windows functions. > > You could also assert that `res == TRUE` and report `GetlastError` if not. Addressed, though it looks like GlobalMemoryStatusEx never fails. > src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 418: > >> 416: #else >> 417: size_t phys_mem = os::physical_memory(); >> 418: return static_cast(phys_mem); > > Suggestion: > > return static_cast(os::physical_memory()); Addressed. > src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 532: > >> 530: TRACE_REQUEST_FUNC(PhysicalMemory) { >> 531: size_t phys_mem = os::physical_memory(); >> 532: u8 totalPhysicalMemory = static_cast(phys_mem); > > Suggestion: > > u8 totalPhysicalMemory = static_cast(os::physical_memory()); Addressed. > src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 536: > >> 534: event.set_totalSize(totalPhysicalMemory); >> 535: size_t avail_mem = 0; >> 536: (void)os::available_memory(avail_mem); > > Suggestion: > > size_t avail_mem = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::available_memory(avail_mem); Addressed. > src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 547: > >> 545: event.set_totalSize(static_cast(total_swap_space)); >> 546: size_t free_swap_space = 0; >> 547: (void)os::free_swap_space(free_swap_space); > > Suggestion: > > size_t total_swap_space = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::total_swap_space(total_swap_space); > event.set_totalSize(static_cast(total_swap_space)); > size_t free_swap_space = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::free_swap_space(free_swap_space); Addressed. > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1362: > >> 1360: InstanceKlass* the_class = get_ik(_class_defs[i].klass); >> 1361: size_t avail_mem = 0; >> 1362: (void)os::available_memory(avail_mem); > > Suggestion: > > size_t avail_mem = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::available_memory(avail_mem); Addressed. > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1529: > >> 1527: } >> 1528: } >> 1529: (void)os::available_memory(avail_mem); > > Suggestion: > > avail_mem = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::available_memory(avail_mem); Addressed. > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4440: > >> 4438: // direct and indirect subclasses of the_class >> 4439: size_t avail_mem = 0; >> 4440: (void)os::available_memory(avail_mem); > > Suggestion: > > size_t avail_mem = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::available_memory(avail_mem); Addressed. > src/hotspot/share/prims/whitebox.cpp line 2516: > >> 2514: LINUX_ONLY(return static_cast(os::Linux::physical_memory());) >> 2515: size_t phys_mem = os::physical_memory(); >> 2516: return static_cast(phys_mem); > > Suggestion: > > return static_cast(LINUX_ONLY(os::Linux::physical_memory()) NOT_LINUX(os::physical_memory())); > > Though this seems like a bad code "smell" to me - there is something wrong with our notion of "physical memory" if we have to make this distinction. Addressed. > src/hotspot/share/services/heapDumper.cpp line 2616: > >> 2614: // Lets ensure we have at least 20MB per thread. >> 2615: size_t free_memory = 0; >> 2616: (void)os::free_memory(free_memory); > > Suggestion: > > size_t free_memory = 0; > // Return value ignored - defaulting to 0 on failure. > (void)os::free_memory(free_memory); Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253531025 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253530680 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253530386 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253529920 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253529670 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253529181 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253528912 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253528737 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253527398 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253527011 From duke at openjdk.org Tue Aug 5 08:29:15 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 5 Aug 2025 08:29:15 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: Message-ID: <7685_Xh8MjRqxoEx2BWfpTcdPXq5-aDuo0XZfTcco5w=.00416a73-5237-4381-a79d-8973f47b19ed@github.com> On Tue, 5 Aug 2025 04:39:49 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 26 commits: >> >> - 8357086: Addressed reviewer's comments >> - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs >> - 8357086: Fixed merge conflict >> - 8357086: Removed extra line >> - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD >> - 8357086: Small fixes >> - 8357086: Made physical_memory() return void >> - 8357086: Fixed behavior of total_swap_space on Linux >> - 8357086: Addressed reviewer's comments. >> - 8357086: Fixed void conversion. >> - ... and 16 more: https://git.openjdk.org/jdk/compare/57553ca1...a3898f43 > > src/hotspot/os/linux/os_linux.cpp line 297: > >> 295: if (OSContainer::is_containerized() && OSContainer::memory_and_swap_limit_in_bytes() > 0) { >> 296: if (OSContainer::memory_limit_in_bytes() > 0) { >> 297: value = static_cast(OSContainer::memory_and_swap_limit_in_bytes() - OSContainer::memory_limit_in_bytes()); > > Pre-existing but we should really only calls these functions once and store the result in a local. Addressed. > src/hotspot/os/linux/os_linux.cpp line 328: > >> 326: bool host_free_swap_ok = host_free_swap_f(host_free_swap); >> 327: if (!total_swap_space_ok || !host_free_swap_ok) { >> 328: assert(false, "sysinfo failed ? "); > > Pre-existing: the assert should be pushed down to where the `sysinfo` calls are so you could see which one failed - not that they can actually fail if called correctly. I think this would change the usage pattern again. Do we want a failing assert in every memory function in case of failure? I thought the consensus is that a false values returned by the function is indicating that. In this particular case it will be easy to trace which method failed as their results are stored as local variables. > src/hotspot/os/linux/os_linux.cpp line 330: > >> 328: assert(false, "sysinfo failed ? "); >> 329: return false; >> 330: } > > Suggestion: > > size_t total_swap_space = 0; > size_t host_free_swap = 0; > if (!os::total_swap_space(total_swap_space) || !host_free_swap_f(host_free_swap)) { > assert(false, "sysinfo failed ? "); > return false; > } I suggest to keep results as locals, see my previous comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253544122 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253543879 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2253543435 From dholmes at openjdk.org Tue Aug 5 08:35:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Aug 2025 08:35:11 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). VM side seems reasonable. Java side looks a bit clunky but that is up to core-libs folk to evaluate. General note: if comments start with a capital they should end with a period, and vice-versa. Extended comments should consist of full sentences. Thanks. src/hotspot/share/classfile/javaClasses.cpp line 3078: > 3076: do { > 3077: // No backtrace available. > 3078: if (!iter.repeat()) return false; Suggestion: if (!iter.repeat()) { return false; } src/hotspot/share/interpreter/bytecodeUtils.cpp line 346: > 344: > 345: if (found && is_parameter) { > 346: // Check MethodParameters for a name, if it carries a name Suggestion: // check MethodParameters for a name, if it carries a name src/hotspot/share/interpreter/bytecodeUtils.cpp line 354: > 352: char *var = cp->symbol_at(elem.name_cp_index)->as_C_string(); > 353: os->print("%s", var); > 354: No need for blank line src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483: > 1481: // Is an explicit slot given? > 1482: bool explicit_search = slot >= 0; > 1483: if (explicit_search) { Suggestion: if (slot >= 0) { No need for the temporary local. src/hotspot/share/interpreter/bytecodeUtils.hpp line 40: > 38: // Slot can be nonnegative to indicate an explicit search for the source of null > 39: // If slot is negative (default), also search for the action that caused the NPE before > 40: // deriving the actual slot and source of null by code parsing Suggestion: // Slot can be nonnegative to indicate an explicit search for the source of null. // If slot is negative (default), also search for the action that caused the NPE before // deriving the actual slot and source of null by code parsing. Periods at the end of sentences in comments. src/java.base/share/classes/java/lang/NullPointerException.java line 78: > 76: NullPointerException(int stackOffset, int searchSlot) { > 77: extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot); > 78: this(); I thought `this()` had to come first in a constructor? Is this new in 25 or 26? src/java.base/share/classes/java/lang/NullPointerException.java line 101: > 99: SEARCH_SLOT_MASK = SEARCH_SLOT_MAX << SEARCH_SLOT_SHIFT; > 100: > 101: // Access these fields in object monitor only Suggestion: // Access these fields only while holding this object's monitor lock. src/java.base/share/classes/java/lang/NullPointerException.java line 162: > 160: /// and the search slot will be derived by bytecode tracing. The message > 161: /// will also include the action that caused the NPE besides the source of > 162: /// the `null`. Suggestion: /// will also include the action that caused the NPE along with the source /// of the `null`. ------------- PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3087045581 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253509165 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253517408 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253519550 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253472224 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253481631 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253558481 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253541806 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253487877 From mhaessig at openjdk.org Tue Aug 5 08:55:06 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 5 Aug 2025 08:55:06 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: On Tue, 5 Aug 2025 03:56:41 GMT, Dean Long wrote: >> Manuel H?ssig 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-8308094-timeout >> - Fix SIGALRM test >> - Add timeout functionality to compiler threads > > src/hotspot/share/compiler/compilerThread.cpp line 97: > >> 95: switch (signo) { >> 96: case TIMEOUT_SIGNAL: { >> 97: assert(!Atomic::load_acquire(&_timeout_armed), "compile task timed out"); > > Why do we need acquire? Only the current thread is ever going to be looking at this value, right? The compiler thread setting and unsetting the flag and the signal handler reading the flag are racing each other as soon as the timer is set, since signals are preemptive. This prevents a few false positive timeouts on architectures with weak memory models, but does not have any effect on x86 for example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2253611427 From jsjolen at openjdk.org Tue Aug 5 09:59:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Aug 2025 09:59:03 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 08:32:33 GMT, David Holmes wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). > > src/java.base/share/classes/java/lang/NullPointerException.java line 78: > >> 76: NullPointerException(int stackOffset, int searchSlot) { >> 77: extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot); >> 78: this(); > > I thought `this()` had to come first in a constructor? Is this new in 25 or 26? https://openjdk.org/jeps/492 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253816429 From mdoerr at openjdk.org Tue Aug 5 10:16:06 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 5 Aug 2025 10:16:06 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. Maybe atomic bitwise operations could be used, but I'm happy with your current solution. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3087610323 From jsjolen at openjdk.org Tue Aug 5 10:23:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Aug 2025 10:23:07 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). Still reading this. A few comments, mostly intended to make this easier to grok for future readers. The actual logic seems fine from a first read. src/java.base/share/classes/java/lang/NullPointerException.java line 159: > 157: /// configurations to trace how a particular argument, which turns out to > 158: /// be `null`, was evaluated. > 159: /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor) Can `searchSlot == -1` here? ------------- PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3087588630 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253882841 From jsjolen at openjdk.org Tue Aug 5 10:23:08 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Aug 2025 10:23:08 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 07:55:41 GMT, David Holmes wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). > > src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483: > >> 1481: // Is an explicit slot given? >> 1482: bool explicit_search = slot >= 0; >> 1483: if (explicit_search) { > > Suggestion: > > if (slot >= 0) { > > No need for the temporary local. If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does. > src/hotspot/share/interpreter/bytecodeUtils.hpp line 40: > >> 38: // Slot can be nonnegative to indicate an explicit search for the source of null >> 39: // If slot is negative (default), also search for the action that caused the NPE before >> 40: // deriving the actual slot and source of null by code parsing > > Suggestion: > > // Slot can be nonnegative to indicate an explicit search for the source of null. > // If slot is negative (default), also search for the action that caused the NPE before > // deriving the actual slot and source of null by code parsing. > > Periods at the end of sentences in comments. I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden. ```c++ enum class NPESlot : int { // docs here None = -1, // docs here Explicit // Anything >= 0 }; bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) { if (slot != NPESlot::None) { // Explicit search } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253888922 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253865251 From mhaessig at openjdk.org Tue Aug 5 10:32:07 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 5 Aug 2025 10:32:07 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: On Tue, 5 Aug 2025 03:55:35 GMT, Dean Long wrote: >> Manuel H?ssig 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-8308094-timeout >> - Fix SIGALRM test >> - Add timeout functionality to compiler threads > > src/hotspot/share/compiler/compileBroker.cpp line 236: > >> 234: { >> 235: MutexLocker notifier(thread, CompileTaskWait_lock); >> 236: thread->timeout_disarm(); > > Is holding the lock above important for disasming? If not, can we move the disarms from the if/else branches and do it unconditionally before the if? It is not. I'll move it above the `if`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2253919668 From fgao at openjdk.org Tue Aug 5 10:36:17 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 5 Aug 2025 10:36:17 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() Message-ID: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> In the existing implementation, the static call stub typically emits a sequence like: `isb; movk; movz; movz; movk; movz; movz; br`. This patch reimplements it using a more compact and patch-friendly sequence: ldr x12, Label_data ldr x8, Label_entry br x8 Label_data: 0x00000000 0x00000000 Label_entry: 0x00000000 0x00000000 The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. Benchmark (length) Mode Cnt Master Patch Units StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op All tests in Tier1 to Tier3, under both release and debug builds, have passed. [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads ------------- Commit messages: - 8363620: AArch64: reimplement emit_static_call_stub() Changes: https://git.openjdk.org/jdk/pull/26638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363620 Stats: 322 lines in 8 files changed: 135 ins; 167 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26638/head:pull/26638 PR: https://git.openjdk.org/jdk/pull/26638 From ayang at openjdk.org Tue Aug 5 10:42:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 10:42:08 GMT Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:49:14 GMT, Albert Mingkun Yang wrote: >> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sgc-whitebox > - sgc-whitebox Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26528#issuecomment-3154564288 From ayang at openjdk.org Tue Aug 5 10:46:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 10:46:08 GMT Subject: Integrated: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC In-Reply-To: References: Message-ID: <0TwYYkT3Exg_w78Ku8Dv5ugVgDl22eGDsx1Y2zVoccA=.273195b8-cb8c-434a-87ac-d1d20623a8c0@github.com> On Tue, 29 Jul 2025 09:37:26 GMT, Albert Mingkun Yang wrote: > Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already. > > Test: tier1-3 This pull request has now been integrated. Changeset: ba0ae4cb Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ba0ae4cb28aa520d5244077349e35ef1bb475b61 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26528 From fgao at openjdk.org Tue Aug 5 11:48:08 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 5 Aug 2025 11:48:08 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Tue, 5 Aug 2025 10:30:13 GMT, Fei Gao wrote: > In the existing implementation, the static call stub typically emits a sequence like: > `isb; movk; movz; movz; movk; movz; movz; br`. > > This patch reimplements it using a more compact and patch-friendly sequence: > > ldr x12, Label_data > ldr x8, Label_entry > br x8 > Label_data: > 0x00000000 > 0x00000000 > Label_entry: > 0x00000000 > 0x00000000 > > The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. > > While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. > > A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. > > > Benchmark (length) Mode Cnt Master Patch Units > StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op > StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op > StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op > StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op > StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op > StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op > > > All tests in Tier1 to Tier3, under both release and debug builds, have passed. > > [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 989: > 987: ldr(rscratch1, far_jump_entry); > 988: br(rscratch1); > 989: bind(far_jump_metadata); I?m considering whether the data here should be 8-byte aligned, similar to what we did for the trampoline stubs https://github.com/openjdk/jdk/blob/743c821289a6562972364b5dcce8dd29a786264a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L950 I tried with a small case: @CompilerControl(CompilerControl.Mode.EXCLUDE) public static void callInterpreted0(int i) { val0 = i; } @CompilerControl(CompilerControl.Mode.EXCLUDE) public static void callInterpreted1(int i) { val1 = i; } @CompilerControl(CompilerControl.Mode.EXCLUDE) public static void callInterpreted2(int i) { val2 = i; } @Benchmark public void callCompiled() { for (int i = 0; i < length; i++) { callInterpreted0(i); // Make sure this is excluded from compilation callInterpreted1(i); callInterpreted2(i); } } where the static stubs are laid out as follows: 0x0000eee528201dd0: ldr x8, 0x0000eee528201dd8 ; {trampoline_stub} 0x0000eee528201dd4: br x8 0x0000eee528201dd8: .inst 0x2f69fe40 ; undefined 0x0000eee528201ddc: .inst 0x0000eee5 ; undefined 0x0000eee528201de0: ldr x8, 0x0000eee528201de8 ; {trampoline_stub} 0x0000eee528201de4: br x8 0x0000eee528201de8: .inst 0x2f69fe40 ; undefined 0x0000eee528201dec: .inst 0x0000eee5 ; undefined 0x0000eee528201df0: ldr x8, 0x0000eee528201df8 ; {trampoline_stub} 0x0000eee528201df4: br x8 0x0000eee528201df8: .inst 0x2f69fe40 ; undefined 0x0000eee528201dfc: .inst 0x0000eee5 ; undefined 0x0000eee528201e00: ldr x12, 0x0000eee528201e0c ; {static_stub} 0x0000eee528201e04: ldr x8, 0x0000eee528201e14 0x0000eee528201e08: br x8 0x0000eee528201e0c: .inst 0x00000000 ; undefined 0x0000eee528201e10: .inst 0x00000000 ; undefined 0x0000eee528201e14: .inst 0x00000000 ; undefined 0x0000eee528201e18: .inst 0x00000000 ; undefined 0x0000eee528201e1c: ldr x12, 0x0000eee528201e28 ; {static_stub} 0x0000eee528201e20: ldr x8, 0x0000eee528201e30 0x0000eee528201e24: br x8 0x0000eee528201e28: .inst 0x00000000 ; undefined 0x0000eee528201e2c: .inst 0x00000000 ; undefined 0x0000eee528201e30: .inst 0x00000000 ; undefined 0x0000eee528201e34: .inst 0x00000000 ; undefined 0x0000eee528201e38: ldr x12, 0x0000eee528201e44 ; {static_stub} 0x0000eee528201e3c: ldr x8, 0x0000eee528201e4c 0x0000eee528201e40: br x8 0x0000eee528201e44: .inst 0x00000000 ; undefined 0x0000eee528201e48: .inst 0x00000000 ; undefined 0x0000eee528201e4c: .inst 0x00000000 ; undefined 0x0000eee528201e50: .inst 0x00000000 ; undefined Here are the performance results: Benchmark (length) Mode Cnt Master Aligned Unaligned Units StaticCallStub.StaticCallStubFar.callCompiled 1000 avgt 5 114.794 63.117 64.346 us/op StaticCallStub.StaticCallStubFar.callCompiled 10000 avgt 5 1136.016 618.576 619.629 us/op StaticCallStub.StaticCallStubFar.callCompiled 100000 avgt 5 11323.945 6191.452 6277.813 us/op StaticCallStub.StaticCallStubNear.callCompiled 1000 avgt 5 114.335 63.142 64.091 us/op StaticCallStub.StaticCallStubNear.callCompiled 10000 avgt 5 1140.667 618.653 619.861 us/op StaticCallStub.StaticCallStubNear.callCompiled 100000 avgt 5 11351.394 6194.946 6195.255 us/op We have several aspects to consider: - 8-byte alignment brings a minor performance gain, but it?s not significant compared to the overall improvement achieved by reimplementing the static stubs. - Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. - The alignment requirement for trampoline stubs doesn?t always introduce extra NOPs?padding is only added when trampoline and static stubs are interleaved. In contrast, enforcing 8-byte alignment for static stubs almost always introduces padding, since the first three instructions are not naturally aligned. - We should carefully balance the trade-off between code size increase and code hotness (i.e., how frequently the stub code is executed). Any feedback or suggestions would be greatly appreciated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2254100081 From adinn at openjdk.org Tue Aug 5 13:28:18 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 5 Aug 2025 13:28:18 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines Message-ID: This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. ------------- Commit messages: - Handle failed compiler blob allocate gracefully Changes: https://git.openjdk.org/jdk/pull/26642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26642&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364558 Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26642/head:pull/26642 PR: https://git.openjdk.org/jdk/pull/26642 From asmehra at openjdk.org Tue Aug 5 13:34:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 5 Aug 2025 13:34:03 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 29 Jul 2025 07:19:31 GMT, Johan Sj?len wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> More compile failure fix >> >> Signed-off-by: Ashutosh Mehra > > It seems like we can just use a `stringStream` instead and not have to deal with any overflow of some buffer, since we strdup at the end. @jdksjolen ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/26515#issuecomment-3155229520 From duke at openjdk.org Tue Aug 5 13:46:06 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 5 Aug 2025 13:46:06 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:21:01 GMT, Andrew Dinn wrote: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. src/hotspot/share/opto/c2compiler.cpp line 95: > 93: // If there was an error generating the blob then UseCompiler will > 94: // have been unset and we need to skip the remaining initialization > 95: if (UseCompiler) { Inverting the if condition here would result in a slightly more readable code: you could early return `false`, avoid the additional indentation, and the comment at L93-94 would refer to the true branch of the `if` statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26642#discussion_r2254396057 From jsjolen at openjdk.org Tue Aug 5 14:11:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Aug 2025 14:11:10 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Wed, 30 Jul 2025 15:17:57 GMT, Ashutosh Mehra wrote: >> This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. >> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. >> Platforms affected: x86-64 and aarch64 >> Other platforms can be done if and when Leyden changes are ported to them. >> >> [0] https://github.com/openjdk/leyden/pull/84 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > More compile failure fix > > Signed-off-by: Ashutosh Mehra This looks good to me! Added a few comments on the `join` method. src/hotspot/share/utilities/ostream.hpp line 170: > 168: > 169: // Append strings returned by gen, separating each with separator. > 170: // Stops when gen returns null or when buffer is out of space. We never really stop when the buffer runs out of space. src/hotspot/share/utilities/ostream.hpp line 172: > 170: // Stops when gen returns null or when buffer is out of space. > 171: template > 172: void join(Generator gen, const char* separator) { We can move this to the `outputStream` class instead! src/hotspot/share/utilities/ostream.hpp line 181: > 179: str = gen(); > 180: } > 181: return; Let's delete this return ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26515#pullrequestreview-3088470522 PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254477968 PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254478897 PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254473839 From adinn at openjdk.org Tue Aug 5 14:13:10 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 5 Aug 2025 14:13:10 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:21:01 GMT, Andrew Dinn wrote: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. @vnkozlov This is still intermittent as it depends on a race. However, I ran this repeatedly with the initial and reserved cache sizes that caused the problem and with stubs logging enabled and observed execution to continue in cases where the race would previously have caused a crash. Here is the outpout from such a run. Look for the new stubs log warning message in the following output: [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version [0.001s][info][stubs] StubRoutines (preuniverse stubs) not generated [0.003s][info][stubs] StubRoutines (initial stubs) [0x0000ffff5bfb4080, 0x0000ffff5bfb6a10] used: 5388, free: 5252 [0.003s][info][stubs] StubRoutines (continuation stubs) [0x0000ffff5bfb7000, 0x0000ffff5bfb7a50] used: 600, free: 2040 [0.004s][info][stubs] StubRoutines (final stubs) [0x0000ffff5bff58c0, 0x0000ffff5c00f568] used: 11568, free: 94072 [0.007s][warning][codecache] CodeCache is full. Compiler has been disabled. [0.007s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= OpenJDK 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers CodeCache: size=1008Kb used=444Kb max_used=1008Kb free=563Kb bounds [0x0000ffff5bfb4000, 0x0000ffff5c0b0000, 0x0000ffff5c0b0000] total_blobs=215, nmethods=0, adapters=177, full_count=2 Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0 [0.007s][warning][stubs ] Ignoring failed allocation of blob Stub Generator compiler_blob under compiler thread OpenJDK 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers openjdk version "26-internal" 2026-03-17 OpenJDK Runtime Environment (build 26-internal-adhoc.adinn.JDK-8364558) OpenJDK 64-Bit Server VM (build 26-internal-adhoc.adinn.JDK-8364558, mixed mode, sharing) That ought to have fixed the problem with test StartOutput. However, after running more times I spotted this (very much less frequent) error exit: [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version [0.001s][info][stubs] StubRoutines (preuniverse stubs) not generated [0.003s][info][stubs] StubRoutines (initial stubs) [0x0000ffff6a514080, 0x0000ffff6a516a10] used: 5388, free: 5252 [0.003s][info][stubs] StubRoutines (continuation stubs) [0x0000ffff6a517000, 0x0000ffff6a517a50] used: 600, free: 2040 [0.004s][info][stubs] StubRoutines (final stubs) [0x0000ffff6a5558c0, 0x0000ffff6a56f568] used: 11568, free: 94072 [0.006s][warning][codecache] CodeCache is full. Compiler has been disabled. [0.006s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=1008Kb used=1008Kb max_used=1008Kb free=0Kb bounds [0x0000ffff6a514000, 0x0000ffff6a610000, 0x0000ffff6a610000] total_blobs=216, nmethods=0, adapters=177, full_count=3 Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0 OpenJDK 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers [0.006s][warning][stubs ] Ignoring failed allocation of blob Stub Generator compiler_blob under compiler thread OpenJDK 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers Error occurred during initialization of boot layer java.lang.OutOfMemoryError: Out of space in CodeCache for adapters So, in this case the warning shows that CodeCache Out of space problem has been finessed under `C2Compiler::initialize` but we still suffer a VM crash because of a failure to allocate an adapter. I am not sure how we can handle this cleanly. This will be happening when `Method::make_adapters` receives nullptr as the return value from `AdapterHandlerLibrary::get_adapter()`. `make_adapters` is currently coded to call `vm_exit_during_initialization` if `is_init_completed()` returns `false` and throw an `OutOfMemoryError` if `is_init_completed()` returns `true`. I think the problem here will be that in the rare occurrence where a C1 compilation is in flight at the point where the C2 failure disables compilation `is_init_completed()` will return `true` and we will be in the middle of linking the method whose adapter is being created. So, even if we wanted to carry on here with compilation disabled it is hard to know how to back out of this gracefully. Any ideas how to proceed? Shall I still continue wiht the current patch? Also, do we need a better title for the JIRA and PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3155395403 From rriggs at openjdk.org Tue Aug 5 14:22:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Aug 2025 14:22:05 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs In-Reply-To: References: Message-ID: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514: > 1512: return true; > 1513: } > 1514: Extra new line src/java.base/share/classes/java/lang/NullPointerException.java line 75: > 73: > 74: /// Creates an NPE with a custom backtrace configuration. > 75: /// The exception has no message if detailed NPE is not enabled. Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value. Use regular // comments. src/java.base/share/classes/java/lang/NullPointerException.java line 142: > 140: } > 141: > 142: // Methods below must be called in object monitor This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers. src/java.base/share/classes/java/lang/NullPointerException.java line 146: > 144: private void ensureMessageComputed() { > 145: if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) { > 146: int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT; This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637: > 635: /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API. > 636: /// Search slot is the slot where the null-checked value is passed in. > 637: NullPointerException extendedNullPointerException(int stackOffset, int searchSlot); Method should **not** be added to SharedSecrets solely for access by tests. Tests can use @modules to gain access. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2251763870 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254483182 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254486286 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254494309 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254508852 From liach at openjdk.org Tue Aug 5 14:34:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 14:34:50 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v2] In-Reply-To: References: Message-ID: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Web review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26600/files - new: https://git.openjdk.org/jdk/pull/26600/files/5735b802..09233e9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=00-01 Stats: 15 lines in 4 files changed: 2 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600 PR: https://git.openjdk.org/jdk/pull/26600 From liach at openjdk.org Tue Aug 5 14:34:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 14:34:50 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v2] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 08:16:21 GMT, David Holmes wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Web review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/interpreter/bytecodeUtils.cpp line 354: > >> 352: char *var = cp->symbol_at(elem.name_cp_index)->as_C_string(); >> 353: os->print("%s", var); >> 354: > > No need for blank line Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254528382 From liach at openjdk.org Tue Aug 5 14:34:51 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 14:34:51 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v2] In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> References: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> Message-ID: On Mon, 4 Aug 2025 14:58:07 GMT, Roger Riggs wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Web review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514: > >> 1512: return true; >> 1513: } >> 1514: > > Extra new line Suggestion: > src/java.base/share/classes/java/lang/NullPointerException.java line 75: > >> 73: >> 74: /// Creates an NPE with a custom backtrace configuration. >> 75: /// The exception has no message if detailed NPE is not enabled. > > Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value. > Use regular // comments. Suggestion: // Creates an NPE with a custom backtrace configuration. // The exception has no message if detailed NPE is not enabled. > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637: > >> 635: /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API. >> 636: /// Search slot is the slot where the null-checked value is passed in. >> 637: NullPointerException extendedNullPointerException(int stackOffset, int searchSlot); > > Method should **not** be added to SharedSecrets solely for access by tests. > Tests can use @modules to gain access. This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254529734 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254532646 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254537044 From liach at openjdk.org Tue Aug 5 14:34:51 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 14:34:51 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v2] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:07:38 GMT, Johan Sj?len wrote: >> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40: >> >>> 38: // Slot can be nonnegative to indicate an explicit search for the source of null >>> 39: // If slot is negative (default), also search for the action that caused the NPE before >>> 40: // deriving the actual slot and source of null by code parsing >> >> Suggestion: >> >> // Slot can be nonnegative to indicate an explicit search for the source of null. >> // If slot is negative (default), also search for the action that caused the NPE before >> // deriving the actual slot and source of null by code parsing. >> >> Periods at the end of sentences in comments. > > I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden. > > ```c++ > enum class NPESlot : int { > // docs here > None = -1, > // docs here > Explicit // Anything >= 0 > }; > bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) { > if (slot != NPESlot::None) { > // Explicit search > } > } I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254525459 From rriggs at openjdk.org Tue Aug 5 14:56:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Aug 2025 14:56:03 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v2] In-Reply-To: References: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> Message-ID: On Tue, 5 Aug 2025 14:28:37 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637: >> >>> 635: /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API. >>> 636: /// Search slot is the slot where the null-checked value is passed in. >>> 637: NullPointerException extendedNullPointerException(int stackOffset, int searchSlot); >> >> Method should **not** be added to SharedSecrets solely for access by tests. >> Tests can use @modules to gain access. > > This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts. Don't add APIs without uses; it speculative and the API may not be what is really needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254604180 From liach at openjdk.org Tue Aug 5 15:07:13 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 15:07:13 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v3] In-Reply-To: References: Message-ID: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). 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: - Use c++ enum classes per jdksjolen - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks - Web review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Years - Roll back Objects.rNN for now - Review remarks - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Bork - Try generify the NPE tracing API - ... and 4 more: https://git.openjdk.org/jdk/compare/dc4f5978...9af7ee85 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26600/files - new: https://git.openjdk.org/jdk/pull/26600/files/09233e9a..9af7ee85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=01-02 Stats: 5643 lines in 151 files changed: 3341 ins; 1944 del; 358 mod Patch: https://git.openjdk.org/jdk/pull/26600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600 PR: https://git.openjdk.org/jdk/pull/26600 From liach at openjdk.org Tue Aug 5 15:07:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 15:07:14 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v3] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 14:24:37 GMT, Chen Liang wrote: >> I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden. >> >> ```c++ >> enum class NPESlot : int { >> // docs here >> None = -1, >> // docs here >> Explicit // Anything >= 0 >> }; >> bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) { >> if (slot != NPESlot::None) { >> // Explicit search >> } >> } > > I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly. I think I figured out how to use static_cast with C++ enum classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254630773 From liach at openjdk.org Tue Aug 5 15:07:15 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 15:07:15 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v3] In-Reply-To: References: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> Message-ID: On Tue, 5 Aug 2025 14:53:03 GMT, Roger Riggs wrote: >> This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts. > > Don't add APIs without uses; it speculative and the API may not be what is really needed. Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254627867 From rriggs at openjdk.org Tue Aug 5 15:17:12 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Aug 2025 15:17:12 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: On Mon, 4 Aug 2025 15:00:52 GMT, Doug Simon wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore c2 optimization. > > src/hotspot/share/prims/jvm.cpp line 1744: > >> 1742: JVM_END >> 1743: >> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls)) > > What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610 Created issue https://bugs.openjdk.org/browse/JDK-8364750 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2254660805 From cstein at openjdk.org Tue Aug 5 16:03:07 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 5 Aug 2025 16:03:07 GMT Subject: RFR: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: <1XRUup7RXkUWm_2yscYV2M-m4ooHr70QdwcVVB7zxDI=.d641c6f9-9dd9-4da7-8599-a164274b9d93@github.com> On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Both tests seem to make hard assumptions on where binary files of `@library` classes are stored. - [TestSPISigned.java#L60-L62](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java#L60-L62) - [resexhausted003.java#L83-L96](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003.java#L83-L96) The storage location changed due to https://bugs.openjdk.org/browse/CODETOOLS-7902847 - it might change again in the near future. Thus, both tests need to be updated to work correctly without relying on a specific location of compiled library classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3155714592 From liach at openjdk.org Tue Aug 5 16:04:08 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Aug 2025 16:04:08 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update NPE per roger review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26600/files - new: https://git.openjdk.org/jdk/pull/26600/files/9af7ee85..4ba1f17c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=02-03 Stats: 33 lines in 1 file changed: 12 ins; 4 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600 PR: https://git.openjdk.org/jdk/pull/26600 From asmehra at openjdk.org Tue Aug 5 16:48:06 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 5 Aug 2025 16:48:06 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 14:08:32 GMT, Johan Sj?len wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> More compile failure fix >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/utilities/ostream.hpp line 172: > >> 170: // Stops when gen returns null or when buffer is out of space. >> 171: template >> 172: void join(Generator gen, const char* separator) { > > We can move this to the `outputStream` class instead! It is in the `outputStream` class ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254829472 From asmehra at openjdk.org Tue Aug 5 18:08:22 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 5 Aug 2025 18:08:22 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: > This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. > This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. > Platforms affected: x86-64 and aarch64 > Other platforms can be done if and when Leyden changes are ported to them. > > [0] https://github.com/openjdk/leyden/pull/84 Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Address review comments Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26515/files - new: https://git.openjdk.org/jdk/pull/26515/files/21383a7d..cca14916 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26515.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26515/head:pull/26515 PR: https://git.openjdk.org/jdk/pull/26515 From asmehra at openjdk.org Tue Aug 5 18:08:23 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 5 Aug 2025 18:08:23 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: <6nXR6F1y_HxreFrbgXEacnewfw3ZGrd4B7yl3I36Lis=.95f01947-9df5-4beb-b9e2-31765327bdb9@github.com> On Tue, 5 Aug 2025 14:08:54 GMT, Johan Sj?len wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> More compile failure fix >> >> Signed-off-by: Ashutosh Mehra > > This looks good to me! Added a few comments on the `join` method. @jdksjolen new commit pushed to address your comments. > src/hotspot/share/utilities/ostream.hpp line 170: > >> 168: >> 169: // Append strings returned by gen, separating each with separator. >> 170: // Stops when gen returns null or when buffer is out of space. > > We never really stop when the buffer runs out of space. Updated the comment. > src/hotspot/share/utilities/ostream.hpp line 181: > >> 179: str = gen(); >> 180: } >> 181: return; > > Let's delete this return Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/26515#issuecomment-3156103224 PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254997542 PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2254997589 From ayang at openjdk.org Tue Aug 5 18:26:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Aug 2025 18:26:18 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy Message-ID: Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. Test: tier1-3 ------------- Commit messages: - g1-soft-refs Changes: https://git.openjdk.org/jdk/pull/26648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364767 Stats: 42 lines in 6 files changed: 4 ins; 35 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26648/head:pull/26648 PR: https://git.openjdk.org/jdk/pull/26648 From coleenp at openjdk.org Tue Aug 5 19:30:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 5 Aug 2025 19:30:12 GMT Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5] In-Reply-To: References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com> Message-ID: On Tue, 5 Aug 2025 15:14:06 GMT, Roger Riggs wrote: >> src/hotspot/share/prims/jvm.cpp line 1744: >> >>> 1742: JVM_END >>> 1743: >>> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls)) >> >> What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610 > > Created issue https://bugs.openjdk.org/browse/JDK-8364750 Sorry I missed the declaration. Will fix it. Thanks for filing the bug Roger. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2255153426 From dlong at openjdk.org Tue Aug 5 21:36:05 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 5 Aug 2025 21:36:05 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: <1YTjfZh0C7UWqTCXWcNS-Q68kBOnhlRJA_-sS_vZsio=.6389ba30-8f3a-48c2-b0e2-40f5877f4a36@github.com> On Tue, 5 Aug 2025 08:52:20 GMT, Manuel H?ssig wrote: >> src/hotspot/share/compiler/compilerThread.cpp line 97: >> >>> 95: switch (signo) { >>> 96: case TIMEOUT_SIGNAL: { >>> 97: assert(!Atomic::load_acquire(&_timeout_armed), "compile task timed out"); >> >> Why do we need acquire? Only the current thread is ever going to be looking at this value, right? > > The compiler thread setting and unsetting the flag and the signal handler reading the flag are racing each other as soon as the timer is set, since signals are preemptive. This prevents a few false positive timeouts on architectures with weak memory models, but does not have any effect on x86 for example. The signal is delivered to the same compiler thread, so I don't think acquire and release help here. There shouldn't be a weak memory model issue between a thread and it's signal handler on the same thread. Can you explain the sequence of events that could cause a false positive? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2255395595 From dlong at openjdk.org Tue Aug 5 21:43:04 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 5 Aug 2025 21:43:04 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: <62G2O_C4dHe0yNocFL7vmma7XWoyr9rTGO2p7Y6i_Z0=.15588516-31e5-4d8c-9003-92cd45fe1dd4@github.com> On Tue, 5 Aug 2025 10:30:13 GMT, Fei Gao wrote: > In the existing implementation, the static call stub typically emits a sequence like: > `isb; movk; movz; movz; movk; movz; movz; br`. > > This patch reimplements it using a more compact and patch-friendly sequence: > > ldr x12, Label_data > ldr x8, Label_entry > br x8 > Label_data: > 0x00000000 > 0x00000000 > Label_entry: > 0x00000000 > 0x00000000 > > The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. > > While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. > > A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. > > > Benchmark (length) Mode Cnt Master Patch Units > StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op > StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op > StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op > StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op > StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op > StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op > > > All tests in Tier1 to Tier3, under both release and debug builds, have passed. > > [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads In the past we would have scheduled the load for x8 earlier to avoid a latency hit for using the value in the next instruction: ldr x8, Label_entry ldr x12, Label_data br x8 Is this still helpful on modern aarch64 hardware? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3156732901 From dlong at openjdk.org Tue Aug 5 21:50:04 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 5 Aug 2025 21:50:04 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Tue, 5 Aug 2025 11:45:18 GMT, Fei Gao wrote: > Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. I thought other threads are modifying the data, which is the reason why we needed the ISB. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2255414513 From tschatzl at openjdk.org Tue Aug 5 21:59:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Aug 2025 21:59:00 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v46] In-Reply-To: References: Message-ID: <8Ja1d6zTuDEThq0VR2UQfpY94bqnQql-mqIc-fa8ico=.0909c352-1208-481e-954b-8356f45e07ad@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into pull/23739 - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 53 more: https://git.openjdk.org/jdk/compare/d906e450...188fc811 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=45 Stats: 7114 lines in 112 files changed: 2583 ins; 3587 del; 944 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From amenkov at openjdk.org Tue Aug 5 22:34:46 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Aug 2025 22:34:46 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v7] In-Reply-To: References: Message-ID: <6MCWqdixHmPtZNQd86-_KSz80enDwWQW9AJEJsgnClI=.e27a474a-dc2d-4e7e-8436-789e65af3031@github.com> > The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. > > Testing: tier1..5 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: comment to async_get_stack_trace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26119/files - new: https://git.openjdk.org/jdk/pull/26119/files/30275945..811db312 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=05-06 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119 PR: https://git.openjdk.org/jdk/pull/26119 From amenkov at openjdk.org Tue Aug 5 22:34:47 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Aug 2025 22:34:47 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v6] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 05:22:33 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> fix broken build > > src/hotspot/share/classfile/javaClasses.cpp line 1885: > >> 1883: } >> 1884: >> 1885: oop java_lang_Thread::async_get_stack_trace(jobject jthread, TRAPS) { > > Please add a comment describing how the method works for virtual threads, and what returning null implies. Done. > src/hotspot/share/classfile/javaClasses.cpp line 1939: > >> 1937: // Target thread has been unmounted. >> 1938: return; >> 1939: } > > Shouldn't we set `carrier = true` if we don't return here? Or am I misunderstanding what "carrier" means here? "carrier" means target is a platform thread with mounted virtual thread. When `carrier == true` `vframeStream` skips frames of the mounted virtual thread. Here target is a virtual thread, so we need frames starting from the last frame ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2255469604 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2255466533 From kvn at openjdk.org Tue Aug 5 23:18:03 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Aug 2025 23:18:03 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 14:08:51 GMT, Andrew Dinn wrote: >> This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. > > @vnkozlov This is still intermittent as it depends on a race. However, I ran this repeatedly with the initial and reserved cache sizes that caused the problem and with stubs logging enabled and observed execution to continue in cases where the race would previously have caused a crash. Here is the outpout from such a run. Look for the new stubs log warning message in the following output: > > [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version > [0.001s][info][stubs] StubRoutines (preuniverse stubs) not generated > [0.003s][info][stubs] StubRoutines (initial stubs) [0x0000ffff5bfb4080, 0x0000ffff5bfb6a10] used: 5388, free: 5252 > [0.003s][info][stubs] StubRoutines (continuation stubs) [0x0000ffff5bfb7000, 0x0000ffff5bfb7a50] used: 600, free: 2040 > [0.004s][info][stubs] StubRoutines (final stubs) [0x0000ffff5bff58c0, 0x0000ffff5c00f568] used: 11568, free: 94072 > [0.007s][warning][codecache] CodeCache is full. Compiler has been disabled. > [0.007s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= > OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. > OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= > OpenJDK 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers > CodeCache: size=1008Kb used=444Kb max_used=1008Kb free=563Kb > bounds [0x0000ffff5bfb4000, 0x0000ffff5c0b0000, 0x0000ffff5c0b0000] > total_blobs=215, nmethods=0, adapters=177, full_count=2 > Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0 > [0.007s][warning][stubs ] Ignoring failed allocation of blob Stub Generator compiler_blob under compiler thread > OpenJDK 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers > openjdk version "26-internal" 2026-03-17 > OpenJDK Runtime Environment (build 26-internal-adhoc.adinn.JDK-8364558) > OpenJDK 64-Bit Server VM (build 26-internal-adhoc.adinn.JDK-8364558, mixed mode, sharing) > > > That ought to have fixed the problem with test StartOutput. However, after running more times I spotted this (very much less frequent) error exit: > > > [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version > [0.001s][info][stubs] StubRoutines (preuniverse stubs) not g... Thank you, @adinn, for working on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3156897321 From kvn at openjdk.org Tue Aug 5 23:22:02 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Aug 2025 23:22:02 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:21:01 GMT, Andrew Dinn wrote: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. src/hotspot/share/runtime/stubRoutines.cpp line 192: > 190: assert(blob_id == BlobId::stubgen_compiler_id, "sanity"); > 191: assert(DelayCompilerStubsGeneration, "sanity"); > 192: log_warning(stubs)("Ignoring failed allocation of blob %s under compiler thread", StubInfo::name(blob_id)); I think it should match other stubs output, for example: [0.001s][info][stubs] StubRoutines (preuniverse stubs) not generated May be: [0.001s][warning][stubs] StubRoutines (compiler stubs) not generated: no space left in CodeCache ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26642#discussion_r2255523961 From kvn at openjdk.org Tue Aug 5 23:25:03 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Aug 2025 23:25:03 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: <1xrYsWuO2i0clJuaenUnLY9U24K4IvY22ATv3WiHQuk=.0687a2e4-7723-432a-bd3b-b98451b3c376@github.com> On Tue, 5 Aug 2025 13:43:12 GMT, Francesco Andreuzzi wrote: >> This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. > > src/hotspot/share/opto/c2compiler.cpp line 95: > >> 93: // If there was an error generating the blob then UseCompiler will >> 94: // have been unset and we need to skip the remaining initialization >> 95: if (UseCompiler) { > > Inverting the if condition here would result in slightly more readable code: you could early return `false`, avoid the additional indentation, and the comment at L93-94 would refer to the true branch of the `if` statement. Should we also check it before calling `compiler_stubs_init()` too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26642#discussion_r2255527228 From kvn at openjdk.org Tue Aug 5 23:43:01 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Aug 2025 23:43:01 GMT Subject: RFR: 8364558: Test compiler/startup/StartupOutput.java failed with native OOM: CodeCache: no room for StubRoutines In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 14:08:51 GMT, Andrew Dinn wrote: > Any ideas how to proceed? Shall I still continue wiht the current patch? Don't worry about adapters. It is different issue which can happen at any time with very small CodeCache. > Also, do we need a better title for the JIRA and PR? Yes, please update it. May be: "Failure to generated compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache" ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3156933123 From dlong at openjdk.org Wed Aug 6 00:17:26 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Aug 2025 00:17:26 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:13:03 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> one unconditional release should be enough > > Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. > Maybe atomic bitwise operations could be used, but I'm happy with your current solution. Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3157006874 From dlong at openjdk.org Wed Aug 6 01:29:58 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Aug 2025 01:29:58 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v10] In-Reply-To: References: Message-ID: > The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. Dean Long 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 13 additional commits since the last revision: - Merge branch 'openjdk:master' into 8278874-verifystack - Merge branch 'openjdk:master' into 8278874-verifystack - more cleanup - simplify is_top_frame - readability suggestion - reviewer suggestions - Update src/hotspot/share/runtime/vframeArray.cpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/runtime/vframeArray.cpp Co-authored-by: Manuel H?ssig - better name for frame index - Update src/hotspot/share/runtime/deoptimization.cpp Co-authored-by: Manuel H?ssig - ... and 3 more: https://git.openjdk.org/jdk/compare/2689ae8e...e04fc720 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26121/files - new: https://git.openjdk.org/jdk/pull/26121/files/6bfda158..e04fc720 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=08-09 Stats: 7351 lines in 213 files changed: 4752 ins; 2089 del; 510 mod Patch: https://git.openjdk.org/jdk/pull/26121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121 PR: https://git.openjdk.org/jdk/pull/26121 From kbarrett at openjdk.org Wed Aug 6 02:57:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Aug 2025 02:57:16 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:13:03 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> one unconditional release should be enough > > Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. > Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. Not a review, just a drive-by comment. We've had Atomic bitops for a while now. Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) They haven't been optimized for most (any?) platforms, being based on cmpxchg. (See all the "Specialize atomic bitset functions for ..." related to https://bugs.openjdk.org/browse/JDK-8293117.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3157237736 From dholmes at openjdk.org Wed Aug 6 03:57:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 03:57:10 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v25] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 08:27:08 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewer's comments src/hotspot/os/linux/os_linux.cpp line 299: > 297: jlong memory_and_swap_limit_in_bytes = OSContainer::memory_and_swap_limit_in_bytes(); > 298: jlong memory_limit_in_bytes = OSContainer::memory_limit_in_bytes(); > 299: value = static_cast(memory_and_swap_limit_in_bytes - memory_limit_in_bytes); This isn't what I meant. You want to save into the locals before each of the `if` statements, else you are still calling these functions twice. src/hotspot/os/windows/os_windows.cpp line 869: > 867: return true; > 868: } else { > 869: errno = ::GetLastError(); Why are you setting `errno` here and elsewhere? I see a couple of places where we do do that though I do not know why, but generally we just want to save the `::GetlastError()` value (here we do need a local) and print it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2255787665 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2255792577 From dholmes at openjdk.org Wed Aug 6 03:57:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 03:57:12 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: <7685_Xh8MjRqxoEx2BWfpTcdPXq5-aDuo0XZfTcco5w=.00416a73-5237-4381-a79d-8973f47b19ed@github.com> References: <7685_Xh8MjRqxoEx2BWfpTcdPXq5-aDuo0XZfTcco5w=.00416a73-5237-4381-a79d-8973f47b19ed@github.com> Message-ID: On Tue, 5 Aug 2025 08:26:30 GMT, Anton Artemov wrote: >> src/hotspot/os/linux/os_linux.cpp line 328: >> >>> 326: bool host_free_swap_ok = host_free_swap_f(host_free_swap); >>> 327: if (!total_swap_space_ok || !host_free_swap_ok) { >>> 328: assert(false, "sysinfo failed ? "); >> >> Pre-existing: the assert should be pushed down to where the `sysinfo` calls are so you could see which one failed - not that they can actually fail if called correctly. > > I think this would change the usage pattern again. Do we want a failing assert in every memory function in case of failure? I thought the consensus is that a false values returned by the function is indicating that. In this particular case it will be easy to trace which method failed as their results are stored as local variables. The assert should go after the syscall that we don't expect to fail, but which we have to tolerate the possibility of failing. That is the place where we can also report why the call failed. I'm not sure what you mean about changing the usage pattern. >> src/hotspot/os/linux/os_linux.cpp line 330: >> >>> 328: assert(false, "sysinfo failed ? "); >>> 329: return false; >>> 330: } >> >> Suggestion: >> >> size_t total_swap_space = 0; >> size_t host_free_swap = 0; >> if (!os::total_swap_space(total_swap_space) || !host_free_swap_f(host_free_swap)) { >> assert(false, "sysinfo failed ? "); >> return false; >> } > > I suggest to keep results as locals, see my previous comment. Sorry I don't see a connection to previous comment about the assert. You only need a local if you need to refer to something more than once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2255794954 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2255796528 From swen at openjdk.org Wed Aug 6 05:27:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 6 Aug 2025 05:27:14 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici 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 31 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Replace `requireNonNull` with implicit null checks to reduce bytecode size > - Add `@bug` tags > - Improve wording of `@param len` > - Make source array bound checks lenient too > - Cap destination array bounds > - Fix bit shifting > - Remove superseded `@throws` Javadoc > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Make `StringCoding` encoding intrinsics lenient > - ... and 21 more: https://git.openjdk.org/jdk/compare/5917e59b...c322f0e0 src/java.base/share/classes/java/lang/StringCoding.java line 99: > 97: * {@linkplain Preconditions#checkFromIndexSize(int, int, int, BiFunction) out of bounds} > 98: */ > 99: static int countPositives(byte[] ba, int off, int len) { If we name countPositives with parameter checking as countPositivesSB, this PR will have fewer changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2255894472 From dholmes at openjdk.org Wed Aug 6 05:41:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 05:41:10 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v7] In-Reply-To: <6MCWqdixHmPtZNQd86-_KSz80enDwWQW9AJEJsgnClI=.e27a474a-dc2d-4e7e-8436-789e65af3031@github.com> References: <6MCWqdixHmPtZNQd86-_KSz80enDwWQW9AJEJsgnClI=.e27a474a-dc2d-4e7e-8436-789e65af3031@github.com> Message-ID: On Tue, 5 Aug 2025 22:34:46 GMT, Alex Menkov wrote: >> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. >> >> Testing: tier1..5 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > comment to async_get_stack_trace Looks good (a couple of typos). Thanks. src/hotspot/share/classfile/javaClasses.cpp line 1887: > 1885: // Obtain stack trace for platform or mounted virtual thread. > 1886: // If jthread is a virtual thread and it has been unmounted (or remounted to different carrier) the method returns null. > 1887: // The caller (java.lang.VirtulThread) handles retuned nulls via retry. Suggestion: // The caller (java.lang.VirtualThread) handles returned nulls via retry. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-3090401802 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2255852479 From stuefe at openjdk.org Wed Aug 6 05:45:06 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Aug 2025 05:45:06 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v2] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 05:43:01 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - Update metaspace.hpp > - fix rebase error > - fix mac build > - rebase, fixes Friendly Ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3157478659 From jsjolen at openjdk.org Wed Aug 6 06:18:13 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Aug 2025 06:18:13 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v4] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 16:45:26 GMT, Ashutosh Mehra wrote: >> src/hotspot/share/utilities/ostream.hpp line 172: >> >>> 170: // Stops when gen returns null or when buffer is out of space. >>> 171: template >>> 172: void join(Generator gen, const char* separator) { >> >> We can move this to the `outputStream` class instead! > > It is in the `outputStream` class Oops, I thought you moved it to the stringStream class, my bad :). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2255968128 From jiefu at openjdk.org Wed Aug 6 06:59:02 2025 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 6 Aug 2025 06:59:02 GMT Subject: RFR: 8364597: Replace THL A29 Limited with Tencent In-Reply-To: References: Message-ID: <08Gigv9qz5H5c80w-WLegQ_8KVI4xoY-kZ374S8t5ls=.35ded307-c917-4c1b-9ab0-032499140a67@github.com> On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang wrote: > `THL A29 Limited` was a `Tencent` company but was dissolved. > So, the copyright notes just use `Tencent` directly. LGTM ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26614#pullrequestreview-3090664823 From dholmes at openjdk.org Wed Aug 6 07:01:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 07:01:06 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:16:32 GMT, Johan Sj?len wrote: >> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483: >> >>> 1481: // Is an explicit slot given? >>> 1482: bool explicit_search = slot >= 0; >>> 1483: if (explicit_search) { >> >> Suggestion: >> >> if (slot >= 0) { >> >> No need for the temporary local. > > If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does. That is what comments are for. >> src/java.base/share/classes/java/lang/NullPointerException.java line 78: >> >>> 76: NullPointerException(int stackOffset, int searchSlot) { >>> 77: extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot); >>> 78: this(); >> >> I thought `this()` had to come first in a constructor? Is this new in 25 or 26? > > https://openjdk.org/jeps/492 And now final - https://openjdk.org/jeps/513 Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256053422 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256047794 From jsjolen at openjdk.org Wed Aug 6 07:48:23 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Aug 2025 07:48:23 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: <7IGhtSwHIBGIY1j6nJCm3Sjv6l28aHypbC98PwPL_Ak=.5d270255-7419-4754-9775-9fc546dae1e2@github.com> On Wed, 6 Aug 2025 06:57:55 GMT, David Holmes wrote: >> If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does. > > That is what comments are for. I'd rather explain things with code than with comments when possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256207131 From tschatzl at openjdk.org Wed Aug 6 08:14:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Aug 2025 08:14:04 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 The other comment may be handled separately. src/hotspot/share/gc/g1/g1VMOperations.cpp line 54: > 52: GCCauseSetter x(g1h, _gc_cause); > 53: bool clear_all_soft_refs = _gc_cause == GCCause::_metadata_GC_clear_soft_refs || > 54: _gc_cause == GCCause::_wb_full_gc; Now that three collectors use this, it might be useful to factor this out as a helper function in `CollectedHeap` and use it. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26648#pullrequestreview-3091140646 PR Review Comment: https://git.openjdk.org/jdk/pull/26648#discussion_r2256297755 From mhaessig at openjdk.org Wed Aug 6 08:34:05 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 6 Aug 2025 08:34:05 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: <1YTjfZh0C7UWqTCXWcNS-Q68kBOnhlRJA_-sS_vZsio=.6389ba30-8f3a-48c2-b0e2-40f5877f4a36@github.com> References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> <1YTjfZh0C7UWqTCXWcNS-Q68kBOnhlRJA_-sS_vZsio=.6389ba30-8f3a-48c2-b0e2-40f5877f4a36@github.com> Message-ID: On Tue, 5 Aug 2025 21:33:52 GMT, Dean Long wrote: >> The compiler thread setting and unsetting the flag and the signal handler reading the flag are racing each other as soon as the timer is set, since signals are preemptive. This prevents a few false positive timeouts on architectures with weak memory models, but does not have any effect on x86 for example. > > The signal is delivered to the same compiler thread, so I don't think acquire and release help here. There shouldn't be a weak memory model issue between a thread and it's signal handler on the same thread. Can you explain the sequence of events that could cause a false positive? As far as I understand weak memory models, the concept of threads, which the CPU does not know of, is irrelevant. The CPU is merely free to reorder a subset of memory operations. The reason I added the acquire/release semantics is to prevent the reordering of a write to `_timeout_armed` that happened before a read from the same in the signal handler. This is only relevant when a compilation is done and the timeout is disarmed just before the timer fires. Granted, this is an edge case that does not create a huge amount of false positives. Also, it might be entirely unnecessary due to the OS doing some work to call the signal handler in-between the write and the read of the value. It is merely conservative programming, so I am fine with dropping the barriers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2256370628 From adinn at openjdk.org Wed Aug 6 08:38:06 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 6 Aug 2025 08:38:06 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache In-Reply-To: <1xrYsWuO2i0clJuaenUnLY9U24K4IvY22ATv3WiHQuk=.0687a2e4-7723-432a-bd3b-b98451b3c376@github.com> References: <1xrYsWuO2i0clJuaenUnLY9U24K4IvY22ATv3WiHQuk=.0687a2e4-7723-432a-bd3b-b98451b3c376@github.com> Message-ID: On Tue, 5 Aug 2025 23:22:34 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/opto/c2compiler.cpp line 95: >> >>> 93: // If there was an error generating the blob then UseCompiler will >>> 94: // have been unset and we need to skip the remaining initialization >>> 95: if (UseCompiler) { >> >> Inverting the if condition here would result in slightly more readable code: you could early return `false`, avoid the additional indentation, and the comment at L93-94 would refer to the true branch of the `if` statement. > > Should we also check it before calling `compiler_stubs_init()` too? We could but I don't think it makes much difference. This is a race we could lose at any time. If we have already lost at the point of call then the called method will attempt the buffer allocate and fail almost immediately. So, checking here doesn't help avoid any real work. I will modify the logic to return early -- although not because I agree that the current code is difficult to read. But it is important to preserve the current indentation, making the cumulative change history simpler to follow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26642#discussion_r2256385920 From aph at openjdk.org Wed Aug 6 08:45:03 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Aug 2025 08:45:03 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <62G2O_C4dHe0yNocFL7vmma7XWoyr9rTGO2p7Y6i_Z0=.15588516-31e5-4d8c-9003-92cd45fe1dd4@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> <62G2O_C4dHe0yNocFL7vmma7XWoyr9rTGO2p7Y6i_Z0=.15588516-31e5-4d8c-9003-92cd45fe1dd4@github.com> Message-ID: <4vmsKSTm9EbwBvumxVmTBl857VH9mGdmNOvj8PeHR3s=.bc1255dd-9375-47c1-8fa3-84069835753e@github.com> On Tue, 5 Aug 2025 21:40:27 GMT, Dean Long wrote: > In the past we would have scheduled the load for x8 earlier to avoid a latency hit for using the value in the next instruction: > > ``` > ldr x8, Label_entry > ldr x12, Label_data > br x8 > ``` > > Is this still helpful on modern aarch64 hardware? Maybe on something very small, such as the Cortex-A34. It doesn't hurt larger out-of-order cores, so I agree with you that we should reorder this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3158299392 From adinn at openjdk.org Wed Aug 6 08:50:57 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 6 Aug 2025 08:50:57 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache [v2] In-Reply-To: References: Message-ID: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: minimize changed lines and align log messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26642/files - new: https://git.openjdk.org/jdk/pull/26642/files/5889ce2b..7a28bc7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26642&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26642&range=00-01 Stats: 16 lines in 2 files changed: 7 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26642/head:pull/26642 PR: https://git.openjdk.org/jdk/pull/26642 From adinn at openjdk.org Wed Aug 6 08:50:58 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 6 Aug 2025 08:50:58 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:21:01 GMT, Andrew Dinn wrote: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. New version addresses all comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3158332733 From duke at openjdk.org Wed Aug 6 08:56:10 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Aug 2025 08:56:10 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 06:55:54 GMT, David Holmes wrote: >> https://openjdk.org/jeps/492 > > And now final - https://openjdk.org/jeps/513 > > Thanks It?s?necessary to?do?this?before the?`this()`/`super()`?call, as?the?`Throwable(?)` constructors?call `this.fillInStackTrace()`: https://github.com/openjdk/jdk/blob/e304d37996b075b8b2b44b5762d7d242169add49/src/java.base/share/classes/java/lang/Throwable.java#L263-L264 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256443245 From fgao at openjdk.org Wed Aug 6 09:19:51 2025 From: fgao at openjdk.org (Fei Gao) Date: Wed, 6 Aug 2025 09:19:51 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD Message-ID: If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. ------------- Commit messages: - 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD Changes: https://git.openjdk.org/jdk/pull/26653/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26653&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362504 Stats: 65 lines in 2 files changed: 59 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26653.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26653/head:pull/26653 PR: https://git.openjdk.org/jdk/pull/26653 From duke at openjdk.org Wed Aug 6 09:27:29 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 09:27:29 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v26] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/fbceea99..f9d9bc4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=24-25 Stats: 16 lines in 2 files changed: 2 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Wed Aug 6 09:27:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 09:27:30 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: <7685_Xh8MjRqxoEx2BWfpTcdPXq5-aDuo0XZfTcco5w=.00416a73-5237-4381-a79d-8973f47b19ed@github.com> Message-ID: On Wed, 6 Aug 2025 03:50:43 GMT, David Holmes wrote: >> I think this would change the usage pattern again. Do we want a failing assert in every memory function in case of failure? I thought the consensus is that a false values returned by the function is indicating that. In this particular case it will be easy to trace which method failed as their results are stored as local variables. > > The assert should go after the syscall that we don't expect to fail, but which we have to tolerate the possibility of failing. That is the place where we can also report why the call failed. > > I'm not sure what you mean about changing the usage pattern. What I meant is that in this PR we are focusing on adding a mechanism to indicate that something failed, not on reporting why that fail. Addressed as suggested. >> I suggest to keep results as locals, see my previous comment. > > Sorry I don't see a connection to previous comment about the assert. You only need a local if you need to refer to something more than once. With the locals it would be visible in debugging which of those methods failed if any. Addressed as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256537890 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256537325 From duke at openjdk.org Wed Aug 6 09:27:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 09:27:30 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v25] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 03:42:19 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Addressed reviewer's comments > > src/hotspot/os/linux/os_linux.cpp line 299: > >> 297: jlong memory_and_swap_limit_in_bytes = OSContainer::memory_and_swap_limit_in_bytes(); >> 298: jlong memory_limit_in_bytes = OSContainer::memory_limit_in_bytes(); >> 299: value = static_cast(memory_and_swap_limit_in_bytes - memory_limit_in_bytes); > > This isn't what I meant. You want to save into the locals before each of the `if` statements, else you are still calling these functions twice. Right, I changed the way it is done as suggested. > src/hotspot/os/windows/os_windows.cpp line 869: > >> 867: return true; >> 868: } else { >> 869: errno = ::GetLastError(); > > Why are you setting `errno` here and elsewhere? I see a couple of places where we do do that though I do not know why, but generally we just want to save the `::GetlastError()` value (here we do need a local) and print it. You are correct, there is no relationship between `errno` and `GetLastError()`. Addressed. I created a separate issue to fix this inconsistency in other places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256538537 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256536814 From aph at openjdk.org Wed Aug 6 09:33:04 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Aug 2025 09:33:04 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Tue, 5 Aug 2025 21:47:34 GMT, Dean Long wrote: > > Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. > > I thought other threads are modifying the data, which is the reason why we needed the ISB. Yes, exactly. Other threads are executing this nmethod while we are modifying its static call stub. We hold the lock while we're doing this, so any thread racing with us to _modify_ the call stub would be blocked. However, another thread could execute the call we just patched but not fully observe the changes we made to the stub, which is why we need the ISB. We have a similar situation with this PR, but with data rather than instruction memory. We need to make sure that any racing thread observes changes to the stub before it observes the patched call to the stub. There is no ordering between instruction and data memory, which is why the current stub uses only instruction memory, keeping everything right. The ISB ensures that the executing thread observes the changed stub: there is a happens-before from the `ICache::invalidate_range` after patching the stub (but before patching the call) to the `isb` at the start of the stub. For this PR to be correctly synchronized, we'd need a similar happens-before from patching the constants used in the stub to executing the stub. I can think of a way to do that, but it's fiddly and may not be worth it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2256564579 From cnorrbin at openjdk.org Wed Aug 6 09:40:16 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 6 Aug 2025 09:40:16 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree Message-ID: Hi everyone, The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter constraints, the treap can be removed in favour of it. I made some modifications to the red-black tree to make it compatible with previous treap usages: - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. Changes to NMT include: - Modified components to align with the updated const-correctness of the red-black tree functions - Renamed structures and variables to remove "treap" from their names to reflect the new tree The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. ------------- Commit messages: - Replace nmttreap with rbtree Changes: https://git.openjdk.org/jdk/pull/26655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352067 Stats: 1016 lines in 14 files changed: 124 ins; 816 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/26655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26655/head:pull/26655 PR: https://git.openjdk.org/jdk/pull/26655 From duke at openjdk.org Wed Aug 6 09:48:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 09:48:28 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v27] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Fixed whitespace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/f9d9bc4a..f62ed1d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=25-26 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From jsjolen at openjdk.org Wed Aug 6 10:00:04 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Aug 2025 10:00:04 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 09:29:05 GMT, Casper Norrbin wrote: > Hi everyone, > > The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. > > I made some modifications to the red-black tree to make it compatible with previous treap usages: > - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. > - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. > > Changes to NMT include: > - Modified components to align with the updated const-correctness of the red-black tree functions > - Renamed structures and variables to remove "treap" from their names to reflect the new tree > > The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. This LGTM. What testing did you run? src/hotspot/share/nmt/vmatree.hpp line 196: > 194: > 195: public: > 196: using VMARBTree = RBTreeCHeap; You should be abl to just write 'mtNMT', same for all other `MemTag::` prefixes. src/hotspot/share/opto/printinlining.cpp line 90: > 88: > 89: return node->val(); > 90: } Could you expand the `auto`s? It should be a code action in VSCode if you use clangd. We tend to only use auto when it's a lambda. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3091786865 PR Review Comment: https://git.openjdk.org/jdk/pull/26655#discussion_r2256636655 PR Review Comment: https://git.openjdk.org/jdk/pull/26655#discussion_r2256634808 From aph at openjdk.org Wed Aug 6 10:02:03 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Aug 2025 10:02:03 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: Message-ID: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> On Wed, 6 Aug 2025 09:13:30 GMT, Fei Gao wrote: > If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3158946110 From duke at openjdk.org Wed Aug 6 10:10:14 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 10:10:14 GMT Subject: RFR: 8364819: Cleanup handshake_timed_out_thread and safepoint_timed_out_thread Message-ID: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Hi, please consider the following changes: This is a cleanup after https://github.com/openjdk/jdk/pull/26309 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. 2) Added a missed brace in the error message. Trivial change. ------------- Commit messages: - 8364819: Cleanup Changes: https://git.openjdk.org/jdk/pull/26656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364819 Stats: 16 lines in 4 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From adinn at openjdk.org Wed Aug 6 10:20:02 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 6 Aug 2025 10:20:02 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: Message-ID: <7aQZ9mKf7PrVcYmsTZZdYp9BgmcNU5pMdu0Tyf_GHGs=.e04966ee-2515-4e0e-9714-4ffc35025d7f@github.com> On Wed, 6 Aug 2025 09:13:30 GMT, Fei Gao wrote: > If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. I agree with Andrew that this may well be slower even if it does save on code size. So, the trade-off being made here is not clear-cut. I also think we need to consider and allow for save and restore of adapter, stub and, in upcoming releases, nmethod code using the AOT cache. Both code cache to code cache (runtime) calls and code cache to foreign (external) calls may require a one-off offset adjustment during AOT code loading. This can happen because 1) code generated at some given address and saved from the Assembly VM may be restored in a Production VM at a different address and 2) references from generated code to a method/function address in some given external C library loaded in the Assembly VM may need adjustment to allow for the library and associated function/method being loaded at a different address. This reloc at reload should not be an issue for generated calls to the runtime since wherever the saved code is reloaded the call offset will still be less than the cache range and that will be less than 2GB. So, we can always patch an 'adrp + add' with another 'adrp + add' However, it is significant for foreign calls where restoration at a different place in the cache and/or randomization of library load addresses implies that a positive reachability decision made at Assembly time might no longer hold in a Production run. In that case an 'adrp + add' pair would not be able to be simply patched to a 'movz + movk + movk' triple. The solution is to make the compiler always generate the 3-instruction load when compiling in an Assembly VM and otherwise generate the 2-instruction load based on reachability i.e. AOT code won't 'benefit' from this patch but runtime generated code will (assuming it is a benefit). So, the reachability method needs to return false if `AOTCodeCache::is_on_for_dump() returns true. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3159151855 From adinn at openjdk.org Wed Aug 6 10:36:04 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 6 Aug 2025 10:36:04 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Wed, 6 Aug 2025 09:30:07 GMT, Andrew Haley wrote: >>> Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. >> >> I thought other threads are modifying the data, which is the reason why we needed the ISB. > >> > Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. >> >> I thought other threads are modifying the data, which is the reason why we needed the ISB. > > Yes, exactly. Other threads are executing this nmethod while we are modifying its static call stub. > > We hold the lock while we're doing this, so any thread racing with us to _modify_ the call stub would be blocked. However, another thread could execute the call we just patched but not fully observe the changes we made to the stub, which is why we need the ISB. > > We have a similar situation with this PR, but with data rather than instruction memory. We need to make sure that any racing thread observes changes to the stub before it observes the patched call to the stub. There is no ordering between instruction and data memory, which is why the current stub uses only instruction memory, keeping everything right. The ISB ensures that the executing thread observes the changed stub: there is a happens-before from the `ICache::invalidate_range` after patching the stub (but before patching the call) to the `isb` at the start of the stub. > > For this PR to be correctly synchronized, we'd need a similar happens-before from patching the constants used in the stub to executing the stub. I can think of a way to do that, but it's fiddly and may not be worth it. Yes, it's a very subtle point that the isb serves to isolate threads executing the call from partial updates by of the writing thread i.e. make the change to the call site atomic. It might be useful to have that written in some comment in the patching code rather than just documented in this issue (but it helps to have it said here). I understand that an isb is relatively expensive and I don't doubt the figures provided from running the micro-benchmark. However, they are not necessarily any indication that there is a problem here. How many such call sites are there and how often do they get patched? Is that significant relative relative to, say, the number of times they are executed or some other measure of overall cost? Is there evidence that we really need to fix this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2256731349 From shade at openjdk.org Wed Aug 6 10:41:02 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 10:41:02 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <1wywkzcGrfAM2m-1EGH6cKvocvHD6hvgKo8uALsi-M8=.e6f51458-30ba-449d-ad3b-0ce5ed37bbd1@github.com> On Wed, 6 Aug 2025 10:05:08 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Also a closing parenthesis in test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java message matcher, I think? A better name for the PR and ticket is: "8364819: Post-integration cleanups for JDK-8359820" ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3159406353 PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3159417870 From duke at openjdk.org Wed Aug 6 10:48:43 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 10:48:43 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Fixed brace in the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/f7aa7a7c..8c2915bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From shade at openjdk.org Wed Aug 6 10:48:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 10:48:43 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> Message-ID: On Wed, 6 Aug 2025 10:45:01 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Fixed brace in the test This looks fine to me, thanks! But @dholmes-ora should take another look, since he reviewed the original patch. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3091955121 From duke at openjdk.org Wed Aug 6 10:48:43 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 10:48:43 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 In-Reply-To: <1wywkzcGrfAM2m-1EGH6cKvocvHD6hvgKo8uALsi-M8=.e6f51458-30ba-449d-ad3b-0ce5ed37bbd1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1wywkzcGrfAM2m-1EGH6cKvocvHD6hvgKo8uALsi-M8=.e6f51458-30ba-449d-ad3b-0ce5ed37bbd1@github.com> Message-ID: On Wed, 6 Aug 2025 10:37:32 GMT, Aleksey Shipilev wrote: > Also a closing parenthesis in test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java message matcher, I think? Thanks for spotting, yes, that one has to be changed. Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3159472025 From rrich at openjdk.org Wed Aug 6 10:58:16 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Aug 2025 10:58:16 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Message-ID: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. Details: It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. ------------- Commit messages: - Fix comment - Weaken assertion. The bottom frame's caller can have the smaller parent_ijava_frame_abi. Changes: https://git.openjdk.org/jdk/pull/26643/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26643&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360219 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26643/head:pull/26643 PR: https://git.openjdk.org/jdk/pull/26643 From cnorrbin at openjdk.org Wed Aug 6 11:07:42 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 6 Aug 2025 11:07:42 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. > > I made some modifications to the red-black tree to make it compatible with previous treap usages: > - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. > - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. > > Changes to NMT include: > - Modified components to align with the updated const-correctness of the red-black tree functions > - Renamed structures and variables to remove "treap" from their names to reflect the new tree > > The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: feedback fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26655/files - new: https://git.openjdk.org/jdk/pull/26655/files/97107f5b..a495e291 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26655&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26655/head:pull/26655 PR: https://git.openjdk.org/jdk/pull/26655 From dholmes at openjdk.org Wed Aug 6 12:01:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 12:01:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> <1YTjfZh0C7UWqTCXWcNS-Q68kBOnhlRJA_-sS_vZsio=.6389ba30-8f3a-48c2-b0e2-40f5877f4a36@github.com> Message-ID: On Wed, 6 Aug 2025 08:31:26 GMT, Manuel H?ssig wrote: >> The signal is delivered to the same compiler thread, so I don't think acquire and release help here. There shouldn't be a weak memory model issue between a thread and it's signal handler on the same thread. Can you explain the sequence of events that could cause a false positive? > > As far as I understand weak memory models, the concept of threads, which the CPU does not know of, is irrelevant. The CPU is merely free to reorder a subset of memory operations. The reason I added the acquire/release semantics is to prevent the reordering of a write to `_timeout_armed` that happened before a read from the same in the signal handler. This is only relevant when a compilation is done and the timeout is disarmed just before the timer fires. > > Granted, this is an edge case that does not create a huge amount of false positives. Also, it might be entirely unnecessary due to the OS doing some work to call the signal handler in-between the write and the read of the value. It is merely conservative programming, so I am fine with dropping the barriers. That is not an accurate characterisation IMO - a memory model defines the consistency of the views of memory by different threads of execution. Any given thread of execution must always have a self-consistent view of memory, and neither the compiler or the CPU is allowed to violate that if code is actually going to be guaranteed to work correctly. If the signal is being handled in the same thread that is setting the flag then you cannot have a memory ordering issue. And acquire/release is not the right tool just to establish an ordering: you would generally want a storestore barrier on the writer side, and a loadload barrier on the reader side. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2256920642 From dholmes at openjdk.org Wed Aug 6 12:11:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 12:11:10 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: <7685_Xh8MjRqxoEx2BWfpTcdPXq5-aDuo0XZfTcco5w=.00416a73-5237-4381-a79d-8973f47b19ed@github.com> Message-ID: On Wed, 6 Aug 2025 09:22:33 GMT, Anton Artemov wrote: >> The assert should go after the syscall that we don't expect to fail, but which we have to tolerate the possibility of failing. That is the place where we can also report why the call failed. >> >> I'm not sure what you mean about changing the usage pattern. > > What I meant is that in this PR we are focusing on adding a mechanism to indicate that something failed, not on reporting why that fail. > > Addressed as suggested. If we are going to assert on failure then we should report as much information about the failure as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256943006 From dholmes at openjdk.org Wed Aug 6 12:11:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 12:11:11 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v25] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 09:22:12 GMT, Anton Artemov wrote: >> src/hotspot/os/windows/os_windows.cpp line 869: >> >>> 867: return true; >>> 868: } else { >>> 869: errno = ::GetLastError(); >> >> Why are you setting `errno` here and elsewhere? I see a couple of places where we do do that though I do not know why, but generally we just want to save the `::GetlastError()` value (here we do need a local) and print it. > > You are correct, there is no relationship between `errno` and `GetLastError()`. Addressed. > > I created a separate issue to fix this inconsistency in other places. I had forgotten that this oddity was also raised in the review of [JDK-8350869](https://bugs.openjdk.org/browse/JDK-8350869). If it is part of the `os::xxx` function's specification to set `errno` on failure then we would need to do something to achieve that (which I think was the intended case with something like `os::stat`) though as previously noted the set of allowed values for `errno` and `GetLastErrror` are not the same. But the API's in question here are not specified that way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2256937209 From mhaessig at openjdk.org Wed Aug 6 12:26:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 6 Aug 2025 12:26:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> <1YTjfZh0C7UWqTCXWcNS-Q68kBOnhlRJA_-sS_vZsio=.6389ba30-8f3a-48c2-b0e2-40f5877f4a36@github.com> Message-ID: On Wed, 6 Aug 2025 11:58:22 GMT, David Holmes wrote: >> As far as I understand weak memory models, the concept of threads, which the CPU does not know of, is irrelevant. The CPU is merely free to reorder a subset of memory operations. The reason I added the acquire/release semantics is to prevent the reordering of a write to `_timeout_armed` that happened before a read from the same in the signal handler. This is only relevant when a compilation is done and the timeout is disarmed just before the timer fires. >> >> Granted, this is an edge case that does not create a huge amount of false positives. Also, it might be entirely unnecessary due to the OS doing some work to call the signal handler in-between the write and the read of the value. It is merely conservative programming, so I am fine with dropping the barriers. > > That is not an accurate characterisation IMO - a memory model defines the consistency of the views of memory by different threads of execution. Any given thread of execution must always have a self-consistent view of memory, and neither the compiler or the CPU is allowed to violate that if code is actually going to be guaranteed to work correctly. If the signal is being handled in the same thread that is setting the flag then you cannot have a memory ordering issue. > > And acquire/release is not the right tool just to establish an ordering: you would generally want a storestore barrier on the writer side, and a loadload barrier on the reader side. Ah, I see my mistake. 1) I did not think about the C++ memory model, and 2) I thought of the signal handler as a different thread, which made me a bit paranoid. Thank you both for pointing out the mistakes in my thinking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2256979751 From dholmes at openjdk.org Wed Aug 6 12:38:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 12:38:06 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> Message-ID: <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> On Wed, 6 Aug 2025 10:48:43 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Fixed brace in the test Thanks for catching these @shipilev . I have to confess I thought there was a reason we stored the thread as just an id rather than a true pointer, but I was mistaken. @toxaart thanks for the speedy follow up here. I have one other nit I just noticed - @shipilev may want to weigh in on it too. src/hotspot/share/utilities/vmError.cpp line 108: > 106: const intptr_t VMError::segfault_address = pd_segfault_address; > 107: volatile Thread* VMError::_handshake_timed_out_thread = nullptr; > 108: volatile Thread* VMError::_safepoint_timed_out_thread = nullptr; I should have picked this up previously but `volatile` generally serves no purpose for inter-thread consistency. If we need to guarantee visibility between the signaller and signalee, then we need a fence to ensure that. Or we can skip the fence (and volatile) and note that this will usually, but perhaps not always, work fine. (I note that `pthread_kill` is not specified as a memory synchronizing operation, but I strongly suspect it has to have its own internal memory barriers that we would be piggy-backing on.) ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3092261002 PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2256961025 From shade at openjdk.org Wed Aug 6 13:02:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 13:02:04 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> Message-ID: <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> On Wed, 6 Aug 2025 12:15:57 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Fixed brace in the test > > src/hotspot/share/utilities/vmError.cpp line 108: > >> 106: const intptr_t VMError::segfault_address = pd_segfault_address; >> 107: volatile Thread* VMError::_handshake_timed_out_thread = nullptr; >> 108: volatile Thread* VMError::_safepoint_timed_out_thread = nullptr; > > I should have picked this up previously but `volatile` generally serves no purpose for inter-thread consistency. If we need to guarantee visibility between the signaller and signalee, then we need a fence to ensure that. Or we can skip the fence (and volatile) and note that this will usually, but perhaps not always, work fine. (I note that `pthread_kill` is not specified as a memory synchronizing operation, but I strongly suspect it has to have its own internal memory barriers that we would be piggy-backing on.) I am pretty sure the memory consistency here is irrelevant, given that: a) the `Thread` in question is likely already initialized for a long time, so it is unlikely we will lose anything release-acquire-wise; b) we only use these for pointer comparisons. But since we are here, and in the interest of clarity and avoiding future surprises, we can just summarily wrap these with `Atomic::release_store` and `Atomic::load_acquire` to be extra paranoidly safe. This is a failing path, so we don't care about performance, and would like to avoid a secondary crash in error handler some time in the future, if anyone reads anything from these threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257071709 From mhaessig at openjdk.org Wed Aug 6 13:19:33 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 6 Aug 2025 13:19:33 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v3] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [ ] Github Actions > - [ ] tier1, tier2 on all platforms > - [ ] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [ ] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into JDK-8308094-timeout - No acquire release semantics - Factor Linux specific timeout functionality out of share/ - Move timeout disarm above if - Merge branch 'master' into JDK-8308094-timeout - Fix SIGALRM test - Add timeout functionality to compiler threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/5840cc2e..d50231f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=01-02 Stats: 67038 lines in 1707 files changed: 39117 ins; 18664 del; 9257 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Wed Aug 6 13:19:34 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 6 Aug 2025 13:19:34 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2] In-Reply-To: References: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com> Message-ID: On Tue, 5 Aug 2025 04:04:01 GMT, Dean Long wrote: >> Manuel H?ssig 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-8308094-timeout >> - Fix SIGALRM test >> - Add timeout functionality to compiler threads > > This looks correct, but would it be possible to move the Linux-specific code out of src/hotspot/share? Thank you for reviewing this PR, @dean-long. For v2 I factored the Linux-specific code out of hotspot/share, moved the disarm above the if, and removed the acquire/release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3160140787 From asmehra at openjdk.org Wed Aug 6 14:05:08 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 6 Aug 2025 14:05:08 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 18:08:22 GMT, Ashutosh Mehra wrote: >> This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. >> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. >> Platforms affected: x86-64 and aarch64 >> Other platforms can be done if and when Leyden changes are ported to them. >> >> [0] https://github.com/openjdk/leyden/pull/84 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > > Signed-off-by: Ashutosh Mehra Can I get one more review of this please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26515#issuecomment-3160311221 From duke at openjdk.org Wed Aug 6 14:06:19 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 14:06:19 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v3] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Made handling of timed out thread safe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/8c2915bb..594654e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=01-02 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From duke at openjdk.org Wed Aug 6 14:06:21 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 14:06:21 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> Message-ID: On Wed, 6 Aug 2025 12:15:57 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Fixed brace in the test > > src/hotspot/share/utilities/vmError.cpp line 108: > >> 106: const intptr_t VMError::segfault_address = pd_segfault_address; >> 107: volatile Thread* VMError::_handshake_timed_out_thread = nullptr; >> 108: volatile Thread* VMError::_safepoint_timed_out_thread = nullptr; > > I should have picked this up previously but `volatile` generally serves no purpose for inter-thread consistency. If we need to guarantee visibility between the signaller and signalee, then we need a fence to ensure that. Or we can skip the fence (and volatile) and note that this will usually, but perhaps not always, work fine. (I note that `pthread_kill` is not specified as a memory synchronizing operation, but I strongly suspect it has to have its own internal memory barriers that we would be piggy-backing on.) Thanks @dholmes-ora and @shipilev, I addressed the possible issue with atomic commands. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257292348 From shade at openjdk.org Wed Aug 6 14:14:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 14:14:09 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v3] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Wed, 6 Aug 2025 14:06:19 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Made handling of timed out thread safe Comments... src/hotspot/share/utilities/vmError.hpp line 229: > 227: static void set_safepoint_timed_out_thread(Thread* thread); > 228: static volatile Thread* get_handshake_timed_out_thread(); > 229: static volatile Thread* get_safepoint_timed_out_thread(); `static volatile` for method declarations makes no real sense? Just `static` would suffice. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3092817846 PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257319054 From duke at openjdk.org Wed Aug 6 14:21:04 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 14:21:04 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v3] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Wed, 6 Aug 2025 14:11:22 GMT, Aleksey Shipilev wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Made handling of timed out thread safe > > src/hotspot/share/utilities/vmError.hpp line 229: > >> 227: static void set_safepoint_timed_out_thread(Thread* thread); >> 228: static volatile Thread* get_handshake_timed_out_thread(); >> 229: static volatile Thread* get_safepoint_timed_out_thread(); > > `static volatile` for method declarations makes no real sense? Just `static` would suffice. If the variable is declared volatile, the same should be done with the getter, otherwise GCC complains about conversion: error: invalid conversion from 'volatile Thread*' to 'Thread*' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257345662 From kvn at openjdk.org Wed Aug 6 15:04:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 6 Aug 2025 15:04:14 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 18:08:22 GMT, Ashutosh Mehra wrote: >> This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. >> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. >> Platforms affected: x86-64 and aarch64 >> Other platforms can be done if and when Leyden changes are ported to them. >> >> [0] https://github.com/openjdk/leyden/pull/84 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > > Signed-off-by: Ashutosh Mehra I submitted our testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26515#issuecomment-3160539796 From kvn at openjdk.org Wed Aug 6 15:19:08 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 6 Aug 2025 15:19:08 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache [v2] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 08:50:57 GMT, Andrew Dinn wrote: >> This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > minimize changed lines and align log messages Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26642#pullrequestreview-3093156997 From shade at openjdk.org Wed Aug 6 15:04:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 15:04:04 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v3] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Wed, 6 Aug 2025 14:18:48 GMT, Anton Artemov wrote: >> src/hotspot/share/utilities/vmError.hpp line 229: >> >>> 227: static void set_safepoint_timed_out_thread(Thread* thread); >>> 228: static volatile Thread* get_handshake_timed_out_thread(); >>> 229: static volatile Thread* get_safepoint_timed_out_thread(); >> >> `static volatile` for method declarations makes no real sense? Just `static` would suffice. > > If the variable is declared volatile, the same should be done with the getter, otherwise GCC complains about conversion: > > error: invalid conversion from 'volatile Thread*' to 'Thread*' Oh, that's because you probably want the: static Thread* volatile _handshake_timed_out_thread; ...not: static volatile Thread* _handshake_timed_out_thread; I.e. the volatility is about the _field_, not about the _type_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257487900 From duke at openjdk.org Wed Aug 6 15:20:44 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 15:20:44 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v4] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Fixed volatility issue on getters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/594654e4..1cac9daa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From duke at openjdk.org Wed Aug 6 15:20:44 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 6 Aug 2025 15:20:44 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v3] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Wed, 6 Aug 2025 15:01:23 GMT, Aleksey Shipilev wrote: >> If the variable is declared volatile, the same should be done with the getter, otherwise GCC complains about conversion: >> >> error: invalid conversion from 'volatile Thread*' to 'Thread*' > > Oh, that's because you probably want the: > > > static Thread* volatile _handshake_timed_out_thread; > > > ...not: > > > static volatile Thread* _handshake_timed_out_thread; > > > I.e. the volatility is about the _field_, not about the _type_. Right, noted! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2257530740 From shade at openjdk.org Wed Aug 6 18:19:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Aug 2025 18:19:17 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v4] In-Reply-To: <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> Message-ID: On Wed, 6 Aug 2025 15:20:44 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Fixed volatility issue on getters. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3093723210 From pchilanomate at openjdk.org Wed Aug 6 18:22:54 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Aug 2025 18:22:54 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error Message-ID: Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/26660/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359222 Stats: 32 lines in 4 files changed: 20 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26660/head:pull/26660 PR: https://git.openjdk.org/jdk/pull/26660 From rriggs at openjdk.org Wed Aug 6 18:52:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Aug 2025 18:52:16 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: <0_Cs4qRmBwmfZE8qrUNZaRCtUfWqarRBdrzZjGEZvLM=.9a0b66f9-9a12-4296-9c90-304080e72886@github.com> On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review A hotspot and 2 core-libs reviewers should have a chance to comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3161228199 From rriggs at openjdk.org Wed Aug 6 18:52:17 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Aug 2025 18:52:17 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> Message-ID: On Tue, 5 Aug 2025 15:01:49 GMT, Chen Liang wrote: >> Don't add APIs without uses; it speculative and the API may not be what is really needed. > > Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)? Please update the description to note this is a pre-requsite for: [JDK-8233268](https://bugs.openjdk.org/browse/JDK-8233268) Improve integration of Objects.requireNonNull and JEP 358 Helpful NPE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2257996201 From amenkov at openjdk.org Wed Aug 6 19:12:31 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 6 Aug 2025 19:12:31 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v8] In-Reply-To: References: Message-ID: <733zJmz4QYLOKTZ5lU1rp13UvWeJaQ7fesb5cBmLFr8=.8a9f7720-fec8-4c84-8cd7-7b04c6b74dd2@github.com> > The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. > > Testing: tier1..5 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/classfile/javaClasses.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26119/files - new: https://git.openjdk.org/jdk/pull/26119/files/811db312..3cc69d8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119 PR: https://git.openjdk.org/jdk/pull/26119 From dholmes at openjdk.org Wed Aug 6 21:06:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Aug 2025 21:06:16 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v4] In-Reply-To: <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> Message-ID: On Wed, 6 Aug 2025 15:20:44 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Fixed volatility issue on getters. Changes requested by dholmes (Reviewer). src/hotspot/share/utilities/vmError.cpp line 108: > 106: const intptr_t VMError::segfault_address = pd_segfault_address; > 107: Thread* volatile VMError::_handshake_timed_out_thread = nullptr; > 108: Thread* volatile VMError::_safepoint_timed_out_thread = nullptr; `volatile` is still not useful or needed here. src/hotspot/share/utilities/vmError.cpp line 1346: > 1344: > 1345: void VMError::set_safepoint_timed_out_thread(Thread* thread) { > 1346: Atomic::release_store(&_safepoint_timed_out_thread, thread); Acquire/release is not what is needed here. You are not trying to synchronize with previous memory accesses. If you want to force this to be visible to the other thread a `fence()` is required. ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3094270934 PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2258292221 PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2258295173 From dlong at openjdk.org Thu Aug 7 01:14:25 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 01:14:25 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v3] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 13:19:33 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [ ] Github Actions >> - [ ] tier1, tier2 on all platforms >> - [ ] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [ ] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8308094-timeout > - No acquire release semantics > - Factor Linux specific timeout functionality out of share/ > - Move timeout disarm above if > - Merge branch 'master' into JDK-8308094-timeout > - Fix SIGALRM test > - Add timeout functionality to compiler threads Looks good. However, you might want to simply remove _timeout_armed, or put it inside a #ifdef ASSERT, since it is only used in an assert. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3094752418 From dlong at openjdk.org Thu Aug 7 02:00:13 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 02:00:13 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Tue, 5 Aug 2025 14:53:30 GMT, Richard Reingruber wrote: > Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). > > Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. > > Details: > > It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). > > There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. > > It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. It seems like relaxing the assert would allow us to silently overwrite part of a frame::top_ijava_frame_abi, which is only harmless if we are guaranteed to always treat that area as the smaller "parent" ABI past this point. Is there any way to determine if the ABI frame flavor is "top" or "parent" without adding something like a new "abi_frame_type" slot? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26643#issuecomment-3162163970 From kvn at openjdk.org Thu Aug 7 05:34:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 7 Aug 2025 05:34:16 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 18:08:22 GMT, Ashutosh Mehra wrote: >> This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. >> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. >> Platforms affected: x86-64 and aarch64 >> Other platforms can be done if and when Leyden changes are ported to them. >> >> [0] https://github.com/openjdk/leyden/pull/84 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > > Signed-off-by: Ashutosh Mehra My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26515#pullrequestreview-3095366477 From jsjolen at openjdk.org Thu Aug 7 07:15:15 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 7 Aug 2025 07:15:15 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree [v2] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. >> >> I made some modifications to the red-black tree to make it compatible with previous treap usages: >> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. >> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. >> >> Changes to NMT include: >> - Modified components to align with the updated const-correctness of the red-black tree functions >> - Renamed structures and variables to remove "treap" from their names to reflect the new tree >> >> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > feedback fixes Still OK ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3095690422 From duke at openjdk.org Thu Aug 7 07:34:50 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 7 Aug 2025 07:34:50 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/1cac9daa..094eb14a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=03-04 Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From duke at openjdk.org Thu Aug 7 07:34:51 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 7 Aug 2025 07:34:51 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v4] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <39aBWZQQdrwY0PTHhASEW1vELD_g4OMDAJ62mUGObj4=.82f28cb9-83d3-4511-b081-1e998418dd5b@github.com> Message-ID: On Wed, 6 Aug 2025 21:02:16 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Fixed volatility issue on getters. > > src/hotspot/share/utilities/vmError.cpp line 108: > >> 106: const intptr_t VMError::segfault_address = pd_segfault_address; >> 107: Thread* volatile VMError::_handshake_timed_out_thread = nullptr; >> 108: Thread* volatile VMError::_safepoint_timed_out_thread = nullptr; > > `volatile` is still not useful or needed here. Removed. > src/hotspot/share/utilities/vmError.cpp line 1346: > >> 1344: >> 1345: void VMError::set_safepoint_timed_out_thread(Thread* thread) { >> 1346: Atomic::release_store(&_safepoint_timed_out_thread, thread); > > Acquire/release is not what is needed here. You are not trying to synchronize with previous memory accesses. If you want to force this to be visible to the other thread a `fence()` is required. Yes, that is what we want, thanks. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2259389904 PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2259389450 From dholmes at openjdk.org Thu Aug 7 08:31:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 08:31:19 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Wed, 6 Aug 2025 12:59:01 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/utilities/vmError.cpp line 108: >> >>> 106: const intptr_t VMError::segfault_address = pd_segfault_address; >>> 107: volatile Thread* VMError::_handshake_timed_out_thread = nullptr; >>> 108: volatile Thread* VMError::_safepoint_timed_out_thread = nullptr; >> >> I should have picked this up previously but `volatile` generally serves no purpose for inter-thread consistency. If we need to guarantee visibility between the signaller and signalee, then we need a fence to ensure that. Or we can skip the fence (and volatile) and note that this will usually, but perhaps not always, work fine. (I note that `pthread_kill` is not specified as a memory synchronizing operation, but I strongly suspect it has to have its own internal memory barriers that we would be piggy-backing on.) > > I am pretty sure the memory consistency here is irrelevant, given that: a) the `Thread` in question is likely already initialized for a long time, so it is unlikely we will lose anything release-acquire-wise; b) we only use these for pointer comparisons. > > But since we are here, and in the interest of clarity and avoiding future surprises, we can just summarily wrap these with `Atomic::release_store` and `Atomic::load_acquire` to be extra paranoidly safe. This is a failing path, so we don't care about performance, and would like to avoid a secondary crash in error handler some time in the future, if anyone reads anything from these threads. @shipilev The memory consistency is about seeing the writes to these fields in the thread that is signalled. acquire/release has no meaning in this context. I would not add acquire/release just in case someone in the future actually tried to follow those pointers - they are only for identifying purposes. If you are worried about that then lets go back to changing them to a value (intptr_t) so it will never be an issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2259542119 From rrich at openjdk.org Thu Aug 7 08:38:16 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 7 Aug 2025 08:38:16 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Thu, 7 Aug 2025 01:57:22 GMT, Dean Long wrote: > It seems like relaxing the assert would allow us to silently overwrite part of a frame::top_ijava_frame_abi, which is only harmless if we are guaranteed to always treat that area as the smaller "parent" ABI past this point. It is harmless. The interpreted and nmethod calling conventions only use the smaller frame::java_abi (alias for parent_ijava_frame_abi). Calling the VM or other native code requires the full ABI. > Is there any way to determine if the ABI frame flavor is "top" or "parent" without adding something like a new "abi_frame_type" slot? I would not be aware of any way to determine the ABI type easily. I'm sure many people were looking for it since bugs caused by using the wrong type are painful. Even with a dedicated slot in dbg builds it would be hard to keep the correct type since there are many places where frames get resized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26643#issuecomment-3163100058 From dlong at openjdk.org Thu Aug 7 08:47:19 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 08:47:19 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 02:54:22 GMT, Kim Barrett wrote: >> Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. >> Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > >> Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. > > Not a review, just a drive-by comment. > We've had Atomic bitops for a while now. > Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) > Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) > They haven't been optimized for most (any?) platforms, being based on cmpxchg. > (See all the "Specialize atomic bitset functions for ..." related to > https://bugs.openjdk.org/browse/JDK-8293117.) Thanks @kimbarrett. I see that the Atomic::fetch_then_XXX() implementation is very similar to what I came up with. The operation I'm doing is sometimes setting a single bit, so fetch_then_or() could be used, but sometimes the operation is setting the other 31 bits, so a new fetch_then_set_with_mask() would need to be added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3163131928 From dlong at openjdk.org Thu Aug 7 08:51:13 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 08:51:13 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: <57AXuIteOPIZfG8MYQd1_Vp7UPO10wXDoqC8f7lzlYw=.81d965eb-fb7a-4c13-8e2a-10f840b3e8ee@github.com> On Tue, 5 Aug 2025 14:53:30 GMT, Richard Reingruber wrote: > Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). > > Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. > > Details: > > It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). > > There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. > > It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26643#pullrequestreview-3096083318 From dlong at openjdk.org Thu Aug 7 08:51:14 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 08:51:14 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Thu, 7 Aug 2025 08:35:33 GMT, Richard Reingruber wrote: >> It seems like relaxing the assert would allow us to silently overwrite part of a frame::top_ijava_frame_abi, which is only harmless if we are guaranteed to always treat that area as the smaller "parent" ABI past this point. Is there any way to determine if the ABI frame flavor is "top" or "parent" without adding something like a new "abi_frame_type" slot? > >> It seems like relaxing the assert would allow us to silently overwrite part of a frame::top_ijava_frame_abi, which is only harmless if we are guaranteed to always treat that area as the smaller "parent" ABI past this point. > > It is harmless. The interpreted and nmethod calling conventions only use the smaller frame::java_abi (alias for parent_ijava_frame_abi). Calling the VM or other native code requires the full ABI. > >> Is there any way to determine if the ABI frame flavor is "top" or "parent" without adding something like a new "abi_frame_type" slot? > > I would not be aware of any way to determine the ABI type easily. I'm sure many people were looking for it since bugs caused by using the wrong type are painful. Even with a dedicated slot in dbg builds it would be hard to keep the correct type since there are many places where frames get resized. Thanks @reinrich . It looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26643#issuecomment-3163150172 From duke at openjdk.org Thu Aug 7 09:49:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 7 Aug 2025 09:49:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [12.517s][info][cpu] === CPU time Statistics ============================================================= > [12.517s][info][cpu] CPUs > [12.517s][info][cpu] s % utilized > [12.517s][info][cpu] Process > [12.517s][info][cpu] Total 175.7628 100.00 14.0 > [12.517s][info][cpu] VM Thread 7.0000 3.98 0.6 > [12.517s][info][cpu] Garbage Collection 72.0000 40.96 5.8 > [12.517s][info][cpu] GC Threads 70.0000 39.83 5.6 > [12.517s][info][cpu] VM Thread 1.0000 0.57 0.1 > [12.518s][info][cpu] String Deduplication 0.0000 0.00 0.0 > [12.518s][info][cpu] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Improve robustness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/216ba811..3f552362 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=02-03 Stats: 29 lines in 3 files changed: 23 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Thu Aug 7 09:53:00 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Thu, 7 Aug 2025 09:53:00 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v3] In-Reply-To: References: Message-ID: > Hello All, > > Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. > > Thank you, > -Yuri Gaevsky > > **Correctness checks:** > hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. Yuri Gaevsky 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 master - Merge master - 8324124: RISC-V: implement _vectorizedMismatch intrinsic ------------- Changes: https://git.openjdk.org/jdk/pull/17750/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=02 Stats: 163 lines in 5 files changed: 162 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17750/head:pull/17750 PR: https://git.openjdk.org/jdk/pull/17750 From shade at openjdk.org Thu Aug 7 10:51:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 10:51:14 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Thu, 7 Aug 2025 08:28:40 GMT, David Holmes wrote: >> I am pretty sure the memory consistency here is irrelevant, given that: a) the `Thread` in question is likely already initialized for a long time, so it is unlikely we will lose anything release-acquire-wise; b) we only use these for pointer comparisons. >> >> But since we are here, and in the interest of clarity and avoiding future surprises, we can just summarily wrap these with `Atomic::release_store` and `Atomic::load_acquire` to be extra paranoidly safe. This is a failing path, so we don't care about performance, and would like to avoid a secondary crash in error handler some time in the future, if anyone reads anything from these threads. > > @shipilev The memory consistency is about seeing the writes to these fields in the thread that is signalled. acquire/release has no meaning in this context. I would not add acquire/release just in case someone in the future actually tried to follow those pointers - they are only for identifying purposes. If you are worried about that then lets go back to changing them to a value (intptr_t) so it will never be an issue. It always feels dubious to me to add fences for the single-variable "visibility" reasons. The fences order things relative to other things, not just "flush" or "make this single variable visible". But that's a theoretical quibble. A more pressing problem is reading the thread marker without any acquire/relaxed semantics; _that_ might miss updates as well. Given how messy C++ memory model is, and how data races are UB-scary there, I think we should strive to do `Atomic`-s as the matter of course for anything that transfers data between threads. Adjusting `Atomic::release_store` -> `Atomic::release_store_fence` would have satisfied both flavors of concurrency paranoia we are having, I think: it is equivalent to having a fence after the store, and it clearly makes Atomic release->acquire chain as well :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2259902716 From fgao at openjdk.org Thu Aug 7 11:46:13 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 7 Aug 2025 11:46:13 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Wed, 6 Aug 2025 09:59:11 GMT, Andrew Haley wrote: >> If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. >> >> In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: >> >> 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. >> 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. >> >> The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. > > It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. Thanks for your review @theRealAph @adinn . > It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. @theRealAph That makes a lot of sense. On Neoverse N1/N2/V1, `ADRP` and `MOVZ/MOVK` have comparable latency and throughput and share the same pipeline, so we can expect these microarchitectures to benefit from this patch. I?m planning to update the patch with an `aarch64` option to enable or disable this replacement based on the target microarchitecture. What do you think? > The solution is to make the compiler always generate the 3-instruction load when compiling in an Assembly VM and otherwise generate the 2-instruction load based on reachability i.e. AOT code won't 'benefit' from this patch but runtime generated code will (assuming it is a benefit). > So, the reachability method needs to return false if `AOTCodeCache::is_on_for_dump() returns true. @adinn thanks for pointing this out. I'll add this constraint in next commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3163784211 From dholmes at openjdk.org Thu Aug 7 12:12:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 12:12:16 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Thu, 7 Aug 2025 07:34:50 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments The updates look fine to me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3096859282 From dholmes at openjdk.org Thu Aug 7 12:09:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 12:09:16 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Thu, 7 Aug 2025 10:49:06 GMT, Aleksey Shipilev wrote: >> @shipilev The memory consistency is about seeing the writes to these fields in the thread that is signalled. acquire/release has no meaning in this context. I would not add acquire/release just in case someone in the future actually tried to follow those pointers - they are only for identifying purposes. If you are worried about that then lets go back to changing them to a value (intptr_t) so it will never be an issue. > > It always feels dubious to me to add fences for the single-variable "visibility" reasons. The fences order things relative to other things, not just "flush" or "make this single variable visible". But that's a theoretical quibble. A more pressing problem is reading the thread marker without any acquire/relaxed semantics; _that_ might miss updates as well. > > Given how messy C++ memory model is, and how data races are UB-scary there, I think we should strive to do `Atomic`-s as the matter of course for anything that transfers data between threads. Adjusting `Atomic::release_store` -> `Atomic::release_store_fence` would have satisfied both flavors of concurrency paranoia we are having, I think: it is equivalent to having a fence after the store, and it clearly makes Atomic release->acquire chain as well :) > that might miss updates as well. Might miss updates to what??? We never follow the pointer. The signalling thread doesn't doesn't do anything that the signallee has to look at, the signallee just gets the signal, checks if it was the timeout target and aborts. We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. acquire/release just says "if you see this then you must see that", it doesn't do anything to help you "see this" in the first place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2260118952 From shade at openjdk.org Thu Aug 7 12:37:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 12:37:16 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Thu, 7 Aug 2025 12:06:36 GMT, David Holmes wrote: > Might miss updates to what??? We never follow the pointer. Following the pointer is not relevant. We can miss updates to the thread pointer. Note that reader needs at least coherence to break out of potential loops like: while (get_handshake_thread() == nullptr); // burn Acquire gives that, among other things. Overlooking these properties is easy, and this is why we should be sticking to use atomics anywhere we transfer data between threads. > We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. Well, yes, this part always felt dubious to me. I am restraining myself from going into theoretical argument here, because it would take a lot of time, and would not be helpful for this work. Since no performance is on the table, we should just do the most obvious/safe thing. I believe it is a proper style to use `Atomic::load_acquire` and `Atomic::release_store_fence`, instead of one-sided `fence`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2260184827 From jbhateja at openjdk.org Thu Aug 7 12:37:17 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 7 Aug 2025 12:37:17 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: <98s1CQXUZuyBYN83myqlz01lNsEw3o7-v1DdVb3cNv4=.705802ff-2a68-4258-8f2b-fe5885ce32c5@github.com> On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Updating predicate checks Adding additional notes on implementation: A) Slice:- 1. New inline expander and C2 IR node VectorSlice for leaf level intrinsic corresponding to Vector.slice(int) 2. Other interfaces of slice APIs. - Vector.slice(int, Vector) - The second vector argument is the background vector, which replaces the zero broadcasted vector of the base version of API. - API internally calls the same intrinsic entry point as the base version. - Vector.slice(int, Vector, VectorMask) - This version of the API internally calls the above slice API with index and vector arguments, followed by an explicit blend with a broadcasted zero vector. Thus, current support implicitly covers all three 3 variants of slice APIs. B) Similar extensions to optimize Unslice with constant index:- 1. Similar to slice, unslice also has three interfaces. 2. Leaf-level interface only accepts an index argument. 3. Other variants of unslice accept unslice index, background vector, and part number. 4. We can assume the receiver vector to be sliding over two contiguously placed background vectors. 5. It's possible to implement all three variants of unslice using slice operations as follows. jshell> // Input jshell> vec vec ==> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] jshell> vec2 vec2 ==> [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160] jshell> bzvec bzvec ==> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] jshell> // Case 1: jshell> vec.unslice(4) $79 ==> [0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] jshell> bzvec.slice(vec.length() - 4, vec) $80 ==> [0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] jshell> // Case 2: jshell> vec.unslice(4, vec2, 0) $81 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] jshell> vec2.blend(vec2.slice(vec2.length() - 4, vec), VectorMask.fromLong(IntVector.SPECIES_512, ((1L << (vec.length() - 4)) - 1) << 4)) $82 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] jshell> // Case 3: jshell> vec.unslice(4, vec2, 1) $83 ==> [13, 14, 15, 16, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160] jshell> vec2.blend(vec.slice(vec.length() - 4, vec2), VectorMask.fromLong(IntVector.SPECIES_512, ((1L << 4) - 1))) $84 ==> [13, 14, 15, 16, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160] jshell> // Case 4: jshell> vec.unslice(4, vec2, 0, VectorMask.fromLong(IntVector.SPECIES_512, 0xFF)) $85 ==> [10, 20, 30, 40, 1, 2, 3, 4, 5, 6, 7, 8, 130, 140, 150, 160] jshell> // Current Java fallback implementation for this version is based on slice and unslice operations. To ease the review process, I plan to optimize the unslice API with a constant index by extending the newly added expander in a follow-up patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3163994472 From shade at openjdk.org Thu Aug 7 12:56:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 12:56:17 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Thu, 7 Aug 2025 07:34:50 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments I still think these should be wrapped with `Atomic`-s, but I don't have energy to argue in favor of them anymore. So I would defer a second review to someone else. ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3097025636 From asmehra at openjdk.org Thu Aug 7 13:29:22 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 7 Aug 2025 13:29:22 GMT Subject: Integrated: 8364128: Improve gathering of cpu feature names using stringStream In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Mon, 28 Jul 2025 18:16:16 GMT, Ashutosh Mehra wrote: > This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. > This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. > Platforms affected: x86-64 and aarch64 > Other platforms can be done if and when Leyden changes are ported to them. > > [0] https://github.com/openjdk/leyden/pull/84 This pull request has now been integrated. Changeset: bc3d8656 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/bc3d86564042208cee5119abe11905e747a5ef4c Stats: 155 lines in 9 files changed: 66 ins; 25 del; 64 mod 8364128: Improve gathering of cpu feature names using stringStream Co-authored-by: Johan Sj?len Reviewed-by: kvn, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/26515 From adinn at openjdk.org Thu Aug 7 13:57:50 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 13:57:50 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: > The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: propagate BufferBlob subclass sizes up constructor chain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26532/files - new: https://git.openjdk.org/jdk/pull/26532/files/ad4a1a27..a7925825 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26532&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26532&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26532/head:pull/26532 PR: https://git.openjdk.org/jdk/pull/26532 From adinn at openjdk.org Thu Aug 7 13:57:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 13:28:15 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn 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 JDK-8364269 > - simplify code cache API by storing adapter entry offsets in blob @vnkozlov @ashu-mehra @shipilev Ok, problem fixed, I believe, but I'm still gob-smacked that this built, ran and passed tier1 plus cds/appcds tests on Linux/aarch64 given the failure to run the exploded image on Linux/x86 and MacOS/aarch64. The problem was with the blob layout. Adding extra fields to AdapterBlob requires propagating the adjusted blob size (i.e. header_size) up the Blob constructor chain, through BufferBlob into RuntimeBlob. Which I have now done -- previously, all subclasses were sized using sizeof(BufferBlob) as none of them had extra fields. without that fix the content_start address for the Adpater blob was being reported in the tail of the blob proper which meant that in the broken builds data fields were being treated as code and we end up in hyperspace when we first use an i2c adapter to jump to Object.init(). Yet not on Linux/aarch64? Go figure. Should be ready to review now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3136689701 From asmehra at openjdk.org Thu Aug 7 13:57:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 08:34:53 GMT, Andrew Dinn wrote: > think maybe in follow-up RFE ;-) Yeah, I can take a stab at that. Meanwhile this PR is still in draft. Do you have any other changes to be made? Seems ready to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3164204093 From asmehra at openjdk.org Thu Aug 7 13:57:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 13:28:15 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn 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 JDK-8364269 > - simplify code cache API by storing adapter entry offsets in blob If the entry offsets are stored in `AdapterBlob`, `AdapterHandlerEntry` can then just store a pointer to the blob and get rid of the offsets. `SharedRuntime::generate_i2c2i_adapters` can be updated to return the AdapterBlob. And when storing the AdapterHandlerEntry, pointer to the blob can be cleared and restored in `AdapterHandlerLibrary::lookup_aot_cache`. This assumes the AdapterBlob won't be moved around in the code cache. @adinn does this make sense? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3137074976 From asmehra at openjdk.org Thu Aug 7 13:57:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: <7rfxaYIUOqeaQMjXcu6ny194UhT9mFUgb8UyGmAW8Qo=.73b7c7b3-1417-469f-9f50-672c6bd36b40@github.com> On Thu, 31 Jul 2025 08:56:00 GMT, Andrew Dinn wrote: > So, in this one case we have a Frankenstein handler assembled from 3 disparate entry points (+ nullptr) which are not derived from an associated adapter blob. That's true. I missed this special adapter handler. That special handler is a pain to accommodate. I looked at how these entry points are accessed and it seems they are mostly accessed by the routines in `Method`. So it should be feasible to handle the case of abstract methods there and get rid of this special adapter completely. @adinn wdyt? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3140236584 From adinn at openjdk.org Thu Aug 7 13:57:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 08:56:00 GMT, Andrew Dinn wrote: >> If the entry offsets are stored in `AdapterBlob`, `AdapterHandlerEntry` can then just store a pointer to the blob and get rid of the offsets. `SharedRuntime::generate_i2c2i_adapters` can be updated to return the AdapterBlob. And when storing the AdapterHandlerEntry, pointer to the blob can be cleared and restored in `AdapterHandlerLibrary::lookup_aot_cache`. >> This assumes the AdapterBlob won't be moved around in the code cache. >> @adinn does this make sense? > > @ashu-mehra >> If the entry offsets are stored in AdapterBlob, AdapterHandlerEntry can then just store a pointer to the blob and get rid of the offsets. > > I planned that originally but it doesn't work because of one special case. Method `AdapterHandlerLibrary::create_abstract_method_handler` does this: > > address wrong_method_abstract = SharedRuntime::get_handle_wrong_method_abstract_stub(); > _abstract_method_handler = AdapterHandlerLibrary::new_entry(AdapterFingerPrint::allocate(0, nullptr)); > _abstract_method_handler->set_entry_points(SharedRuntime::throw_AbstractMethodError_entry(), > wrong_method_abstract, > wrong_method_abstract, > nullptr); > > So, in this one case we have a Frankenstein handler assembled from 3 disparate entry points (+ nullptr) which are not derived from an associated adapter blob. > I looked at how these entry points are accessed and it seems they are mostly accessed by the routines in Method. So it should be feasible to handle the case of abstract methods there and get rid of this special adapter completely. @adinn wdyt? I think maybe in follow-up RFE ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3163097384 From adinn at openjdk.org Thu Aug 7 13:57:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 13:57:52 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 16:36:13 GMT, Ashutosh Mehra wrote: >> Andrew Dinn 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 JDK-8364269 >> - simplify code cache API by storing adapter entry offsets in blob > > If the entry offsets are stored in `AdapterBlob`, `AdapterHandlerEntry` can then just store a pointer to the blob and get rid of the offsets. `SharedRuntime::generate_i2c2i_adapters` can be updated to return the AdapterBlob. And when storing the AdapterHandlerEntry, pointer to the blob can be cleared and restored in `AdapterHandlerLibrary::lookup_aot_cache`. > This assumes the AdapterBlob won't be moved around in the code cache. > @adinn does this make sense? @ashu-mehra > If the entry offsets are stored in AdapterBlob, AdapterHandlerEntry can then just store a pointer to the blob and get rid of the offsets. I planned that originally but it doesn't work because of one special case. Method `AdapterHandlerLibrary::create_abstract_method_handler` does this: address wrong_method_abstract = SharedRuntime::get_handle_wrong_method_abstract_stub(); _abstract_method_handler = AdapterHandlerLibrary::new_entry(AdapterFingerPrint::allocate(0, nullptr)); _abstract_method_handler->set_entry_points(SharedRuntime::throw_AbstractMethodError_entry(), wrong_method_abstract, wrong_method_abstract, nullptr); So, in this one case we have a Frankenstein handler assembled from 3 disparate entry points (+ nullptr) which are not derived from an associated adapter blob. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3139109309 From adinn at openjdk.org Thu Aug 7 14:01:24 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 14:01:24 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 23:39:59 GMT, Vladimir Kozlov wrote: >> @vnkozlov This is still intermittent as it depends on a race. However, I ran this repeatedly with the initial and reserved cache sizes that caused the problem and with stubs logging enabled and observed execution to continue in cases where the race would previously have caused a crash. Here is the outpout from such a run. Look for the new stubs log warning message in the following output: >> >> [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version >> [0.001s][info][stubs] StubRoutines (preuniverse stubs) not generated >> [0.003s][info][stubs] StubRoutines (initial stubs) [0x0000ffff5bfb4080, 0x0000ffff5bfb6a10] used: 5388, free: 5252 >> [0.003s][info][stubs] StubRoutines (continuation stubs) [0x0000ffff5bfb7000, 0x0000ffff5bfb7a50] used: 600, free: 2040 >> [0.004s][info][stubs] StubRoutines (final stubs) [0x0000ffff5bff58c0, 0x0000ffff5c00f568] used: 11568, free: 94072 >> [0.007s][warning][codecache] CodeCache is full. Compiler has been disabled. >> [0.007s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= >> OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. >> OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= >> OpenJDK 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers >> CodeCache: size=1008Kb used=444Kb max_used=1008Kb free=563Kb >> bounds [0x0000ffff5bfb4000, 0x0000ffff5c0b0000, 0x0000ffff5c0b0000] >> total_blobs=215, nmethods=0, adapters=177, full_count=2 >> Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0 >> [0.007s][warning][stubs ] Ignoring failed allocation of blob Stub Generator compiler_blob under compiler thread >> OpenJDK 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers >> openjdk version "26-internal" 2026-03-17 >> OpenJDK Runtime Environment (build 26-internal-adhoc.adinn.JDK-8364558) >> OpenJDK 64-Bit Server VM (build 26-internal-adhoc.adinn.JDK-8364558, mixed mode, sharing) >> >> >> That ought to have fixed the problem with test StartOutput. However, after running more times I spotted this (very much less frequent) error exit: >> >> >> [adinn at clarapandy JDK-8364558]$ build/linux-aarch64-server-release/images/jdk/bin/java -XX:InitialCodeCacheSize=873K -XX:ReservedCodeCacheSize=995k -Xlog:stubs -version >> [0.00... > >> Any ideas how to proceed? Shall I still continue wiht the current patch? > > Don't worry about adapters. It is different issue which can happen at any time with very small CodeCache. > >> Also, do we need a better title for the JIRA and PR? > > Yes, please update it. May be: "Failure to generated compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache" @vnkozlov Thanks for the review. Can I get a second one? @shipilev @ashu-mehra ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3164325141 From mablakatov at openjdk.org Thu Aug 7 14:34:16 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Thu, 7 Aug 2025 14:34:16 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> Message-ID: On Mon, 4 Aug 2025 17:11:59 GMT, Evgeny Astigeevich wrote: > So you actually have: > ``` > key -> value > (trampoline_id1} -> {get_resolve_static_call_stub, {call_B_offset1, call_B_offset2}} > {trampoline_id2} -> {get_resolve_static_call_stub, {call_C_offset1, call_C_offset2, call_C_offset3}} > {trampoilen_id3} -> {some_runtime_call, {call_RT_offset1, call_RT_offset2, call_RT_offset3}} > ``` Am I right assuming you're suggesting to simplify the logic in `auto emit = [&](address dest, const CodeBuffer::Offsets &offsets)` (so the compiler doesn't need to distinguish between runtime and static calls to update the `dest` for the latter) by storing the effective `dest` addresses in the `_shared_trampoline_requests` dictionary as a part of the value? It seems to me this should work. It unifies emission logic by storing more data up front, when a shared trampoline is requested. However, I'm not sure there's a clearly better approach here. This design leads to some duplication - for instance, `trampoline_id3` should match `some_runtime_call`, if I understand correctly. Taking this into account, I'd suggest keeping the current approach and not proceeding with the alternative implementation described above. > IMO based on `SharedRuntime::resolve_helper`, we can have shared trampolines for `relocInfo::opt_virtual_call_type` and `relocInfo::virtual_call_type`. Their trampolines have the corresponding resolver set. I don't see we write anything specific to a call site into a trampoline. I can see this being implemented as a follow-up PR. For now, I suggest to establish the core mechanism by supporting static call trampolines only. If your assumption holds, a follow-up patch should turn up rather easy to implement and review. Let me know if you spot anything in the proposed design that may hinder future extensions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2260516201 From shade at openjdk.org Thu Aug 7 14:51:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 14:51:16 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache [v2] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 08:50:57 GMT, Andrew Dinn wrote: >> This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > minimize changed lines and align log messages This looks a kludge, but it is a sign that init code is a mess, not that the patch has a problem. From that vantage point, it looks reasonable. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26642#pullrequestreview-3097507955 From mhaessig at openjdk.org Thu Aug 7 14:52:48 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 7 Aug 2025 14:52:48 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v4] In-Reply-To: References: Message-ID: <7SKfaULZBs_ccRipoMMWXKUAASHIhq9um43xaxToBKE=.83db680e-fc44-4be9-8f15-0030e764b4f8@github.com> > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [ ] Github Actions > - [ ] tier1, tier2 on all platforms > - [ ] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [ ] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: ASSERT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/d50231f9..212afb4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=02-03 Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Thu Aug 7 14:52:48 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 7 Aug 2025 14:52:48 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v3] In-Reply-To: References: Message-ID: <3dpJoVc2WphcDziUngOFHUf6Th74DAizG9lIclUwPCc=.655a1ba0-9fae-495b-9431-f8a2a43c0073@github.com> On Thu, 7 Aug 2025 01:11:14 GMT, Dean Long wrote: > However, you might want to simply remove _timeout_armed, or put it inside a #ifdef ASSERT, since it is only used in an assert. Good point, thank you. v3 does just that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3164517696 From kvn at openjdk.org Thu Aug 7 15:05:19 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 7 Aug 2025 15:05:19 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: <8anPQBaOB8Rg6Y0-PWU3afCmybFFvpCpJ2zPInDF1-4=.a11f6b77-f4c6-4cb1-b9ec-99a4841ec068@github.com> On Thu, 7 Aug 2025 13:57:50 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > propagate BufferBlob subclass sizes up constructor chain Looks good. Let me test it. ------------- PR Review: https://git.openjdk.org/jdk/pull/26532#pullrequestreview-3097570748 From qamai at openjdk.org Thu Aug 7 15:38:20 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 7 Aug 2025 15:38:20 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Updating predicate checks src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7138: > 7136: // res[255:128] = {src2[127:0] , src1[255:128]} >> SHIFT > 7137: vperm2i128(xtmp, src1, src2, 0x21); > 7138: vpalignr(dst, xtmp, src1, origin, Assembler::AVX_256bit); If the slice amount is exactly 16, I think the `vpalignr` is unnecessary. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7159: > 7157: void C2_MacroAssembler::vector_slice_64B_op(XMMRegister dst, XMMRegister src1, XMMRegister src2, > 7158: XMMRegister xtmp, int origin, int vlen_enc) { > 7159: if (origin <= 16) { If `origin` is divisible by `4`, then a single `valignd` is enough, am I right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260699543 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260702518 From eastigeevich at openjdk.org Thu Aug 7 15:55:19 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 7 Aug 2025 15:55:19 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> Message-ID: <-2nFSgxvTQDnTjG1yW-Lq1zfj5plegc9RCcplg3SWKs=.fb5feaf6-10ab-413e-bf64-eef5f3f5e8c2@github.com> On Thu, 7 Aug 2025 14:31:09 GMT, Mikhail Ablakatov wrote: > Am I right assuming you're suggesting to simplify ... Yes. > However, I'm not sure there's a clearly better approach here. This design leads to some duplication - for instance, trampoline_id3 should match some_runtime_call, if I understand correctly. There should not be any duplication. Why do you think so? Let's revisit the example. This time `A` has three calls of `Arrays.hashCode`. For large arrays we will use the stub `StubRoutines::aarch64::large_arrays_hashcode`. Your implementation: key -> value {B} -> {relocInfo::static_call_type, {call_B_offset1, call_B_offset2}} {C} -> {relocInfo::static_call_type, {call_C_offset1, call_C_offset2, call_C_offset3}} {StubRoutines::aarch64::large_arrays_hashcode} -> {relocInfo::runtime_call_type, {call_RT_offset1, call_RT_offset2, call_RT_offset3}} Mine proposal: key -> value (B} -> {get_resolve_static_call_stub, {call_B_offset1, call_B_offset2}} {C} -> {get_resolve_static_call_stub, {call_C_offset1, call_C_offset2, call_C_offset3}} {StubRoutines::aarch64::large_arrays_hashcode} -> {StubRoutines::aarch64::large_arrays_hashcode, {call_RT_offset1, call_RT_offset2, call_RT_offset3}} I don't see any duplication. > Taking this into account, I'd suggest keeping the current approach and not proceeding with the alternative implementation described above. I dont understand what you mean "the current approach". Do you mean using `Pair` and checking `relocInfo::relocType`? `Pair` obfuscates what is stored inside it. IMO this reduces readability of the program. `SharedTrampolineRequest` clearly states its purpose and the purpose of its members. > I can see this being implemented as a follow-up PR. I am ok with this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2260752243 From aph at openjdk.org Thu Aug 7 16:20:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 7 Aug 2025 16:20:14 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Wed, 6 Aug 2025 09:59:11 GMT, Andrew Haley wrote: >> If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. >> >> In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: >> >> 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. >> 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. >> >> The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. > > It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. > Thanks for your review @theRealAph @adinn . > > > It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. > > @theRealAph That makes a lot of sense. On Neoverse N1/N2/V1, `ADRP` and `MOVZ/MOVK` have comparable latency and throughput and share the same pipeline, so we can expect these microarchitectures to benefit from this patch. I?m planning to update the patch with an `aarch64` option to enable or disable this replacement based on the target microarchitecture. What do you think? No, the difference isn't worth any added complexity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3164894932 From adinn at openjdk.org Thu Aug 7 16:26:22 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 16:26:22 GMT Subject: RFR: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 14:49:06 GMT, Aleksey Shipilev wrote: > This looks a kludge, but it is a sign that init code is a mess, not that the patch has a problem. From that vantage point, it looks reasonable. Yes, it's far from perfect and still leaves us with the possibility of a VM exit from a racing C1 thread that wants an adapter. But it is undoubtedly less bad than the status quo. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26642#issuecomment-3164912193 From adinn at openjdk.org Thu Aug 7 16:26:23 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 7 Aug 2025 16:26:23 GMT Subject: Integrated: 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 13:21:01 GMT, Andrew Dinn wrote: > This PR avoids bringing down the VM when a code cache allocation for the stubgen compiler blob is requested by the compiler thread and fails because the code cache is full. Instead the VM is allowed to carry on with the compiler disabled. This pull request has now been integrated. Changeset: 90ea42f7 Author: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/90ea42f716770fd567e4e3b3bf7466fa93964f07 Stats: 17 lines in 2 files changed: 17 ins; 0 del; 0 mod 8364558: Failure to generate compiler stubs from compiler thread should not crash VM when compilation disabled due to full CodeCache Reviewed-by: kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/26642 From fgao at openjdk.org Thu Aug 7 16:47:19 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 7 Aug 2025 16:47:19 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Wed, 6 Aug 2025 09:30:07 GMT, Andrew Haley wrote: >>> Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. >> >> I thought other threads are modifying the data, which is the reason why we needed the ISB. > >> > Unaligned memory access may be non-atomic, although in this case, other threads aren?t modifying the data. >> >> I thought other threads are modifying the data, which is the reason why we needed the ISB. > > Yes, exactly. Other threads are executing this nmethod while we are modifying its static call stub. > > We hold the lock while we're doing this, so any thread racing with us to _modify_ the call stub would be blocked. However, another thread could execute the call we just patched but not fully observe the changes we made to the stub, which is why we need the ISB. > > We have a similar situation with this PR, but with data rather than instruction memory. We need to make sure that any racing thread observes changes to the stub before it observes the patched call to the stub. There is no ordering between instruction and data memory, which is why the current stub uses only instruction memory, keeping everything right. The ISB ensures that the executing thread observes the changed stub: there is a happens-before from the `ICache::invalidate_range` after patching the stub (but before patching the call) to the `isb` at the start of the stub. > > For this PR to be correctly synchronized, we'd need a similar happens-before from patching the constants used in the stub to executing the stub. I can think of a way to do that, but it's fiddly and may not be worth it. Thanks for your reviewing @theRealAph @adinn @dean-long . Also thanks a lot for the explanation ? it?s really helpful and clarified why the `isb` is necessary in the current implementation. This patch is inspired by the trampoline stub design, and I?m trying to understand why that approach works as it does. Happy to be corrected if I?ve got anything wrong. Initially, we generate a trampoline stub to redirect control flow from the caller to the static call resolver. Once the static stub is patched, we also update the trampoline stub, though in some cases the call may bypass the trampoline entirely and jump directly from the caller to the static stub. When the callee is eventually compiled, we reset the trampoline to once again direct the call back to the resolver. After resolution completes, we then update the trampoline to point to the compiled callee. My question is: Why isn?t any explicit memory synchronization required before executing the trampoline stub? How do we ensure that any data loaded by the trampoline stub is fully synchronized across multiple threads? I?d appreciate any insights. Thank you very much! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2260874295 From aph at openjdk.org Thu Aug 7 16:52:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 7 Aug 2025 16:52:14 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Thu, 7 Aug 2025 16:17:09 GMT, Andrew Haley wrote: > Thanks for your review @theRealAph @adinn . > > > It's certainly smaller, but whether it's more efficient is dependent on the circumstances. For example, on Firestorm we can do two ADRPs per cycle, but eight MOVZ/MOVKs. > > @theRealAph That makes a lot of sense. On Neoverse N1/N2/V1, `ADRP` and `MOVZ/MOVK` have comparable latency and throughput and share the same pipeline, I've done some modelling using llvm-mca and it looks like `adrp; add` is a win on recent Apple processors as well as on Arm processors, so go ahead with making this the default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3164998150 From duke at openjdk.org Thu Aug 7 16:55:48 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 7 Aug 2025 16:55:48 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency Message-ID: In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. linux-x64 GCC master real 81.39 user 3352.15 sys 287.49 JDK-8365053 real 81.94 user 3030.24 sys 295.82 linux-x64 Clang master real 43.44 user 2082.93 sys 130.70 JDK-8365053 real 38.44 user 1723.80 sys 117.68 linux-aarch64 GCC master real 1188.08 user 2015.22 sys 175.53 JDK-8365053 real 1019.85 user 1667.45 sys 171.86 ------------- Commit messages: - refresh Changes: https://git.openjdk.org/jdk/pull/26681/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365053 Stats: 41 lines in 1 file changed: 1 ins; 28 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From aph at openjdk.org Thu Aug 7 17:04:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 7 Aug 2025 17:04:17 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Thu, 7 Aug 2025 16:44:11 GMT, Fei Gao wrote: > My question is: Why isn?t any explicit memory synchronization required before executing the trampoline stub? How do we ensure that any data loaded by the trampoline stub is fully synchronized across multiple threads? It isn't. Other threads may call the static call resolver multiple times even after it's been patched. The difference is that for a trampoline call there is only one address to load so it can be patched atomically by a single store, and it doesn't matter if the address is stale. We could read/write the { code; method } pair inside a critical section, thus guaranteeing that the operation is correctly synchronized. It might well be a bit faster, but it would be fiddly, especially on Apple silicon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2260916337 From shade at openjdk.org Thu Aug 7 17:06:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 17:06:16 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 13:57:50 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > propagate BufferBlob subclass sizes up constructor chain This looks fine to me. API got indeed simpler. src/hotspot/share/code/codeBlob.hpp line 410: > 408: static const int ENTRY_COUNT = 4; > 409: private: > 410: AdapterBlob(int size, CodeBuffer* cb, int entry_offset[ENTRY_COUNT]); I was today years old when I realized you can pass const-sized arrays as arguments. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26532#pullrequestreview-3097985317 PR Review Comment: https://git.openjdk.org/jdk/pull/26532#discussion_r2260891380 From shade at openjdk.org Thu Aug 7 17:10:15 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 17:10:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi wrote: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 src/hotspot/share/precompiled/precompiled.hpp line 29: > 27: > 28: // These header files are included in at least 130 C++ files, as of > 29: // measurements made in November 2018. This list excludes files named Keep this comment, just update the date (seeing how threshold is the same?). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2260927049 From shade at openjdk.org Thu Aug 7 17:35:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 17:35:17 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi wrote: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils. It would be nice if the output of that script could be simply piped into `precompiled.hpp`, so we can use it later without extra work. We can, technically, hook it up a similar way SortIncludes.java is currently done, but I think it is unnecessary at this point. In a perfect world we would not be needing precompiled headers. In less ideal world, having a jtreg test that warns us that a new popular header appeared, or that older header is not as popular anymore, would be handy. Again, this is something out of scope for this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165135998 From shade at openjdk.org Thu Aug 7 18:03:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Aug 2025 18:03:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi wrote: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 On my M1, with some AV software that always get in the way, I am seeing 15% faster build, which saves about half a minute. This is great! CONF=macosx-aarch64-server-fastdebug LOG=info make hotspot 1245.30s user 230.07s system 640% cpu 3:50.49 total CONF=macosx-aarch64-server-fastdebug LOG=info make hotspot 1064.59s user 203.24s system 618% cpu 3:20.09 total ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165209211 From duke at openjdk.org Thu Aug 7 18:51:04 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 7 Aug 2025 18:51:04 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v2] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: keep comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/9e0cb7e8..a75494f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Thu Aug 7 18:51:05 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 7 Aug 2025 18:51:05 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 17:07:17 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> keep comment > > src/hotspot/share/precompiled/precompiled.hpp line 29: > >> 27: >> 28: // These header files are included in at least 130 C++ files, as of >> 29: // measurements made in November 2018. This list excludes files named > > Keep this comment, just update the date (seeing how threshold is the same?). The part about `.inline.hpp` is not relevant anymore though, I've seen significant improvements after including a couple of them. I'll keep the rest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261151719 From duke at openjdk.org Thu Aug 7 18:51:06 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 7 Aug 2025 18:51:06 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 18:44:29 GMT, Francesco Andreuzzi wrote: >> src/hotspot/share/precompiled/precompiled.hpp line 29: >> >>> 27: >>> 28: // These header files are included in at least 130 C++ files, as of >>> 29: // measurements made in November 2018. This list excludes files named >> >> Keep this comment, just update the date (seeing how threshold is the same?). > > The part about `.inline.hpp` is not relevant anymore though, I've seen significant improvements after including a couple of them. I'll keep the rest. a75494f10f47a032f01e7e967c3b937166d8780d ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261153641 From dlong at openjdk.org Thu Aug 7 18:59:36 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 7 Aug 2025 18:59:36 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v4] In-Reply-To: <7SKfaULZBs_ccRipoMMWXKUAASHIhq9um43xaxToBKE=.83db680e-fc44-4be9-8f15-0030e764b4f8@github.com> References: <7SKfaULZBs_ccRipoMMWXKUAASHIhq9um43xaxToBKE=.83db680e-fc44-4be9-8f15-0030e764b4f8@github.com> Message-ID: On Thu, 7 Aug 2025 14:52:48 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [ ] Github Actions >> - [ ] tier1, tier2 on all platforms >> - [ ] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [ ] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > ASSERT Thinking about _timeout_armed a little more, the fact the the signal handler received TIMEOUT_SIGNAL should be enough. The value of _timeout_armed should be redundant, and your assert could be changed to: assert(false, "compile task timed out"); and _timeout_armed could be removed. It's just an inexact mirror of the timer state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3165377812 From asmehra at openjdk.org Thu Aug 7 19:04:13 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 7 Aug 2025 19:04:13 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 13:57:50 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > propagate BufferBlob subclass sizes up constructor chain lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/26532#pullrequestreview-3098416533 From erikj at openjdk.org Thu Aug 7 19:54:13 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 7 Aug 2025 19:54:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v2] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 18:51:04 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > keep comment I tried it on Windows. Build time for hotspot was basically the same before and after, so no regression at least. So I'm fine with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165525209 From duke at openjdk.org Thu Aug 7 20:00:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 7 Aug 2025 20:00:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 17:32:35 GMT, Aleksey Shipilev wrote: > Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils. It would be nice if the output of that script could be simply piped into `precompiled.hpp`, so we can use it later without extra work. > > We can, technically, hook it up a similar way SortIncludes.java is currently done, but I think it is unnecessary at this point. In a perfect world we would not be needing precompiled headers. In less ideal world, having a jtreg test that warns us that a new popular header appeared, or that older header is not as popular anymore, would be handy. Again, this is something out of scope for this PR. I'll add the generation script, it looks like something that could be useful at some point in the future. I think there should be a human curator though, because the process is not completely automatic. For example, when the threshold is set to 50 I get this compilation error: /jdk/src/hotspot/share/compiler/compilerEvent.cpp:59:36: error: redefinition of 'phase_names' with a different type: 'GrowableArray *' vs 'const char *[100]' static GrowableArray* phase_names = nullptr; ^ /jdk/src/hotspot/share/opto/phasetype.hpp:147:20: note: previous definition is here static const char* phase_names[] = { It could happen with any threshold, even 130 as the codebase evolves. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165535039 From kvn at openjdk.org Thu Aug 7 21:54:12 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 7 Aug 2025 21:54:12 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 13:57:50 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > propagate BufferBlob subclass sizes up constructor chain My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26532#pullrequestreview-3098867813 From dholmes at openjdk.org Thu Aug 7 22:24:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 22:24:11 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Thu, 7 Aug 2025 12:34:21 GMT, Aleksey Shipilev wrote: >>> that might miss updates as well. >> >> Might miss updates to what??? We never follow the pointer. The signalling thread doesn't doesn't do anything that the signallee has to look at, the signallee just gets the signal, checks if it was the timeout target and aborts. >> >> We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. acquire/release just says "if you see this then you must see that", it doesn't do anything to help you "see this" in the first place. > >> Might miss updates to what??? We never follow the pointer. > > Following the pointer is not relevant. We can miss updates to the thread pointer. Note that reader needs at least coherence to break out of potential loops like: > > > while (get_handshake_thread() == nullptr); // burn > > > Acquire gives that, among other things. Overlooking these properties is easy, and this is why we should be sticking to use atomics anywhere we transfer data between threads. > >> We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. > > Well, yes, this part always felt dubious to me. I am restraining myself from going into theoretical argument here, because it would take a lot of time, and would not be helpful for this work. > > Since no performance is on the table, we should just do the most obvious/safe thing. I believe it is a proper style to use `Atomic::load_acquire` and `Atomic::release_store_fence`, instead of one-sided `fence`. Blindly applying acquire/release is not at all the obvious/safe thing to me. I do not understand your reference to `get_handshake_thread()` above - this is not about handshakes. Here we have a very simple situation: - Thread 1: set field; signal target thread - Target thread: receive signal; read field All we need to "transfer" here is the value of "field". acquire/release does not achieve that it only says what happens _if_ you see the new value of field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2261569500 From dholmes at openjdk.org Thu Aug 7 22:29:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 22:29:13 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: On Thu, 7 Aug 2025 22:21:29 GMT, David Holmes wrote: >>> Might miss updates to what??? We never follow the pointer. >> >> Following the pointer is not relevant. We can miss updates to the thread pointer. Note that reader needs at least coherence to break out of potential loops like: >> >> >> while (get_handshake_thread() == nullptr); // burn >> >> >> Acquire gives that, among other things. Overlooking these properties is easy, and this is why we should be sticking to use atomics anywhere we transfer data between threads. >> >>> We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. >> >> Well, yes, this part always felt dubious to me. I am restraining myself from going into theoretical argument here, because it would take a lot of time, and would not be helpful for this work. >> >> Since no performance is on the table, we should just do the most obvious/safe thing. I believe it is a proper style to use `Atomic::load_acquire` and `Atomic::release_store_fence`, instead of one-sided `fence`. > > Blindly applying acquire/release is not at all the obvious/safe thing to me. I do not understand your reference to `get_handshake_thread()` above - this is not about handshakes. Here we have a very simple situation: > - Thread 1: set field; signal target thread > - Target thread: receive signal; read field > All we need to "transfer" here is the value of "field". acquire/release does not achieve that it only says what happens _if_ you see the new value of field. Though as I said elsewhere, although the spec does not require it, I would be very surprised if signal raising did not, in practice, "happen-before" signal delivery. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2261575130 From dholmes at openjdk.org Thu Aug 7 23:40:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Aug 2025 23:40:15 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> Message-ID: <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0OVPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> On Thu, 7 Aug 2025 22:26:49 GMT, David Holmes wrote: >> Blindly applying acquire/release is not at all the obvious/safe thing to me. I do not understand your reference to `get_handshake_thread()` above - this is not about handshakes. Here we have a very simple situation: >> - Thread 1: set field; signal target thread >> - Target thread: receive signal; read field >> All we need to "transfer" here is the value of "field". acquire/release does not achieve that it only says what happens _if_ you see the new value of field. > > Though as I said elsewhere, although the spec does not require it, I would be very surprised if signal raising did not, in practice, "happen-before" signal delivery. > acquire/release does not achieve that it only says what happens if you see the new value of field Note I am describing the semantic model for acquire/release in a general sense - as we describe in orderAccess.hpp. An actual implementation may ensure memory operations actually complete before the `release` in a similar way to a `fence` (e.g. X86 `mfence`). A "fence" may only ensure ordering in its abstract description but that suffices, as the store to the field must happen before any of the stores related to raising the signal, which must happen before the signal can actually be delivered, which happens before we load the field. Hence by transitivity we are guaranteed to see the fields written value, by using the fence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2261646124 From duke at openjdk.org Fri Aug 8 00:43:27 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 00:43:27 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: script. update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/a75494f1..d6cd068b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=01-02 Stats: 167 lines in 3 files changed: 167 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From jjiang at openjdk.org Fri Aug 8 02:31:15 2025 From: jjiang at openjdk.org (John Jiang) Date: Fri, 8 Aug 2025 02:31:15 GMT Subject: Integrated: 8364597: Replace THL A29 Limited with Tencent In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang wrote: > `THL A29 Limited` was a `Tencent` company but was dissolved. > So, the copyright notes just use `Tencent` directly. This pull request has now been integrated. Changeset: 4c9eadda Author: John Jiang URL: https://git.openjdk.org/jdk/commit/4c9eaddaef83c6ba30e27ae3e0d16caeeec206cb Stats: 67 lines in 58 files changed: 0 ins; 9 del; 58 mod 8364597: Replace THL A29 Limited with Tencent Reviewed-by: jiefu ------------- PR: https://git.openjdk.org/jdk/pull/26614 From qamai at openjdk.org Fri Aug 8 03:10:12 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 03:10:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: Message-ID: <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com> On Fri, 8 Aug 2025 00:43:27 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > script. update src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 73: > 71: paths.filter(Files::isRegularFile) > 72: .filter(path -> { > 73: String name = path.getFileName().toString(); IIUC this means that we count the number of cpp or hpp files that directly include a file, but should we count the number of cpp file that directly or transitively include a file instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261838083 From dholmes at openjdk.org Fri Aug 8 04:39:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Aug 2025 04:39:11 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 16:52:23 GMT, Patricio Chilano Mateo wrote: > Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. > > Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. > > The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. > > Thanks, > Patricio Seems reasonable - though I dislike that we have to add ASAN and CPU specific code this way. A couple of minor nits. Thanks. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 106: > 104: // For a compiled frame we need to re-read fp out of the frame because it may be an > 105: // oop and we might have had a safepoint in finalize_freeze, after constructing f. > 106: // For stub/native frames the value is not used while freezed, and will be constructed Suggestion: // For stub/native frames the value is not used while frozen, and will be constructed src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 103: > 101: // For a compiled frame we need to re-read fp out of the frame because it may be an > 102: // oop and we might have had a safepoint in finalize_freeze, after constructing f. > 103: // For stub/native frames the value is not used while freezed, and will be constructed Suggestion: // For stub/native frames the value is not used while frozen, and will be constructed src/hotspot/share/runtime/continuationFreezeThaw.cpp line 796: > 794: // frame (lowest address). ASan treats this memory access in the callee as > 795: // an overflow access to one of the locals stored in that frame. For these > 796: // preemption case we don't need to read these words anyways so we avoid it. Suggestion: // preemption cases we don't need to read these words anyways so we avoid it. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 797: > 795: // an overflow access to one of the locals stored in that frame. For these > 796: // preemption case we don't need to read these words anyways so we avoid it. > 797: adjust -= _preempt ? frame::metadata_words_at_bottom : 0; Suggestion: if (_preempt) { adjust = 0; } ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26660#pullrequestreview-3099411836 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2261898883 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2261903871 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2261905677 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2261908614 From dholmes at openjdk.org Fri Aug 8 04:57:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Aug 2025 04:57:16 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi wrote: > For example, when the threshold is set to 50 I get this compilation error: How can we possibly get a compilation error when everything should build with PCH disabled? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3166572069 From kbarrett at openjdk.org Fri Aug 8 06:36:19 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Aug 2025 06:36:19 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 00:43:27 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > script. update Changes requested by kbarrett (Reviewer). src/hotspot/share/precompiled/precompiled.hpp line 29: > 27: > 28: // These header files are included in at least 130 C++ files, as of > 29: // measurements made in August 2025. I don't think there's anything particularly special about the number 130. Another thing to consider when a header file has a high include count is whether it's being overincluded. We've had lots of those, and some folks occasionally try to poke at that problem. Some of the removals here look like they might be a result of such efforts. Still another thing to consider is the cost of inclusion. Some files may just be a lot more expensive to process and benefit more for being precompiled. File size can be an indicator, but there are others. Unfortunately, I don't know of a good way to measure this. src/hotspot/share/precompiled/precompiled.hpp line 70: > 68: #include "utilities/ticks.hpp" > 69: > 70: #ifdef TARGET_COMPILER_visCPP All of the reported testing was on Linux. These were included specifically because measurements said their inclusion here was beneficial. And my recollection from previous discussions is that Visual Studio may be the compiler where precompiled headers are most beneficial. src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70: > 68: // Count inclusion times for each header > 69: Map occurrences = new HashMap<>(); > 70: try (Stream paths = Files.walk(hotspotPath)) { I think walking the source tree is the wrong approach to gathering the data about include counts. I think better is to do a build and then look at the files /hotspot/variant-server/libjvm/objs/*.d. From that one can build a completely accurate count of the transitive inclusions. ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3099600154 PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262050884 PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262055386 PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262041141 From kbarrett at openjdk.org Fri Aug 8 06:42:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Aug 2025 06:42:13 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 02:54:22 GMT, Kim Barrett wrote: >> Thanks for implementing nice code for PPC64! I appreciate it! The shared code and the other platforms look fine, too. >> Maybe atomic bitwise operations could be used, but I'm happy with your current solution. > >> Thanks @TheRealMDoerr . I didn't even consider atomic bitwise operations, but that's a good idea. I'm not in a hurry to push this, so if you could provide an atomic bitwise patch for ppc64, I would be happy to include it. In the mean time, I'm still investigating the ZGC regression. If I can figure it out, I might want to include a fix for ZGC in this PR as well. > > Not a review, just a drive-by comment. > We've had Atomic bitops for a while now. > Atomic::fetch_then_{and,or,xor}(ptr, bits [, order]) > Atomic::{and,or,xor}_then_fetch(ptr, bits [, order]) > They haven't been optimized for most (any?) platforms, being based on cmpxchg. > (See all the "Specialize atomic bitset functions for ..." related to > https://bugs.openjdk.org/browse/JDK-8293117.) > Thanks @kimbarrett. I see that the Atomic::fetch_then_XXX() implementation is very similar to what I came up with. The operation I'm doing is sometimes setting a single bit, so fetch_then_or() could be used, but sometimes the operation is setting the other 31 bits, so a new fetch_then_set_with_mask() would need to be added. Oh, yes, I see. This code is setting a bitfield. Yeah, that's not one of the logical atomic primitives, and seems unlikely to be added unless more use-cases can be found. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3166743405 From fgao at openjdk.org Fri Aug 8 08:11:14 2025 From: fgao at openjdk.org (Fei Gao) Date: Fri, 8 Aug 2025 08:11:14 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Thu, 7 Aug 2025 16:49:31 GMT, Andrew Haley wrote: > > I've done some modelling using llvm-mca and it looks like `adrp; add` is a win on recent Apple processors as well as on Arm processors, so go ahead with making this the default. Thanks for testing that ? really great to hear! I?ll update the patch with a constraint for AOT cache shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3166943966 From duke at openjdk.org Fri Aug 8 08:24:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 08:24:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com> References: <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com> Message-ID: On Fri, 8 Aug 2025 03:07:58 GMT, Quan Anh Mai wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> script. update > > src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 73: > >> 71: paths.filter(Files::isRegularFile) >> 72: .filter(path -> { >> 73: String name = path.getFileName().toString(); > > IIUC this means that we count the number of cpp or hpp files that directly include a file, but should we count the number of cpp file that directly or transitively include a file instead? That would be a much more sensitive number indeed. I'll look into the solution proposed below by @kimbarrett. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262278283 From shade at openjdk.org Fri Aug 8 08:40:11 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Aug 2025 08:40:11 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0OVPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0O VPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> Message-ID: <_ESoV2tghLGuqSsmR8jYrdpoCpNpipdxtq878TT3vIc=.c21e74c2-2044-4b92-96b6-72e873302091@github.com> On Thu, 7 Aug 2025 23:37:44 GMT, David Holmes wrote: >> Though as I said elsewhere, although the spec does not require it, I would be very surprised if signal raising did not, in practice, "happen-before" signal delivery. > >> acquire/release does not achieve that it only says what happens if you see the new value of field > > Note I am describing the semantic model for acquire/release in a general sense - as we describe in orderAccess.hpp. An actual implementation may ensure memory operations actually complete before the `release` in a similar way to a `fence` (e.g. X86 `mfence`). > > A "fence" may only ensure ordering in its abstract description but that suffices, as the store to the field must happen before any of the stores related to raising the signal, which must happen before the signal can actually be delivered, which happens before we load the field. Hence by transitivity we are guaranteed to see the fields written value, by using the fence. As I said before, getting too deep into theory and how this case might be special is counter-productive here. Honestly, I do _not_ understand the aversion to the idea that a field that is accessed by several threads should be nominally wrapped with `Atomic`. (Also note that some fields in `VMError` already do this.) Whatever the current situation is, that might allow for a low-level naked fence, the situation can change. I strongly believe we should be erring on the side of caution and future-proofness, unless there are other concerns on the table, like performance. There is no other concerns here, AFAICS. If you want a `fence` after the store for whatever reason, that's fine, there is `Atomic::release_store_fence` that gives it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2262314155 From aph at openjdk.org Fri Aug 8 08:57:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 8 Aug 2025 08:57:10 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Fri, 8 Aug 2025 08:08:36 GMT, Fei Gao wrote: > > I've done some modelling using llvm-mca and it looks like `adrp; add` is a win on recent Apple processors as well as on Arm processors, so go ahead with making this the default. > > Thanks for testing that ? really great to hear! I?ll update the patch with a constraint for AOT cache shortly. Correction: I'm afraid that the llvm-mca results are nonsense. It says that this sequence movk w0, #0x1234, lsl 16 movk w1, #0x1234, lsl 16 movk w2, #0x1234, lsl 16 movk w3, #0x1234, lsl 16 movk w4, #0x1234, lsl 16 movk w5, #0x1234, lsl 16 movk w6, #0x1234, lsl 16 movk w7, #0x1234, lsl 16 takes 2 clock cycles on Apple M1, but Dougall Johnson measured real hardware executing this at 1 clock cycle. I'm not going to believe any more without numbers we can trust. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3167078839 From adinn at openjdk.org Fri Aug 8 09:12:15 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 8 Aug 2025 09:12:15 GMT Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v3] In-Reply-To: References: Message-ID: <3Ev99DymxsVlMZlKiLHWYChb2Lg74ryHHHGdQtfuK98=.4407433b-5f84-45e3-a7f2-34094ea1280b@github.com> On Thu, 7 Aug 2025 13:57:50 GMT, Andrew Dinn wrote: >> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > propagate BufferBlob subclass sizes up constructor chain Thanks all for the reviews. Integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3167124598 From adinn at openjdk.org Fri Aug 8 09:15:22 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 8 Aug 2025 09:15:22 GMT Subject: Integrated: 8364269: Simplify code cache API by storing adapter entry offsets in blob In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 12:15:48 GMT, Andrew Dinn wrote: > The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs. This pull request has now been integrated. Changeset: 241808e1 Author: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/241808e13fb032b0ec192e0b7ff94891a653ac94 Stats: 102 lines in 5 files changed: 30 ins; 42 del; 30 mod 8364269: Simplify code cache API by storing adapter entry offsets in blob Reviewed-by: kvn, shade, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/26532 From duke at openjdk.org Fri Aug 8 10:30:12 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 10:30:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 04:54:32 GMT, David Holmes wrote: > > For example, when the threshold is set to 50 I get this compilation error: > > How can we possibly get a compilation error when everything should build with PCH disabled? Possibly some includes are inside namespaces or classes? I would have to check on this though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3167372745 From mhaessig at openjdk.org Fri Aug 8 10:51:42 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 8 Aug 2025 10:51:42 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v5] In-Reply-To: References: Message-ID: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [ ] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [ ] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into JDK-8308094-timeout - Rename _timer - remove _timeout_armed - ASSERT - Merge branch 'master' into JDK-8308094-timeout - No acquire release semantics - Factor Linux specific timeout functionality out of share/ - Move timeout disarm above if - Merge branch 'master' into JDK-8308094-timeout - Fix SIGALRM test - ... and 1 more: https://git.openjdk.org/jdk/compare/80c8bd84...8bb5eb7a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/212afb4d..8bb5eb7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=03-04 Stats: 4769 lines in 139 files changed: 3372 ins; 855 del; 542 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From duke at openjdk.org Fri Aug 8 11:15:46 2025 From: duke at openjdk.org (Ruben) Date: Fri, 8 Aug 2025 11:15:46 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 Message-ID: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. ------------- Commit messages: - 8365047: Remove exception handler stub code in C2 Changes: https://git.openjdk.org/jdk/pull/26678/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365047 Stats: 204 lines in 16 files changed: 19 ins; 180 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From duke at openjdk.org Fri Aug 8 11:27:53 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 11:27:53 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v4] In-Reply-To: References: Message-ID: <9F_mpCqxuTVGhOfdZn2M32xj7XEfOHlHg-m7yQB6c-A=.4ef5971f-fac0-442f-ac1e-ca3f6fefe922@github.com> > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: use .d files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/d6cd068b..5672a1b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=02-03 Stats: 55 lines in 2 files changed: 16 ins; 18 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 11:36:04 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 11:36:04 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v5] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - nl - refresh. not needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/5672a1b1..5c8179d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=03-04 Stats: 416 lines in 2 files changed: 408 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 11:39:12 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 11:39:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: Message-ID: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> On Fri, 8 Aug 2025 06:23:43 GMT, Kim Barrett wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> script. update > > src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70: > >> 68: // Count inclusion times for each header >> 69: Map occurrences = new HashMap<>(); >> 70: try (Stream paths = Files.walk(hotspotPath)) { > > I think walking the source tree is the wrong approach to gathering the data > about include counts. I think better is to do a build and then look at the > files /hotspot/variant-server/libjvm/objs/*.d. From that one can build > a completely accurate count of the transitive inclusions. I followed this hint, the latest version of the script checks the `.d` files. Two observations: - The magic number is now `2460` (more includes are taken into account, which makes sense) - There is much less wiggle room, 2461 includes nothing, 2459 includes too much - Runtime does not seem to be affected negatively or positively If anybody is interested, this file contains the inclusion count for each source file: [inclusions_count.txt](https://github.com/user-attachments/files/21682561/inclusions_count.txt) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262707516 From aph at openjdk.org Fri Aug 8 11:40:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 8 Aug 2025 11:40:13 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> On Fri, 8 Aug 2025 08:55:03 GMT, Andrew Haley wrote: > I'm not going to believe any more without numbers we can trust. Sorry, it's 6 movz/movk per cycle, which I just confirmed by measuring it myself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3167573763 From dholmes at openjdk.org Fri Aug 8 12:24:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Aug 2025 12:24:10 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: <_ESoV2tghLGuqSsmR8jYrdpoCpNpipdxtq878TT3vIc=.c21e74c2-2044-4b92-96b6-72e873302091@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0O VPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> <_ESoV2tghLGuqSsmR8jYrdpoCpNpipdxtq878TT3vIc=.c21e74c2-2044-4b92-96b6-72e873302091@github.com> Message-ID: On Fri, 8 Aug 2025 08:37:13 GMT, Aleksey Shipilev wrote: >>> acquire/release does not achieve that it only says what happens if you see the new value of field >> >> Note I am describing the semantic model for acquire/release in a general sense - as we describe in orderAccess.hpp. An actual implementation may ensure memory operations actually complete before the `release` in a similar way to a `fence` (e.g. X86 `mfence`). >> >> A "fence" may only ensure ordering in its abstract description but that suffices, as the store to the field must happen before any of the stores related to raising the signal, which must happen before the signal can actually be delivered, which happens before we load the field. Hence by transitivity we are guaranteed to see the fields written value, by using the fence. > > As I said before, getting too deep into theory and how this case might be special is counter-productive here. > > Honestly, I do _not_ understand the aversion to the idea that a field that is accessed by several threads should be nominally wrapped with `Atomic`. (Also note that some fields in `VMError` already do this.) Whatever the current situation is, that might allow for a low-level naked fence, the situation can change. I strongly believe we should be erring on the side of caution and future-proofness, unless there are other concerns on the table, like performance. There is no other concerns here, AFAICS. If you want a `fence` after the store for whatever reason, that's fine, there is `Atomic::release_store_fence` that gives it. It is not the "atomic" that is the issue it is the inappropriate and unnecessary use of acquire/release semantics. When people look at this code later they will wonder what it is that we are trying to coordinate - when the answer is "nothing". That just causes confusion. Synchronization and concurrency is hard enough with obfuscating things by sprinkling the wrong kind of synchronization constructs around "just to be safe". That isn't future-proofing things. If in the future we have different synchronization requirements then those requirements need to be understood and the correct code inserted. Maybe in the future we will need a mutex - who knows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2262830006 From duke at openjdk.org Fri Aug 8 12:25:30 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Fri, 8 Aug 2025 12:25:30 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v4] In-Reply-To: References: Message-ID: > Hello All, > > Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. > > Thank you, > -Yuri Gaevsky > > **Correctness checks:** > hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: removed obsolete code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17750/files - new: https://git.openjdk.org/jdk/pull/17750/files/0e1d7527..cfed55df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17750/head:pull/17750 PR: https://git.openjdk.org/jdk/pull/17750 From kbarrett at openjdk.org Fri Aug 8 12:45:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Aug 2025 12:45:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> Message-ID: <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> On Fri, 8 Aug 2025 11:36:04 GMT, Francesco Andreuzzi wrote: >> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70: >> >>> 68: // Count inclusion times for each header >>> 69: Map occurrences = new HashMap<>(); >>> 70: try (Stream paths = Files.walk(hotspotPath)) { >> >> I think walking the source tree is the wrong approach to gathering the data >> about include counts. I think better is to do a build and then look at the >> files /hotspot/variant-server/libjvm/objs/*.d. From that one can build >> a completely accurate count of the transitive inclusions. > > I followed this hint, the latest version of the script checks the `.d` files. > > Two observations: > - The magic number is now `2460` (more includes are taken into account, which makes sense) > - There is much less wiggle room, 2461 includes nothing, 2459 includes too much > - Runtime does not seem to be affected negatively or positively > > If anybody is interested, this file contains the inclusion count for each source file: [inclusions_count.txt](https://github.com/user-attachments/files/21682561/inclusions_count.txt) Something seems wrong with these numbers. - There are 538 headers with include counts of 2460. - There are only 1121 .o.cmdline files. So how do we get include counts that are greater (by more than a factor of 2) than the number of .d files? Note that precompiled.hpp has an include count of 2456. There's 1 .d file that depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded from counting, although I guess it should just add one to every file. Also, precompiled.hpp has an include count of 2456, so not the maximum count, but close. Which is itself weird that it wouldn't be the most included file. But it's hard to guess what might be going on with that until the surprising high include count > number of .d files is understood. That include count listing would also be more useful of sorted by count. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262874254 From shade at openjdk.org Fri Aug 8 13:35:13 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Aug 2025 13:35:13 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0O VPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> <_ESoV2tghLGuqSsmR8jYrdpoCpNpipdxtq878TT3vIc=.c21e74c2-2044-4b92-96b6-72e873302091@github.com> Message-ID: On Fri, 8 Aug 2025 12:21:33 GMT, David Holmes wrote: >> As I said before, getting too deep into theory and how this case might be special is counter-productive here. >> >> Honestly, I do _not_ understand the aversion to the idea that a field that is accessed by several threads should be nominally wrapped with `Atomic`. (Also note that some fields in `VMError` already do this.) Whatever the current situation is, that might allow for a low-level naked fence, the situation can change. I strongly believe we should be erring on the side of caution and future-proofness, unless there are other concerns on the table, like performance. There is no other concerns here, AFAICS. If you want a `fence` after the store for whatever reason, that's fine, there is `Atomic::release_store_fence` that gives it. > > It is not the "atomic" that is the issue it is the inappropriate and unnecessary use of acquire/release semantics. When people look at this code later they will wonder what it is that we are trying to coordinate - when the answer is "nothing". That just causes confusion. Synchronization and concurrency is hard enough without obfuscating things by sprinkling the wrong kind of synchronization constructs around "just to be safe". That isn't future-proofing things. If in the future we have different synchronization requirements then those requirements need to be understood and the correct code inserted. Maybe in the future we will need a mutex - who knows. You say "inappropriate and unnecessary", I say "conservative". I think this is an opinion stalemate, so I'll just recluse myself from this conversation, and let someone else to break this tie. There is no confusion to me: we pass something between the threads without clear additional synchronization in sight (i.e. mutexes) => we do `Atomic`-s. Deciding on the memory ordering for Atomics is: unless we see the need for performance, we default to conservative (acqrel and minimum for pointers, seqcst if we are are paranoid and cannot guarantee it is one-sided transfer) ordering, to avoid future accidents. If anything, a naked `fence()` raises much more questions for me in comparison with `Atomic` accesses. Mostly because fences are significantly more low-level than Atomics. When I look at this code from the perspective of bystander, these are the questions that pop into my mind: Why it is only the fence on the write side? Shouldn't there be a fence on the reader side somewhere then? Maybe we are optimizing performance? Are we relying on some other (partial) synchronization? Are we stacking with some other fence? Are there arch-specific details about what fences actually do? Etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2262992787 From duke at openjdk.org Fri Aug 8 14:10:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 14:10:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> Message-ID: <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> On Fri, 8 Aug 2025 12:42:40 GMT, Kim Barrett wrote: > Note that precompiled.hpp has an include count of 2456. There's 1 .d file that depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded from counting, although I guess it should just add one to every file. Apparently `BUILD_LIBJVM.d` mentions all files multiple times: % grep "utilities/waitBarrier.hpp" build/clang/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d | wc -l 1231 It's definitely reasonable to exclude it, I did it in the latest revision of the script. Now, the numbers seem more reasonable: % ls build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | wc -l 1232 % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | \ grep -v BUILD | sort | uniq | wc -l 1230 % grep "code/codeCache.hpp" inclusions_count.txt code/codeCache.hpp=1230 Updated [inclusions_count.txt](https://github.com/user-attachments/files/21685761/inclusions_count.txt) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263090433 From duke at openjdk.org Fri Aug 8 14:21:37 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 14:21:37 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v6] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with five additional commits since the last revision: - refresh - refresh - exclude precompiled - nn - exclude BUILD, cpp, compiler specific ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/5c8179d8..dba3a6aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=04-05 Stats: 45 lines in 2 files changed: 28 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 14:36:00 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 14:36:00 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v7] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: refresh ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/dba3a6aa..3546dd18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=05-06 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 14:50:01 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 14:50:01 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - two times might be too much - ops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/3546dd18..71950aed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=06-07 Stats: 6 lines in 2 files changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From ayang at openjdk.org Fri Aug 8 14:57:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 8 Aug 2025 14:57:20 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages Message-ID: Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. Test: tier1?8 ------------- Commit messages: - pgc-largepage Changes: https://git.openjdk.org/jdk/pull/26700/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346005 Stats: 230 lines in 15 files changed: 82 ins; 91 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From qamai at openjdk.org Fri Aug 8 15:05:14 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 15:05:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> Message-ID: On Fri, 8 Aug 2025 14:08:02 GMT, Francesco Andreuzzi wrote: >> Something seems wrong with these numbers. >> >> - There are 538 headers with include counts of 2460. >> - There are only 1121 .o.cmdline files. >> >> So how do we get include counts that are greater (by more than a factor of 2) >> than the number of .d files? >> >> Note that precompiled.hpp has an include count of 2456. There's 1 .d file that >> depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded >> from counting, although I guess it should just add one to every file. >> >> Also, precompiled.hpp has an include count of 2456, so not the maximum count, >> but close. Which is itself weird that it wouldn't be the most included file. >> But it's hard to guess what might be going on with that until the surprising >> high include count > number of .d files is understood. >> >> That include count listing would also be more useful of sorted by count. > >> Note that precompiled.hpp has an include count of 2456. There's 1 .d file that > depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded > from counting, although I guess it should just add one to every file. > > Apparently `BUILD_LIBJVM.d` mentions all files multiple times: > > % grep "utilities/waitBarrier.hpp" build/clang/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d | wc -l > 1231 > > > It's definitely reasonable to exclude it, I did it in the latest revision of the script. > > Now, the numbers seem more reasonable: > > % ls build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | wc -l > 1232 > > % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | \ > grep -v BUILD | sort | uniq | wc -l > 1230 > > % grep "code/codeCache.hpp" inclusions_count.txt > code/codeCache.hpp=1230 > > > Updated [inclusions_count.txt](https://github.com/user-attachments/files/21685761/inclusions_count.txt) I assume this means that other `.d` files might include a header multiple times, too. Is it reasonable to count only the number of files containing a header instead of number of appearances? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263225465 From duke at openjdk.org Fri Aug 8 15:20:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 15:20:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> Message-ID: On Fri, 8 Aug 2025 15:02:56 GMT, Quan Anh Mai wrote: > I assume this means that other .d files might include a header multiple times, too. >From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something? % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l 1230 % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l 1230 I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263257970 From qamai at openjdk.org Fri Aug 8 15:27:13 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 15:27:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> Message-ID: On Fri, 8 Aug 2025 15:17:06 GMT, Francesco Andreuzzi wrote: >> I assume this means that other `.d` files might include a header multiple times, too. Is it reasonable to count only the number of files containing a header instead of number of appearances? > >> I assume this means that other .d files might include a header multiple times, too. > > From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something? > > > % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l > 1230 > > % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l > 1230 > > > I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file. Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263272948 From qamai at openjdk.org Fri Aug 8 15:35:15 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 15:35:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: Message-ID: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com> On Fri, 8 Aug 2025 06:30:11 GMT, Kim Barrett wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> script. update > > src/hotspot/share/precompiled/precompiled.hpp line 29: > >> 27: >> 28: // These header files are included in at least 130 C++ files, as of >> 29: // measurements made in August 2025. > > I don't think there's anything particularly special about the number 130. > > Another thing to consider when a header file has a high include count is > whether it's being overincluded. We've had lots of those, and some folks > occasionally try to poke at that problem. Some of the removals here look like > they might be a result of such efforts. > > Still another thing to consider is the cost of inclusion. Some files may just > be a lot more expensive to process and benefit more for being precompiled. > File size can be an indicator, but there are others. Unfortunately, I don't > know of a good way to measure this. You need to modify the comment here, too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263274537 From duke at openjdk.org Fri Aug 8 15:35:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 15:35:17 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 15:28:41 GMT, Quan Anh Mai wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - two times might be too much >> - ops > > src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85: > >> 83: try { >> 84: // The first line contains the object name >> 85: return Files.lines(file).skip(1); > > Or maybe `return Files.lines(file).skip(1).distinct()`? `distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263292750 From duke at openjdk.org Fri Aug 8 15:35:16 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 15:35:16 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com> References: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com> Message-ID: On Fri, 8 Aug 2025 15:25:15 GMT, Quan Anh Mai wrote: >> src/hotspot/share/precompiled/precompiled.hpp line 29: >> >>> 27: >>> 28: // These header files are included in at least 130 C++ files, as of >>> 29: // measurements made in August 2025. >> >> I don't think there's anything particularly special about the number 130. >> >> Another thing to consider when a header file has a high include count is >> whether it's being overincluded. We've had lots of those, and some folks >> occasionally try to poke at that problem. Some of the removals here look like >> they might be a result of such efforts. >> >> Still another thing to consider is the cost of inclusion. Some files may just >> be a lot more expensive to process and benefit more for being precompiled. >> File size can be an indicator, but there are others. Unfortunately, I don't >> know of a good way to measure this. > > You need to modify the comment here, too. Right, I'll wait just a bit so the discussion on how to approach the problem stabilizes :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263289968 From qamai at openjdk.org Fri Aug 8 15:35:13 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 15:35:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:01 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - two times might be too much > - ops Marked as reviewed by qamai (Committer). src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85: > 83: try { > 84: // The first line contains the object name > 85: return Files.lines(file).skip(1); Or maybe `return Files.lines(file).skip(1).distinct()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3101235921 PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263282801 From qamai at openjdk.org Fri Aug 8 16:31:15 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 8 Aug 2025 16:31:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com> On Fri, 8 Aug 2025 15:32:32 GMT, Francesco Andreuzzi wrote: >> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85: >> >>> 83: try { >>> 84: // The first line contains the object name >>> 85: return Files.lines(file).skip(1); >> >> Or maybe `return Files.lines(file).skip(1).distinct()`? > > `distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file? It's not like stream is the most performant method to do anything anyway. I think the clarification is worth the additional overhead, especially when this file is not run very frequently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263469891 From erikj at openjdk.org Fri Aug 8 17:34:13 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 8 Aug 2025 17:34:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:01 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - two times might be too much > - ops The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3168810638 From dlong at openjdk.org Fri Aug 8 18:48:13 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 8 Aug 2025 18:48:13 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v5] In-Reply-To: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> References: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> Message-ID: On Fri, 8 Aug 2025 10:51:42 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into JDK-8308094-timeout > - Rename _timer > - remove _timeout_armed > - ASSERT > - Merge branch 'master' into JDK-8308094-timeout > - No acquire release semantics > - Factor Linux specific timeout functionality out of share/ > - Move timeout disarm above if > - Merge branch 'master' into JDK-8308094-timeout > - Fix SIGALRM test > - ... and 1 more: https://git.openjdk.org/jdk/compare/2eac5347...8bb5eb7a Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3101863176 From liach at openjdk.org Fri Aug 8 18:54:13 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 8 Aug 2025 18:54:13 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> References: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com> Message-ID: On Tue, 5 Aug 2025 14:11:06 GMT, Roger Riggs wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > src/java.base/share/classes/java/lang/NullPointerException.java line 142: > >> 140: } >> 141: >> 142: // Methods below must be called in object monitor > > This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers. Done. > src/java.base/share/classes/java/lang/NullPointerException.java line 146: > >> 144: private void ensureMessageComputed() { >> 145: if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) { >> 146: int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT; > > This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263783470 PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263782482 From liach at openjdk.org Fri Aug 8 18:54:14 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 8 Aug 2025 18:54:14 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 10:14:07 GMT, Johan Sj?len wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > src/java.base/share/classes/java/lang/NullPointerException.java line 159: > >> 157: /// configurations to trace how a particular argument, which turns out to >> 158: /// be `null`, was evaluated. >> 159: /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor) > > Can `searchSlot == -1` here? I think the code handles all < 0 cases so using that is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263781125 From dcubed at openjdk.org Fri Aug 8 18:58:12 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 8 Aug 2025 18:58:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> Message-ID: On Fri, 8 Aug 2025 15:24:46 GMT, Quan Anh Mai wrote: >>> I assume this means that other .d files might include a header multiple times, too. >> >> From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something? >> >> >> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l >> 1230 >> >> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l >> 1230 >> >> >> I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file. > > Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great. I suspect that the multiple includes reported in the .d files are accurate. The .d file appears to report the number of times we `#include` a file, however, because if the include-guard constructs we use, the content is pulled in only once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263788850 From pchilanomate at openjdk.org Fri Aug 8 19:12:19 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Aug 2025 19:12:19 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: References: Message-ID: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> > Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. > > Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. > > The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: address David's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26660/files - new: https://git.openjdk.org/jdk/pull/26660/files/1e098c54..a000a06b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=00-01 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26660/head:pull/26660 PR: https://git.openjdk.org/jdk/pull/26660 From pchilanomate at openjdk.org Fri Aug 8 19:19:12 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Aug 2025 19:19:12 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 04:36:42 GMT, David Holmes wrote: > Seems reasonable - though I dislike that we have to add ASAN and CPU specific code this way. > Initially I added it to avoid the extra branch in this fast path except when using ASan builds. I checked and the compiler is smart enough to avoid that and just generates an extra load of `_preempt` and arithmetic instructions that use a register instead of a constant. So maybe we could make it unconditional. But I thought the macros?also make it clear this is only needed for this type of build. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 106: > >> 104: // For a compiled frame we need to re-read fp out of the frame because it may be an >> 105: // oop and we might have had a safepoint in finalize_freeze, after constructing f. >> 106: // For stub/native frames the value is not used while freezed, and will be constructed > > Suggestion: > > // For stub/native frames the value is not used while frozen, and will be constructed Fixed. > src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 103: > >> 101: // For a compiled frame we need to re-read fp out of the frame because it may be an >> 102: // oop and we might have had a safepoint in finalize_freeze, after constructing f. >> 103: // For stub/native frames the value is not used while freezed, and will be constructed > > Suggestion: > > // For stub/native frames the value is not used while frozen, and will be constructed Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 796: > >> 794: // frame (lowest address). ASan treats this memory access in the callee as >> 795: // an overflow access to one of the locals stored in that frame. For these >> 796: // preemption case we don't need to read these words anyways so we avoid it. > > Suggestion: > > // preemption cases we don't need to read these words anyways so we avoid it. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 797: > >> 795: // an overflow access to one of the locals stored in that frame. For these >> 796: // preemption case we don't need to read these words anyways so we avoid it. >> 797: adjust -= _preempt ? frame::metadata_words_at_bottom : 0; > > Suggestion: > > if (_preempt) { > adjust = 0; > } Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26660#issuecomment-3169053521 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2263820051 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2263818906 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2263819043 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2263819286 From pchilanomate at openjdk.org Fri Aug 8 19:19:13 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Aug 2025 19:19:13 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: On Fri, 8 Aug 2025 19:12:19 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address David's comments Thanks for the review David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26660#issuecomment-3169060162 From dlong at openjdk.org Fri Aug 8 20:15:15 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 8 Aug 2025 20:15:15 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:49:20 GMT, Ruben wrote: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. This looks good. How much testing have you done? Maybe we can get rid of CodeOffsets::DeoptMH next. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3169173960 From duke at openjdk.org Fri Aug 8 21:43:23 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 21:43:23 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v9] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: distinct ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/71950aed..3116b39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 21:43:24 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 21:43:24 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com> References: <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com> Message-ID: On Fri, 8 Aug 2025 16:28:15 GMT, Quan Anh Mai wrote: >> `distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file? > > It's not like stream is the most performant method to do anything anyway. I think the clarification is worth the additional overhead, especially when this file is not run very frequently. 3116b39c5dc812c1bfb0994bda3a82c9f66870af ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2264028292 From duke at openjdk.org Fri Aug 8 22:11:32 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 22:11:32 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - magic number: 400 - inline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/3116b39c..be25d341 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=08-09 Stats: 188 lines in 1 file changed: 0 ins; 176 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Fri Aug 8 22:17:12 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 8 Aug 2025 22:17:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v8] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 17:31:41 GMT, Erik Joelsson wrote: > The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features. The last commit (be25d3413b432b56e9789eae55920f1862008911) should fix the problem. I made a build with the following configuration: ./configure \ --with-toolchain-type=clang \ --disable-jvm-feature-shenandoahgc \ --disable-jvm-feature-zero \ --disable-jvm-feature-zgc \ --disable-jvm-feature-g1gc \ --disable-jvm-feature-parallelgc \ --disable-jvm-feature-epsilongc and then I ran the script on this build to extract the [inclusions count](https://github.com/user-attachments/files/21692915/inclusions_count.txt). This could be included in the README file attached to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3169427612 From sangheki at openjdk.org Fri Aug 8 22:36:11 2025 From: sangheki at openjdk.org (Sangheon Kim) Date: Fri, 8 Aug 2025 22:36:11 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: <9HFVLrbzrIH4ffJz2q7YFwn7qGp008aA0b74sRnyMTM=.fd78fb39-dd8b-478e-be91-610e519870cd@github.com> On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 LGTM ------------- Marked as reviewed by sangheki (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26648#pullrequestreview-3102265382 From dlong at openjdk.org Sat Aug 9 00:39:16 2025 From: dlong at openjdk.org (Dean Long) Date: Sat, 9 Aug 2025 00:39:16 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:49:20 GMT, Ruben wrote: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Test results from Oracle are good. You need one more review. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3102350248 From dholmes at openjdk.org Sat Aug 9 02:00:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Sat, 9 Aug 2025 02:00:19 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <1hxKXbEwRFeYpwizPVqgc7A9RgisMENdhCkF6j3GpQg=.a41c0c87-3e8c-4404-a56d-5d10910f8e8a@github.com> <4kEHCplZQoA4U4JCTKpGCG8zVv3PU_8oi9YrjmKySjA=.ed88ff2d-1cdc-4332-a5d9-d6f48b89ed61@github.com> <4P-UnGAY8t-sXYcveukioiJ1rgwEhmCtJYSL7ofNevQ=.1ef67992-329a-4f7c-a0e4-d79ef6d62d8f@github.com> <25VDLj8CrrdVmydx-vou5S_-vxT_uqh5c0O VPubW7XM=.d515ad77-1b2c-4d26-ab78-554e3fe7b940@github.com> <_ESoV2tghLGuqSsmR8jYrdpoCpNpipdxtq878TT3vIc=.c21e74c2-2044-4b92-96b6-72e873302091@github.com> Message-ID: <3T7EA9zLJpHjYD6Y2bwjQu82BYrT_AU7ez9bYCAwkio=.6a7fb6e2-caed-4bd1-b271-6882ac71cd60@github.com> On Fri, 8 Aug 2025 13:32:50 GMT, Aleksey Shipilev wrote: >> It is not the "atomic" that is the issue it is the inappropriate and unnecessary use of acquire/release semantics. When people look at this code later they will wonder what it is that we are trying to coordinate - when the answer is "nothing". That just causes confusion. Synchronization and concurrency is hard enough without obfuscating things by sprinkling the wrong kind of synchronization constructs around "just to be safe". That isn't future-proofing things. If in the future we have different synchronization requirements then those requirements need to be understood and the correct code inserted. Maybe in the future we will need a mutex - who knows. > > You say "inappropriate and unnecessary", I say "conservative". I think this is an opinion stalemate, so I'll just recluse myself from this conversation, and let someone else to break this tie. > > There is no confusion to me: we pass something between the threads without clear additional synchronization in sight (i.e. mutexes) => we do `Atomic`-s. Deciding on the memory ordering for Atomics is: unless we see the need for performance, we default to conservative (acqrel and minimum for pointers, seqcst if we are are paranoid and cannot guarantee it is one-sided transfer) ordering, to avoid future accidents. > > If anything, a naked `fence()` raises much more questions for me in comparison with `Atomic` accesses. Mostly because fences are significantly more low-level than Atomics. When I look at this code from the perspective of bystander, these are the questions that pop into my mind: Why it is only the fence on the write side? Shouldn't there be a fence on the reader side somewhere then? Maybe we are optimizing performance? Are we relying on some other (partial) synchronization? Are we stacking with some other fence? Are there arch-specific details about what fences actually do? Etc. For completeness our own conventions say we should use `Atomic::load` and `Atomic::store` to highlight the lock-free access. But only a fence provides the guarantee of visibility. acquire/release does not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2264193909 From aph at openjdk.org Sat Aug 9 19:03:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 9 Aug 2025 19:03:10 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Tue, 5 Aug 2025 10:30:13 GMT, Fei Gao wrote: > In the existing implementation, the static call stub typically emits a sequence like: > `isb; movk; movz; movz; movk; movz; movz; br`. > > This patch reimplements it using a more compact and patch-friendly sequence: > > ldr x12, Label_data > ldr x8, Label_entry > br x8 > Label_data: > 0x00000000 > 0x00000000 > Label_entry: > 0x00000000 > 0x00000000 > > The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. > > While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. > > A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. > > > Benchmark (length) Mode Cnt Master Patch Units > StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op > StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op > StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op > StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op > StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op > StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op > > > All tests in Tier1 to Tier3, under both release and debug builds, have passed. > > [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads Try this. It might be enough to rescue this PR. diff --git a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp index 12b941fc4f7..29853ed4a10 100644 --- a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp @@ -68,8 +68,8 @@ friend class ArrayCopyStub; enum { // call stub: CompiledDirectCall::to_interp_stub_size() + - // CompiledDirectCall::to_trampoline_stub_size() - _call_stub_size = 13 * NativeInstruction::instruction_size, + // CompiledDirectCall::to_trampoline_stub_size() + alignment nop + _call_stub_size = 15 * NativeInstruction::instruction_size, _exception_handler_size = DEBUG_ONLY(1*K) NOT_DEBUG(175), _deopt_handler_size = 7 * NativeInstruction::instruction_size }; diff --git a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp index 4285524514b..63577a55809 100644 --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp @@ -983,22 +983,29 @@ void MacroAssembler::emit_static_call_stub() { // Jump to the entry point of the c2i stub. const int stub_start_offset = offset(); Label far_jump_metadata, far_jump_entry; - ldr(rmethod, far_jump_metadata); + { + Label retry; bind(retry); + adr(rmethod, far_jump_metadata); + ldar(rmethod, (rmethod)); + cbz(rmethod, retry); + } ldr(rscratch1, far_jump_entry); br(rscratch1); + nop(); bind(far_jump_metadata); - assert(offset() - stub_start_offset == NativeStaticCallStub::far_jump_metadata_offset, + assert(offset() - stub_start_offset == NativeStaticCallStub::metadata_offset, "should be"); + assert(is_aligned(offset(), BytesPerWord), "offset is misaligned"); emit_int64(0); bind(far_jump_entry); - assert(offset() - stub_start_offset == NativeStaticCallStub::far_jump_entrypoint_offset, + assert(offset() - stub_start_offset == NativeStaticCallStub::entrypoint_offset, "should be"); emit_int64(0); } int MacroAssembler::static_call_stub_size() { - // ldr; ldr; br; zero; zero; zero; zero; - return 7 * NativeInstruction::instruction_size; + // adr; ldar; cbz; ldr; br; nop; zero; zero; zero; zero; + return 10 * NativeInstruction::instruction_size; } void MacroAssembler::c2bool(Register x) { diff --git a/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp b/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp index 12a6eb6f7f0..5d33d94f1ae 100644 --- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp @@ -393,22 +393,20 @@ void NativeCall::trampoline_jump(CodeBuffer &cbuf, address dest, JVMCI_TRAPS) { #ifndef PRODUCT // Mirror the logic in CompiledDirectCall::verify_mt_safe(). void NativeStaticCallStub::verify_static_stub(const methodHandle& callee, address entry) { - intptr_t metadata = intptr_at(far_jump_metadata_offset); - address entrypoint = ptr_at(far_jump_entrypoint_offset); + intptr_t metadata = intptr_at(metadata_offset); + address entrypoint = ptr_at(entrypoint_offset); CompiledDirectCall::verify_mt_safe_helper(callee, entry, metadata, entrypoint); } #endif void NativeStaticCallStub::set_metadata_and_destination(intptr_t callee, address entry) { - set_intptr_at(far_jump_metadata_offset, callee); - set_ptr_at(far_jump_entrypoint_offset, entry); - OrderAccess::release(); + set_ptr_at(entrypoint_offset, entry); + Atomic::release_store((intptr_t*)addr_at(metadata_offset), callee); } void NativeStaticCallStub::verify_instruction_sequence() { - if (! (nativeInstruction_at(addr_at(0))->is_ldr_literal() && - nativeInstruction_at(addr_at(NativeInstruction::instruction_size))->is_ldr_literal() && - nativeInstruction_at(addr_at(NativeInstruction::instruction_size * 2))->is_blr())) { + if (! (nativeInstruction_at(addr_at(NativeInstruction::instruction_size * 3))->is_ldr_literal() && + nativeInstruction_at(addr_at(NativeInstruction::instruction_size * 4))->is_blr())) { fatal("Not expected instructions in static call stub"); } } diff --git a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp index 17c87bf7c2b..897152f26f1 100644 --- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp @@ -461,8 +461,8 @@ class NativeStaticCallStub : public NativeInstruction { public: enum AArch64_specific_constants { - far_jump_metadata_offset = 3 * 4, - far_jump_entrypoint_offset = 5 * 4 + metadata_offset = 6 * NativeInstruction::instruction_size, + entrypoint_offset = 6 * NativeInstruction::instruction_size + wordSize , }; void set_metadata_and_destination(intptr_t callee, address entry); ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3172040556 From aph at openjdk.org Sat Aug 9 19:15:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 9 Aug 2025 19:15:10 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Tue, 5 Aug 2025 10:30:13 GMT, Fei Gao wrote: > In the existing implementation, the static call stub typically emits a sequence like: > `isb; movk; movz; movz; movk; movz; movz; br`. > > This patch reimplements it using a more compact and patch-friendly sequence: > > ldr x12, Label_data > ldr x8, Label_entry > br x8 > Label_data: > 0x00000000 > 0x00000000 > Label_entry: > 0x00000000 > 0x00000000 > > The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations. > > While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches. > > A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%. > > > Benchmark (length) Mode Cnt Master Patch Units > StaticCallStubFar.callCompiled 1000 avgt 5 39.346 22.474 us/op > StaticCallStubFar.callCompiled 10000 avgt 5 390.05 218.478 us/op > StaticCallStubFar.callCompiled 100000 avgt 5 3869.264 2174.001 us/op > StaticCallStubNear.callCompiled 1000 avgt 5 39.093 22.582 us/op > StaticCallStubNear.callCompiled 10000 avgt 5 387.319 217.398 us/op > StaticCallStubNear.callCompiled 100000 avgt 5 3855.825 2206.923 us/op > > > All tests in Tier1 to Tier3, under both release and debug builds, have passed. > > [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads There may still be a race in `set_to_clean()`, which doesn't zero out the [method, entry} fields in the stub. I'd fix that, to be safe. It'd be tricky to test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3172045863 From lmesnik at openjdk.org Sat Aug 9 20:36:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 9 Aug 2025 20:36:51 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state Message-ID: The method get_jvmti_thread_state() should be called only while thread is in vm state. The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. The fix was found using jvmti stress agent and thus no additional regression test is required. ------------- Commit messages: - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state Changes: https://git.openjdk.org/jdk/pull/26713/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365192 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From aph at openjdk.org Sun Aug 10 07:27:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Sun, 10 Aug 2025 07:27:09 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: On Sat, 9 Aug 2025 19:12:14 GMT, Andrew Haley wrote: > There may still be a race in `set_to_clean()`, which doesn't zero out the [method, entry} fields in the stub. I'd fix that, to be safe. It'd be tricky to test. Ah no, that would create another race when unloading. This stuff is hard... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3172432994 From kbarrett at openjdk.org Mon Aug 11 01:23:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Aug 2025 01:23:18 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com> <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com> <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com> Message-ID: On Fri, 8 Aug 2025 18:55:07 GMT, Daniel D. Daugherty wrote: >> Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great. > > I suspect that the multiple includes reported in the .d files are accurate. The .d file appears > to report the number of times we `#include` a file, however, because if the include-guard > constructs we use, the content is pulled in only once. The number of times a header is (directly or indirectly) included by a given source file doesn't affect the number of times that header appears in the .d file associated with that source file. The compiler uniquifies that set (though links might confuse things, but that's not an issue here). The .d files consist of a set of targets, and for each target, the set of dependencies. For the .d files, there's one target, .o, with its dependencies (once each). For BUILD_LIBJVM.d, there's a target for each .o file. And for each of those targets, it's dependencies (once each). Essentially BUILD_LIBJVM.d includes a concatenation of all the .d files. And since there are duplicates among the dependencies of different targets, there are many(!) duplicates in this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265529851 From kbarrett at openjdk.org Mon Aug 11 01:49:20 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Aug 2025 01:49:20 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline > > The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features. > > The last commit ([be25d34](https://github.com/openjdk/jdk/commit/be25d3413b432b56e9789eae55920f1862008911)) should fix the problem. I made a build with the following configuration: > > ``` > ./configure \ > --with-toolchain-type=clang \ > --disable-jvm-feature-shenandoahgc \ > --disable-jvm-feature-zero \ > --disable-jvm-feature-zgc \ > --disable-jvm-feature-g1gc \ > --disable-jvm-feature-parallelgc \ > --disable-jvm-feature-epsilongc > ``` > > and then I ran the script on this build to extract the [inclusions count](https://github.com/user-attachments/files/21692915/inclusions_count.txt). This could be included in the README file attached to this PR. Other optional features include cds, c1, jfr, and jvmci, so files from those directories also ought to be excluded. The (current) list of optional features is here: https://github.com/openjdk/jdk/blame/022e29a77533aacabd56820d00ecffa9646a8362/make/autoconf/jvm-features.m4#L47-L49 cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check \ jvmci jvmti link-time-opt management minimal opt-size parallelgc \ serialgc services shenandoahgc vm-structs zero zgc \ Not all of these have their own directories. Even where they do, the feature name and directory name aren't always the same. (The compiler1 feature and the c1 directory being an obvious example.) I didn't spot any files for other optional features in the latest list, other than the ones called out in the first sentence of this comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173072518 From xgong at openjdk.org Mon Aug 11 03:10:17 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 11 Aug 2025 03:10:17 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Updating predicate checks Thanks for your work @jatin-bhateja! This PR also provides help on AArch64 that we also have plan to do the same intrinsifaction in our side. src/hotspot/share/opto/vectorIntrinsics.cpp line 1667: > 1665: bool LibraryCallKit::inline_vector_slice() { > 1666: const TypeInt* origin = gvn().type(argument(0))->isa_int(); > 1667: const TypeInstPtr* vector_klass = gvn().type(argument(1))->isa_instptr(); Code style: Suggestion: const TypeInt* origin = gvn().type(argument(0))->isa_int(); const TypeInstPtr* vector_klass = gvn().type(argument(1))->isa_instptr(); src/hotspot/share/opto/vectorIntrinsics.cpp line 1700: > 1698: > 1699: if (!arch_supports_vector(Op_VectorSlice, num_elem, elem_bt, VecMaskNotUsed)) { > 1700: log_if_needed(" ** not supported: arity=2 op=slice vlen=%d etype=%s ismask=useload/none", `ismask=useload/none` is not necessary here? src/hotspot/share/opto/vectorIntrinsics.cpp line 1714: > 1712: } > 1713: > 1714: Node* origin_node = gvn().intcon(origin->get_con() * type2aelembytes(elem_bt)); Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes. Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such requirement. WDYT? src/hotspot/share/opto/vectornode.hpp line 1719: > 1717: class VectorSliceNode : public VectorNode { > 1718: public: > 1719: VectorSliceNode(Node* vec1, Node* vec2, Node* origin, const TypeVect* vt) Do we have specific value for `origin` like zero or vlen? If so, maybe simply Identity is better to be added as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3103877319 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265568519 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265573060 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265579342 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265580768 From xgong at openjdk.org Mon Aug 11 03:14:12 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 11 Aug 2025 03:14:12 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Updating predicate checks test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 36: > 34: @State(Scope.Thread) > 35: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector"}) > 36: public class VectorSliceBenchmark { I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2265592754 From dholmes at openjdk.org Mon Aug 11 06:24:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Aug 2025 06:24:11 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: On Fri, 8 Aug 2025 19:12:19 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address David's comments Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26660#pullrequestreview-3104168492 From dholmes at openjdk.org Mon Aug 11 06:29:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Aug 2025 06:29:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com> On Mon, 11 Aug 2025 01:46:43 GMT, Kim Barrett wrote: > Other optional features include cds, c1, jfr, and jvmci, so files from those directories also ought to be excluded. Can't these just be conditionalized with an INCLUDE_xxx check instead of being excluded? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173410334 From jbhateja at openjdk.org Mon Aug 11 06:39:57 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 11 Aug 2025 06:39:57 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v3] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Updating predicate checks - Fixes for failing regressions - Optimizing AVX2 backend and some re-factoring - new benchmark - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8303762 - 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction ------------- Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=02 Stats: 747 lines in 32 files changed: 664 ins; 0 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From dfenacci at openjdk.org Mon Aug 11 07:31:12 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 11 Aug 2025 07:31:12 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:49:20 GMT, Ruben wrote: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Thanks for "cleaning" this @ruben-arm. Did you run some testing (on the touched platforms)? I doubt that there is anything perceivable but, out of curiosity, did you notice any performance change? src/hotspot/cpu/s390/s390.ad line 1652: > 1650: public: > 1651: > 1652: static int emit_exception_handler(C2_MacroAssembler *masm); Is this declaration still needed? src/hotspot/share/code/nmethod.cpp line 1486: > 1484: } > 1485: > 1486: assert(offsets->value(CodeOffsets::Deopt ) != -1, "must be set"); It might be good to leave this line where it was at the beginning of the block, just to avoid one more diff. ------------- PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3104246623 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2265844527 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2265878970 From ihse at openjdk.org Mon Aug 11 08:02:20 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 08:02:20 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: <-U8KN5uNIUhrTn2MCESloqat2y6ZFvgxK-bsmqIDFFI=.ab50a73b-80bd-49ec-aac9-b633cc92b915@github.com> On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline There is a handy shortcut for creating a build with all optional features disabled, `--with-jvm-variants=custom`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173648190 From kbarrett at openjdk.org Mon Aug 11 08:02:20 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Aug 2025 08:02:20 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com> References: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com> Message-ID: On Mon, 11 Aug 2025 06:26:04 GMT, David Holmes wrote: > > Other optional features include cds, c1, jfr, and jvmci, so files from those directories also ought to be excluded. > > Can't these just be conditionalized with an INCLUDE_xxx check instead of being excluded? Yeah, that might be better than excluding altogether. But still need to figure out which files to (conditionally) exclude. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173654009 From ihse at openjdk.org Mon Aug 11 08:02:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 08:02:21 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 06:32:57 GMT, Kim Barrett wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - magic number: 400 >> - inline > > src/hotspot/share/precompiled/precompiled.hpp line 70: > >> 68: #include "utilities/ticks.hpp" >> 69: >> 70: #ifdef TARGET_COMPILER_visCPP > > All of the reported testing was on Linux. These were included specifically because measurements > said their inclusion here was beneficial. And my recollection from previous discussions is that > Visual Studio may be the compiler where precompiled headers are most beneficial. Indeed, Visual Studio is the place where PCH is most needed. I see Erik says he tested on Windows with no difference. While he concluded that this means no regression, I see it as a missed opportunity. Giving the Windows platform a bit of extra love can probably increase compilation speed where it is needed the most. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265948776 From ihse at openjdk.org Mon Aug 11 08:09:15 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 08:09:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi wrote: > Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils. @shipilev I'm not sure this is a proper place. The other tools in `src/utils` are stand-alone utilities that could be useful to end users, like hsdis and IdealGraphVisualizer. In contrast, tools that are useful for developers are put either into `bin` or `make/scripts`. Normally, I think `bin` is what would make most sense, and the latter is mostly a legacy result of people using `make` as a `misc` back in the bad old hg-forest days, but in this particular case I think it might be the best placement. This is after all clearly about optimizing the build speed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173680429 From ihse at openjdk.org Mon Aug 11 08:13:12 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 08:13:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com> Message-ID: On Mon, 11 Aug 2025 07:59:02 GMT, Kim Barrett wrote: > But still need to figure out which files to (conditionally) exclude. Maybe first make a baseline build with no optional features, and analyze the result with this tool. And then enable each individual feature, re-build and re-analyze, and see how it differs. If a file then makes it to the PCH list, it is useful when enabling that feature, and it is potentially only correct to include with that feature enabled, so it could be added with an include guard. That will require a bit more manual work (unless this process too can be automated), but it will probably give the best results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173692668 From duke at openjdk.org Mon Aug 11 08:20:15 2025 From: duke at openjdk.org (Ruben) Date: Mon, 11 Aug 2025 08:20:15 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 11 Aug 2025 06:57:52 GMT, Damon Fenacci wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > src/hotspot/cpu/s390/s390.ad line 1652: > >> 1650: public: >> 1651: >> 1652: static int emit_exception_handler(C2_MacroAssembler *masm); > > Is this declaration still needed? No, it should be removed as well - I will update the patch. > src/hotspot/share/code/nmethod.cpp line 1486: > >> 1484: } >> 1485: >> 1486: assert(offsets->value(CodeOffsets::Deopt ) != -1, "must be set"); > > It might be good to leave this line where it was at the beginning of the block, just to avoid one more diff. Sure, I will update this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2265989794 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2265989898 From ihse at openjdk.org Mon Aug 11 08:21:22 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 08:21:22 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v3] In-Reply-To: References: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com> Message-ID: On Fri, 8 Aug 2025 15:31:18 GMT, Francesco Andreuzzi wrote: >> You need to modify the comment here, too. > > Right, I'll wait just a bit so the discussion on how to approach the problem stabilizes :) This number is based on my original experimentation. If I tried to lower the bar by lowering the number, the PCH list grew too much and it made for a worse performance. And contrary, if I raised the number, fewer files where included which made the PCH quicker to process but less helpful. That number was the optimum I found. It seems from https://bugs.openjdk.org/browse/JDK-8365053 that this is still around the optimum. However, rather than just mentioning the number in the comment, the rationale could be specified, like `the optimum number of includes`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265991618 From duke at openjdk.org Mon Aug 11 08:41:12 2025 From: duke at openjdk.org (Ruben) Date: Mon, 11 Aug 2025 08:41:12 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <0JLBGmyrRt-y1IHz5j-UYkiXutQ1FgrOqeO0gQTFhcs=.fb1ff8ce-67d9-4963-9adb-758e17b66f98@github.com> On Fri, 8 Aug 2025 20:12:08 GMT, Dean Long wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > This looks good. How much testing have you done? > > Maybe we can get rid of CodeOffsets::DeoptMH next. Thank you for the reviews, @dean-long, @dafedafe, > How much testing have you done? > Did you run some testing (on the touched platforms)? I've run tier1-tier3 tests, however only on AArch64 and x86-64. I can run more tests on these platforms if that might be useful. > I doubt that there is anything perceivable but, out of curiosity, did you notice any performance change? I've not measured performance impact of the patch separately. It is a part of a bigger effort to reduce memory footprint of compiled code. The cumulative effect from this and similar patches is expected to be a noticeable performance improvement, however I wouldn't expect a significant observable effect from this patch only. The decrease for C2-compiled code on AArch64 should be 4-12 bytes (depends on size of code cache) per nmethod, however the nmethod's alignment requirement might hide some of these improvements. I'm also exploring possibility to reduce footprint of the deoptimization handler stub codes. > Maybe we can get rid of CodeOffsets::DeoptMH next. I will look into this. I have a proof-of-concept patch reducing each deoptimization handler stub code to 1 instruction each on AArch64 - that instruction traps and the rest of the deoptimization handler logic continues in signal handler. However, I would agree it would be preferable to remove the stub code completely if possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3173773194 From duke at openjdk.org Mon Aug 11 08:59:16 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 11 Aug 2025 08:59:16 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com> Message-ID: <0DhdCTNjwi_HGzvp9ybEEikGSHvqSvWTBP4PIIbdzEI=.7bbfa37f-be55-4925-9cc9-40850ba1f54c@github.com> On Mon, 11 Aug 2025 08:10:09 GMT, Magnus Ihse Bursie wrote: > > But still need to figure out which files to (conditionally) exclude. > > Maybe first make a baseline build with no optional features, and analyze the result with this tool. And then enable each individual feature, re-build and re-analyze, and see how it differs. If a file then makes it to the PCH list, it is useful when enabling that feature, and it is potentially only correct to include with that feature enabled, so it could be added with an include guard. > > That will require a bit more manual work (unless this process too can be automated), but it will probably give the best results. Hi @magicus, thanks for the hint. I'll give it a shot and post the results here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173824367 From ihse at openjdk.org Mon Aug 11 09:39:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 09:39:21 GMT Subject: RFR: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3104868381 From ayang at openjdk.org Mon Aug 11 09:41:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 09:41:15 GMT Subject: RFR: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26648#issuecomment-3173964461 From ayang at openjdk.org Mon Aug 11 09:45:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 09:45:26 GMT Subject: Integrated: 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 18:18:34 GMT, Albert Mingkun Yang wrote: > Use gc-cause checking in `VM_G1CollectFull` to decide soft-ref policy. > > Test: tier1-3 This pull request has now been integrated. Changeset: 0c39228e Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/0c39228ec1c8c6eadafb54567c94ad5f19f27f7a Stats: 42 lines in 6 files changed: 4 ins; 35 del; 3 mod 8364767: G1: Remove use of CollectedHeap::_soft_ref_policy Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/26648 From ayang at openjdk.org Mon Aug 11 10:57:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 10:57:10 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree [v2] In-Reply-To: References: Message-ID: <_64fHkIUSnCgZRdwphFKm6LqfUaSv_NKzd0-ivH3nEw=.4fc83148-7758-4ef7-969c-816aa0750a92@github.com> On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. >> >> I made some modifications to the red-black tree to make it compatible with previous treap usages: >> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. >> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. >> >> Changes to NMT include: >> - Modified components to align with the updated const-correctness of the red-black tree functions >> - Renamed structures and variables to remove "treap" from their names to reflect the new tree >> >> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > feedback fixes Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3105279452 From adinn at openjdk.org Mon Aug 11 11:08:11 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 11 Aug 2025 11:08:11 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:49:20 GMT, Ruben wrote: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Looks ok to me. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3105309380 From redestad at openjdk.org Mon Aug 11 11:14:20 2025 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Aug 2025 11:14:20 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: <7vrt6sWpiQUWUchiSTMUByRbe8q1Tcd_VcfkJP4MaB0=.3ee3b5f9-7188-446b-bd9a-12233fda0488@github.com> On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici 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 31 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Replace `requireNonNull` with implicit null checks to reduce bytecode size > - Add `@bug` tags > - Improve wording of `@param len` > - Make source array bound checks lenient too > - Cap destination array bounds > - Fix bit shifting > - Remove superseded `@throws` Javadoc > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Make `StringCoding` encoding intrinsics lenient > - ... and 21 more: https://git.openjdk.org/jdk/compare/9a1823bd...c322f0e0 src/hotspot/share/opto/library_call.cpp line 964: > 962: > 963: if (bailout->req() > 1) { > 964: bailout = _gvn.transform(bailout)->as_Region(); Should this be done only for the case where it's needed, i.e., in the `if (halt)` branch? Not sure it has any side-effect but it seems prudent not to change the default code more than necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266374676 From cstein at openjdk.org Mon Aug 11 11:35:12 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 11 Aug 2025 11:35:12 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v2] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/bf7b033b..b5112c32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=00-01 Stats: 30 lines in 2 files changed: 8 ins; 19 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From cstein at openjdk.org Mon Aug 11 11:35:13 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 11 Aug 2025 11:35:13 GMT Subject: RFR: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: <45gc5UsWc5d6aePWF_7SSX0ERJTTvklTXBukRdjqhCc=.1cf0046e-b697-4fce-9751-e8eade48a49e@github.com> On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. I updated both tests to be agnostic about the location to where `jtreg` puts library classes into. See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3174373256 From ayang at openjdk.org Mon Aug 11 12:01:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Aug 2025 12:01:12 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Thu, 7 Aug 2025 07:34:50 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments > I should have picked this up previously but volatile generally serves no purpose for inter-thread consistency. True, but I thought we denote a variable `volatile` if it can be accessed by multiple threads, mostly for documentation purpose. In this case, it should be e.g. `Thread* volatile VMError::_handshake_timed_out_thread`. > (I note that pthread_kill is not specified as a memory synchronizing operation, but I strongly suspect it has to have its own internal memory barriers that we would be piggy-backing on.) How about making the ordering explicit by using `OrderAccess::acquire/release` in reader/writer side? Sth like: Writer side: VMError::set_handshake_timed_out_thread(target); OrderAccess::release(); if (os::signal_thread(target, SIGILL, "cannot be handshaked")) { Reader side: if (_siginfo != nullptr && os::signal_sent_by_kill(_siginfo)) { OrderAccess::acquire(); if (get_handshake_timed_out_thread() == _thread) { > Here we have a very simple situation: > Thread 1: set field; signal target thread > Target thread: receive signal; read field I think for this to work, we need ordering btw set-field and sending-signal and btw reading-signal and read-field. Therefore, the acquire/release "operation" should be performed on the "signal" variable. (Ofc, such "signal" variable is not directly accessible, hence, the suggested `OrderAccess` above.) I have to say it's indeed a bit odd that "setters" (e.g. `set_handshake_timed_out_thread`) have `fence()` there for no obvious reasons. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3174462135 From cnorrbin at openjdk.org Mon Aug 11 12:26:18 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 11 Aug 2025 12:26:18 GMT Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree [v2] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. >> >> I made some modifications to the red-black tree to make it compatible with previous treap usages: >> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. >> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. >> >> Changes to NMT include: >> - Modified components to align with the updated const-correctness of the red-black tree functions >> - Renamed structures and variables to remove "treap" from their names to reflect the new tree >> >> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > feedback fixes Thank you for the reviews! Let's ship it :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26655#issuecomment-3174530098 From cnorrbin at openjdk.org Mon Aug 11 12:26:19 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 11 Aug 2025 12:26:19 GMT Subject: Integrated: 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 09:29:05 GMT, Casper Norrbin wrote: > Hi everyone, > > The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it. > > I made some modifications to the red-black tree to make it compatible with previous treap usages: > - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early. > - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently. > > Changes to NMT include: > - Modified components to align with the updated const-correctness of the red-black tree functions > - Renamed structures and variables to remove "treap" from their names to reflect the new tree > > The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case. > > Testing: > - Oracle tiers 1-3 This pull request has now been integrated. Changeset: 0ad919c1 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/0ad919c1e54895b000b58f6a1b54d79f76970845 Stats: 1016 lines in 14 files changed: 124 ins; 816 del; 76 mod 8352067: Remove the NMT treap and replace its uses with the utilities red-black tree Reviewed-by: jsjolen, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26655 From redestad at openjdk.org Mon Aug 11 12:46:19 2025 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Aug 2025 12:46:19 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici 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 31 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Replace `requireNonNull` with implicit null checks to reduce bytecode size > - Add `@bug` tags > - Improve wording of `@param len` > - Make source array bound checks lenient too > - Cap destination array bounds > - Fix bit shifting > - Remove superseded `@throws` Javadoc > - Merge remote-tracking branch 'upstream/master' into strIntrinCheck > - Make `StringCoding` encoding intrinsics lenient > - ... and 21 more: https://git.openjdk.org/jdk/compare/502f1129...c322f0e0 src/hotspot/share/opto/library_call.cpp line 946: > 944: Node* count, > 945: bool char_count, > 946: bool halt) { Could we rename this to something more descriptive such as `halt_on_oob`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266616962 From kbarrett at openjdk.org Mon Aug 11 13:14:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Aug 2025 13:14:03 GMT Subject: RFR: 8365245: Move size reducing operations to GrowableArrayWithAllocator Message-ID: Please review this change to GrowableArray to move size reducing operations from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. See JBS for rationale for this move. This is mostly just a simple code motion change, with the moved functions being updated to account for different name lookup rules now that they are in a class with a class template base class. For the most part this refactoring didn't require any client code changes. All but one use of one moved function was with a GrowableArrayWithAllocator-derived class, so not affected by moving the functions. The one exception was a test of ZArraySlice that was modified to no longer use GA::pop(). Testing: mach5 tier1. ------------- Commit messages: - move pop to GAWA, fixing gtest - move remove_at to GAWA - move remove_if_existing to GAWA - move remove to GAWA - move remove_till/remove_range to GAWA - move delete_at to GAWA - move trunc_to to GAWA - move clear() to GAWA Changes: https://git.openjdk.org/jdk/pull/26726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365245 Stats: 134 lines in 2 files changed: 69 ins; 64 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26726/head:pull/26726 PR: https://git.openjdk.org/jdk/pull/26726 From kbarrett at openjdk.org Mon Aug 11 13:14:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Aug 2025 13:14:03 GMT Subject: RFR: 8365245: Move size reducing operations to GrowableArrayWithAllocator In-Reply-To: References: Message-ID: <-i9UDvOkeQCBRT-__2W7gERYOXOtJ3H4njnIgSmCN2k=.faa7a8bf-45e9-4efe-90e8-1fa3d3fa37b8@github.com> On Mon, 11 Aug 2025 13:06:01 GMT, Kim Barrett wrote: > Please review this change to GrowableArray to move size reducing operations > from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. > See JBS for rationale for this move. > > This is mostly just a simple code motion change, with the moved functions > being updated to account for different name lookup rules now that they are in > a class with a class template base class. For the most part this refactoring > didn't require any client code changes. All but one use of one moved function > was with a GrowableArrayWithAllocator-derived class, so not affected by moving > the functions. The one exception was a test of ZArraySlice that was modified > to no longer use GA::pop(). > > Testing: mach5 tier1. I didn't make any code changes to address some issues noticed while doing this refactoring. Some things I noticed and will file JBS issues for were: - GrowableArray::remove_range doesn't allow an empty range. Wondering why, as that's potentially inconvenient and contrary to usual practice. - GrowableArray::appendAll effectively does a bunch of push_backs, which can lead to multiple reallocations. It should expand capacity once up front, based on the size of the array being appended. - GrowableArray::remove_if_existing searches for the the item twice, once to detect it's presence (using `contains`), and again as part of `remove`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26726#issuecomment-3174744007 From vyazici at openjdk.org Mon Aug 11 13:47:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 11 Aug 2025 13:47:41 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v14] In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > ... Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: - Rename `generate_string_range_check::halt` to `halt_on_oob` - Move `->asRegion()` after `if (halt)` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25998/files - new: https://git.openjdk.org/jdk/pull/25998/files/c322f0e0..9b721bb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=12-13 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998 PR: https://git.openjdk.org/jdk/pull/25998 From vyazici at openjdk.org Mon Aug 11 13:47:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 11 Aug 2025 13:47:44 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Mon, 11 Aug 2025 12:43:38 GMT, Claes Redestad wrote: >> Volkan Yazici 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 31 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into strIntrinCheck >> - Replace `requireNonNull` with implicit null checks to reduce bytecode size >> - Add `@bug` tags >> - Improve wording of `@param len` >> - Make source array bound checks lenient too >> - Cap destination array bounds >> - Fix bit shifting >> - Remove superseded `@throws` Javadoc >> - Merge remote-tracking branch 'upstream/master' into strIntrinCheck >> - Make `StringCoding` encoding intrinsics lenient >> - ... and 21 more: https://git.openjdk.org/jdk/compare/357546c1...c322f0e0 > > src/hotspot/share/opto/library_call.cpp line 946: > >> 944: Node* count, >> 945: bool char_count, >> 946: bool halt) { > > Could we rename this to something more descriptive such as `halt_on_oob`? Changed as requested in 9b721bb9fee. > src/hotspot/share/opto/library_call.cpp line 964: > >> 962: >> 963: if (bailout->req() > 1) { >> 964: bailout = _gvn.transform(bailout)->as_Region(); > > Should this be done only for the case where it's needed, i.e., in the `if (halt)` branch? Not sure it has any side-effect but it seems prudent not to change the default code more than necessary. Changed as requested in 4d2a7a39c50. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266824420 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266823319 From vyazici at openjdk.org Mon Aug 11 13:56:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 11 Aug 2025 13:56:18 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Wed, 6 Aug 2025 05:24:41 GMT, Shaojin Wen wrote: >> Volkan Yazici 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 31 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into strIntrinCheck >> - Replace `requireNonNull` with implicit null checks to reduce bytecode size >> - Add `@bug` tags >> - Improve wording of `@param len` >> - Make source array bound checks lenient too >> - Cap destination array bounds >> - Fix bit shifting >> - Remove superseded `@throws` Javadoc >> - Merge remote-tracking branch 'upstream/master' into strIntrinCheck >> - Make `StringCoding` encoding intrinsics lenient >> - ... and 21 more: https://git.openjdk.org/jdk/compare/565028e3...c322f0e0 > > src/java.base/share/classes/java/lang/StringCoding.java line 99: > >> 97: * {@linkplain Preconditions#checkFromIndexSize(int, int, int, BiFunction) out of bounds} >> 98: */ >> 99: static int countPositives(byte[] ba, int off, int len) { > > If we name countPositives with parameter checking as countPositivesSB, this PR will have fewer changes. I presume you mean we would not need to touch `vmIntrinsics.hpp` and such. I discussed this with @cl4es, and we decided to keep the _"`foo` for method, and `foo0` for intrinsic candidate"_ convention, since this matches the existing one. Unless more experienced maintainers tell do to otherwise, I will stick to the current style. @wenshao, nevertheless, thanks so much for your kind review(s). Please keep them coming. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266851757 From duke at openjdk.org Mon Aug 11 14:53:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 11 Aug 2025 14:53:17 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline Some results: | Features | Time1 (s) | Time2 (s) | Change (s) | |---------------------------------|----------|----------|-------------| | epsilongc | 490.77 | 489.50 | 1.27 | | epsilongc cds | 546.27 | 537.91 | 8.36 | | epsilongc compiler1 | 547.87 | 539.86 | 8.01 | | epsilongc compiler2 | 785.18 | 735.13 | 50.05 | | g1gc | 682.44 | 666.40 | 16.04 | | epsilongc services | 510.22 | 504.68 | 5.54 | | epsilongc services jfr | 675.49 | 636.87 | 38.62 | | epsilongc jni-check | 499.53 | 493.72 | 5.81 | | epsilongc compiler1 jvmci | 589.74 | 591.32 | -1.58 | | epsilongc compiler2 jvmci | 852.46 | 806.35 | 46.11 | | epsilongc services jvmti | 567.67 | 561.73 | 5.94 | | epsilongc link-time-opt | 535.96 | 526.00 | 9.97 | | epsilongc management | 508.63 | 504.53 | 4.10 | | epsilongc opt-size | 507.03 | 498.58 | 8.45 | | parallelgc | 525.78 | 517.38 | 8.40 | | serialgc | 512.59 | 511.88 | 0.71 | | shenandoahgc | 739.44 | 722.72 | 16.72 | | zgc | 681.20 | 672.28 | 8.92 | - `Time1` is the time (sys+user) it takes to complete `make -h hotspot` with the precompiled headers in be25d3413b432b56e9789eae55920f1862008911 (>=400 includes in a `custom` build) - `Time2`: same as `Time1`, with the precompiled headers having >=400 includes in a `custom` build with all features in the first column So, the third column measures how much we improve by taking new precompiled headers due to a specific features. I'd say the following are worth keeping behind an include guard: - `cds` - `compiler1` - `compiler2` - `g1gc` - `services` - `jfr` ==> `services` (#26723) - `jni-check` - `link-time-opt` - `opt-size` - `parallelgc` - `shenandoahgc` - `zgc` ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175208900 From ihse at openjdk.org Mon Aug 11 15:52:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 15:52:21 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 14:49:54 GMT, Francesco Andreuzzi wrote: > * `link-time-opt` > > * `opt-size` I thought these should not really affect the set of files compiled (or included, which is what matters here)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175481286 From jsjolen at openjdk.org Mon Aug 11 16:04:00 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 11 Aug 2025 16:04:00 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable Message-ID: Hi, This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. I didn't change any copyright years for this change. Thanks ------------- Commit messages: - Rename file - Rename ResourceHashtable to HashTable Changes: https://git.openjdk.org/jdk/pull/26729/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365264 Stats: 1841 lines in 67 files changed: 856 ins; 856 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/26729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729 PR: https://git.openjdk.org/jdk/pull/26729 From duke at openjdk.org Mon Aug 11 16:27:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 11 Aug 2025 16:27:15 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: <7_2SHq1iU6SEIPWDiTaNhW6G0ChhcnsXtrVxMUgB0ts=.a407d743-9d86-4ab3-b905-3ea8cf8069f3@github.com> On Mon, 11 Aug 2025 15:49:55 GMT, Magnus Ihse Bursie wrote: >> Some results: >> >> | Features | Time1 (s) | Time2 (s) | Change (s) | >> |---------------------------------|----------|----------|-------------| >> | epsilongc | 490.77 | 489.50 | 1.27 | >> | epsilongc cds | 546.27 | 537.91 | 8.36 | >> | epsilongc compiler1 | 547.87 | 539.86 | 8.01 | >> | epsilongc compiler2 | 785.18 | 735.13 | 50.05 | >> | g1gc | 682.44 | 666.40 | 16.04 | >> | epsilongc services | 510.22 | 504.68 | 5.54 | >> | epsilongc services jfr | 675.49 | 636.87 | 38.62 | >> | epsilongc jni-check | 499.53 | 493.72 | 5.81 | >> | epsilongc compiler1 jvmci | 589.74 | 591.32 | -1.58 | >> | epsilongc compiler2 jvmci | 852.46 | 806.35 | 46.11 | >> | epsilongc services jvmti | 567.67 | 561.73 | 5.94 | >> | epsilongc link-time-opt | 535.96 | 526.00 | 9.97 | >> | epsilongc management | 508.63 | 504.53 | 4.10 | >> | epsilongc opt-size | 507.03 | 498.58 | 8.45 | >> | parallelgc | 525.78 | 517.38 | 8.40 | >> | serialgc | 512.59 | 511.88 | 0.71 | >> | shenandoahgc | 739.44 | 722.72 | 16.72 | >> | zgc | 681.20 | 672.28 | 8.92 | >> >> - `Time1` is the time (sys+user) it takes to complete `make -h hotspot` with the precompiled headers in be25d3413b432b56e9789eae55920f1862008911 (>=400 includes in a `custom` build) >> - `Time2`: same as `Time1`, with the precompiled headers having >=400 includes in a `custom` build with all features in the first column >> >> So, the third column measures how much we improve by taking new precompiled headers due to a specific features. I'd say the following are worth keeping behind an include guard: >> - `cds` >> - `compiler1` >> - `compiler2` >> - `g1gc` >> - `services` >> - `jfr` ==> `services` (#26723) >> - `jni-check` >> - `link-time-opt` >> - `opt-size` >> - `parallelgc` >> - `shenandoahgc` >> - `zgc` > >> * `link-time-opt` >> >> * `opt-size` > > I thought these should not really affect the set of files compiled (or included, which is what matters here)? That's right @magicus, I rerun the script and I got only a `1.86s` improvements for `link-time-opt`. I checked the includes in `precompiled.hpp` and indeed nothing changes when the analyzer runs on a build with `link-time-opt`. So, exactly the same build, just different build times. That's most likely noise. I'd say, as a criteria we could use is: - Improvement > 10s (unlikely to be noise, but still possible) - new headers added to `precompiled.hpp` is not empty ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175758710 From aph at openjdk.org Mon Aug 11 17:06:22 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 11 Aug 2025 17:06:22 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching Message-ID: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. We mark all sites that we know will write to code memory with `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to see where transitions take place. ------------- Commit messages: - Cleanup - More - More - More - Remove debug code - More - More - More - Update src/hotspot/share/interpreter/interpreterRuntime.cpp - Update src/hotspot/share/runtime/javaThread.cpp - ... and 1 more: https://git.openjdk.org/jdk/compare/c239c0ab...b9709363 Changes: https://git.openjdk.org/jdk/pull/26562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328306 Stats: 267 lines in 32 files changed: 209 ins; 19 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Mon Aug 11 17:06:23 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 11 Aug 2025 17:06:23 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Wed, 30 Jul 2025 17:34:48 GMT, Andrew Haley wrote: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... > ### Progress > > * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > > * [x] Change must not contain extraneous whitespace > > * [x] Commit message must refer to an issue > > > ### Error > > ?? The pull request body must not be empty. > ### Integration blocker > > ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) > ### Issue > > * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. > > > ### Reviewing > Using `git` > > Using Skara CLI tools > > Using diff file > ### Progress > > * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > > * [x] Change must not contain extraneous whitespace > > * [x] Commit message must refer to an issue > > > ### Error > > ?? The pull request body must not be empty. > ### Integration blocker > > ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) > ### Issue > > * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. > > > ### Reviewing > Using `git` > > Using Skara CLI tools > > Using diff file src/hotspot/share/interpreter/interpreterRuntime.cpp line 392: > 390: > 391: > 392: Suggestion: src/hotspot/share/runtime/javaThread.cpp line 526: > 524: > 525: _lock_stack(this), > 526: _om_cache(this) { Suggestion: _om_cache(this) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3175557349 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2243461476 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2243453769 From jsjolen at openjdk.org Mon Aug 11 17:32:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 11 Aug 2025 17:32:11 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len wrote: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks Aha, of course I forgot about re-sorting the headers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3176028919 From iris at openjdk.org Mon Aug 11 17:38:12 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 11 Aug 2025 17:38:12 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v2] In-Reply-To: References: Message-ID: <3cVhuiuq1cW-XgONMnkCje3LI6yOMIxTmmiH5AStlTY=.e6a50bf3-0a7e-437b-bd66-3f6b59353b74@github.com> On Mon, 11 Aug 2025 11:35:12 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3106980594 From jbhateja at openjdk.org Mon Aug 11 18:02:34 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 11 Aug 2025 18:02:34 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v4] In-Reply-To: References: Message-ID: <4omqHrPtNFE0UWmulPymwsUHXRpd9EBhgJvOpRyXxJQ=.dacad6cd-5a3e-4671-9543-98f04e1b7e73@github.com> > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/e7c7374b..405de56f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=02-03 Stats: 389 lines in 9 files changed: 373 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From duke at openjdk.org Mon Aug 11 18:32:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 11 Aug 2025 18:32:17 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline Just found a bug in the script, I'm rerunning all the combinations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3176301836 From dlong at openjdk.org Mon Aug 11 20:52:13 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 11 Aug 2025 20:52:13 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:49:20 GMT, Ruben wrote: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Re: CodeOffsets::DeoptMH, what I meant is that it is just an exact copy of the CodeOffsets::Deopt stub code. Apparently at some point in the JSR 292 evolution, we needed to distinguish between the two, but it looks to me that we no longer need to do that. So we should be able to get rid of DeoptMH and related code, like nmethod::is_deopt_mh_entry(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3176849923 From duke at openjdk.org Mon Aug 11 21:37:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 11 Aug 2025 21:37:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline | Feature | Baseline `precompiled.hpp` (Mean ?) | Updated `precompiled.hpp` (Mean ?) | |-----------------------|---------------------|----------------------| | epsilongc | 505.78 ? 9.08 | 499.36 ? 3.21 | | epsilongc cds | 523.93 ? 9.42 | 510.68 ? 0.99 | | epsilongc compiler1 | 514.89 ? 2.28 | 518.67 ? 14.22 | | epsilongc compiler2 | 758.34 ? 5.56 | 736.65 ? 32.95 | | g1gc | 674.96 ? 6.37 | 693.39 ? 23.25 | | epsilongc services jfr| 707.45 ? 2.08 | 670.55 ? 1.50 | | epsilongc jni-check | 522.61 ? 1.82 | 517.46 ? 1.67 | | epsilongc compiler1 jvmci | 604.92 ? 4.23 | 600.61 ? 8.79 | | epsilongc compiler2 jvmci | 836.85 ? 7.40 | 792.07 ? 16.18 | | epsilongc services jvmti | 549.48 ? 6.87 | 553.74 ? 7.67 | | epsilongc management | 486.56 ? 5.68 | 480.58 ? 4.59 | | epsilongc opt-size | 476.57 ? 1.87 | 476.71 ? 1.23 | | parallelgc | 497.28 ? 3.90 | 493.68 ? 2.19 | | serialgc | 477.84 ? 0.86 | 476.14 ? 1.32 | | epsilongc services | 476.99 ? 2.44 | 478.74 ? 3.47 | | shenandoahgc | 676.10 ? 5.35 | 623.43 ? 3.11 | | zgc | 620.95 ? 1.84 | 621.86 ? 4.35 | `?`: maximum and minimum measurements ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3176968277 From ihse at openjdk.org Mon Aug 11 22:38:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Aug 2025 22:38:13 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline This looks like regressions for c1 and G1..? And/or a lot more variability in build time. Any idea what is causing that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3177090836 From duke at openjdk.org Tue Aug 12 00:54:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 12 Aug 2025 00:54:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline I'm starting to think the high variability is a quirk of my environment. I ran the builds in a virtualized machine and I'm probably experiencing erratic behavior under high load. I re-ran each combination fewer times (3, should still be enough to get an idea), and I'm observing more reasonable results: | Feature | Baseline `precompiled.hpp` | Updated `precompiled.hpp` | |----------------------------|-----------------|-----------------| | epsilongc | 458.88 +/- 0.35 | 459.69 +/- 0.34 | | epsilongc cds | 501.63 +/- 0.35 | 501.58 +/- 0.57 | | epsilongc compiler1 | 505.66 +/- 0.61 | 505.06 +/- 0.51 | | epsilongc compiler2 | 725.91 +/- 0.41 | 692.25 +/- 0.40 | | g1gc | 630.73 +/- 0.02 | 624.24 +/- 0.35 | | epsilongc services jfr | 625.54 +/- 1.45 | 592.37 +/- 1.00 | | epsilongc jni-check | 461.19 +/- 0.14 | 461.79 +/- 0.89 | | epsilongc compiler1 jvmci | 541.31 +/- 0.42 | 540.31 +/- 0.70 | | epsilongc compiler2 jvmci | 758.13 +/- 0.71 | 724.80 +/- 0.21 | | epsilongc services jvmti | 499.64 +/- 0.18 | 499.69 +/- 0.52 | | epsilongc management | 450.82 +/- 0.62 | 451.38 +/- 0.59 | | epsilongc opt-size | 446.44 +/- 0.56 | 446.16 +/- 0.12 | | parallelgc | 467.23 +/- 0.19 | 466.89 +/- 0.41 | | serialgc | 454.17 +/- 0.40 | 454.22 +/- 0.12 | | epsilongc services | 453.82 +/- 0.21 | 453.59 +/- 0.51 | | shenandoahgc | 658.17 +/- 0.50 | 647.44 +/- 0.40 | [This](https://github.com/fandreuz/jdk-stuff/blob/master/script) is the script I used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3177333952 From sspitsyn at openjdk.org Tue Aug 12 03:54:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Aug 2025 03:54:12 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: On Sat, 9 Aug 2025 20:30:14 GMT, Leonid Mesnik wrote: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Thank you for catching and addressing this! How was the fix tested? It looks okay at a glance but may give surprises. ------------- PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3108454887 From lmesnik at openjdk.org Tue Aug 12 05:54:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 12 Aug 2025 05:54:19 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: On Sat, 9 Aug 2025 20:30:14 GMT, Leonid Mesnik wrote: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. I ran tier1-5 testing and separately verified that test pass with jvmti strass agent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3177804637 From duke at openjdk.org Tue Aug 12 05:58:16 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Tue, 12 Aug 2025 05:58:16 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v5] In-Reply-To: References: Message-ID: > Hello All, > > Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. > > Thank you, > -Yuri Gaevsky > > **Correctness checks:** > hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: - moved vector register declarations into vectorized_mismatch() body. - added initial support for ArrayOperationPartialInlineSize. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17750/files - new: https://git.openjdk.org/jdk/pull/17750/files/cfed55df..63410201 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=03-04 Stats: 23 lines in 5 files changed: 14 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17750/head:pull/17750 PR: https://git.openjdk.org/jdk/pull/17750 From jbhateja at openjdk.org Tue Aug 12 06:01:29 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 12 Aug 2025 06:01:29 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v5] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/405de56f..f36ae6dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Tue Aug 12 06:01:29 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 12 Aug 2025 06:01:29 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> References: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> Message-ID: On Mon, 11 Aug 2025 02:47:49 GMT, Xiaohong Gong wrote: > Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes. > Added comments. > Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT? Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator. > Do we have specific value for `origin` like zero or vlen? If so, maybe simply Identity is better to be added as well. Done, Thanks!, also added a new IR test to complement the code changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268669566 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268669731 From xgong at openjdk.org Tue Aug 12 06:01:29 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 12 Aug 2025 06:01:29 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> Message-ID: On Tue, 12 Aug 2025 05:55:14 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1714: >> >>> 1712: } >>> 1713: >>> 1714: Node* origin_node = gvn().intcon(origin->get_con() * type2aelembytes(elem_bt)); >> >> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes. >> >> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such requirement. WDYT? > >> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes. >> > > Added comments. > >> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT? > > Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator. Thanks for your updating! So maybe the matcher function `supports_vector_slice_with_non_constant_index()` could also be removed totally? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268675021 From duke at openjdk.org Tue Aug 12 06:02:29 2025 From: duke at openjdk.org (Cheng Pan) Date: Tue, 12 Aug 2025 06:02:29 GMT Subject: RFR: 8318706: Implement JEP 423: Region Pinning for G1 [v10] In-Reply-To: References: <1-i3-5OmZbuCNUlpfv31Kr3eiBXEd4Si8F5gsbPHuBQ=.1d97dcac-4662-4482-842c-ce86315ba61a@github.com> Message-ID: On Wed, 29 Nov 2023 10:02:31 GMT, Thomas Schatzl wrote: >> Marked as reviewed by ayang (Reviewer). > > Thanks @albertnetymk @kstefanj @walulyai for your reviews! Given that the JEP is now targeted, I will integrate. > > This has been a fairly long journey until today... :) @tschatzl thanks for your excellent work! I know that JEP 423 targets JDK 22, but I wonder if this can be backported to JDK 21. For big data workloads like Apache Spark, we do see that G1 generally performs better than other GC algorithms, but one major issue is that it heavily uses JNI for compression/decompression (e.g. [zstd-jni](https://github.com/luben/zstd-jni/issues/346)), thus easy to OOM. I have tested some internal Spark jobs, which were easy to OOM on JDK 21, work well on JDK 22, but given that JDK 22 has been EOL, I would appreciate it if this could be landed on JDK 21 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16342#issuecomment-3177810965 From adinn at openjdk.org Tue Aug 12 07:51:13 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 07:51:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Wed, 30 Jul 2025 17:34:48 GMT, Andrew Haley wrote: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... src/hotspot/os/bsd/os_bsd.cpp line 821: > 819: // Avoiding excessive CAS operations to hot RW locations is critical. > 820: // See https://blogs.oracle.com/dave/entry/cas_and_cache_trivia_invalidate > 821: // https://web.archive.org/web/20131214182431/https://blogs.oracle.com/dave/entry/cas_and_cache_trivia_invalidate Something is wrong here. Do we need both the original URL and the wayback machine link? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2268996730 From burban at openjdk.org Tue Aug 12 07:51:13 2025 From: burban at openjdk.org (Bernhard Urban-Forster) Date: Tue, 12 Aug 2025 07:51:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <41xWQ3Xvg5mBCvdur_fGGNJyuqXkl3HAzuT705oX9NM=.70100e04-b99d-4232-ba04-6a20dc62a6ca@github.com> On Wed, 30 Jul 2025 17:34:48 GMT, Andrew Haley wrote: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 537: > 535: } > 536: > 537: #ifdef __APPLE__ Suggestion: #ifdef MACOS_W_XOR_X ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269000738 From jsjolen at openjdk.org Tue Aug 12 07:53:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 12 Aug 2025 07:53:58 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v2] In-Reply-To: References: Message-ID: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: What does the test think about this sorting? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26729/files - new: https://git.openjdk.org/jdk/pull/26729/files/fa1794d0..c7ce8dea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=00-01 Stats: 87 lines in 29 files changed: 42 ins; 45 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729 PR: https://git.openjdk.org/jdk/pull/26729 From aph at openjdk.org Tue Aug 12 07:58:04 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 07:58:04 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp Co-authored-by: Bernhard Urban-Forster ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/b9709363..df402a45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Tue Aug 12 07:58:05 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 07:58:05 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:46:55 GMT, Andrew Dinn wrote: > Something is wrong here. Do we need both the original URL and the wayback machine link? I guess not. The original link is (very) dead, but I'm not sure how stable archive.org links are. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269010486 From burban at openjdk.org Tue Aug 12 07:58:06 2025 From: burban at openjdk.org (Bernhard Urban-Forster) Date: Tue, 12 Aug 2025 07:58:06 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <43yDEnGr5BeprhNzSr7k2081hI5P4f77FdLojqBWiXE=.1655da99-7bda-482d-8137-d47eced82f2e@github.com> On Tue, 12 Aug 2025 07:54:54 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 265: > 263: // is called by the signal handler at arbitrary point of > 264: // execution. > 265: ThreadWXEnable wx(WXWrite, thread); Having this done by default is a bit scary. How about adding a flag to enable it e.g. with `-XX:+WXHealing` and error out here if not enabled, with a helpful message that mentions the option to enable WX healing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269007734 From aph at openjdk.org Tue Aug 12 07:58:07 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 07:58:07 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <43yDEnGr5BeprhNzSr7k2081hI5P4f77FdLojqBWiXE=.1655da99-7bda-482d-8137-d47eced82f2e@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <43yDEnGr5BeprhNzSr7k2081hI5P4f77FdLojqBWiXE=.1655da99-7bda-482d-8137-d47eced82f2e@github.com> Message-ID: On Tue, 12 Aug 2025 07:51:43 GMT, Bernhard Urban-Forster wrote: > Having this done by default is a bit scary. It's not new, it's just been moved a bit later. > How about adding a flag to enable it e.g. with `-XX:+WXHealing` and error out here if not enabled, with a helpful message that mentions the option to enable WX healing? It's not really connected with healing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269015548 From vyazici at openjdk.org Tue Aug 12 08:17:59 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 12 Aug 2025 08:17:59 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v8] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Thu, 17 Jul 2025 13:58:32 GMT, Raffaello Giulietti wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace casting with `as_Region()` in `generate_string_range_check` > > src/java.base/share/classes/java/lang/StringCoding.java line 130: > >> 128: *

>> 129: * This method assumes that {@code sa} is encoded in UTF-16, and hence, >> 130: * each {@code char} maps to 2 bytes. > > Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph? @rgiulietti, gave it some more thought, and I think you're right, this is probably just noise. Removed in d5aabf0c62a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2269064538 From vyazici at openjdk.org Tue Aug 12 08:17:58 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 12 Aug 2025 08:17:58 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > ... Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Remove `@apiNote` in `encodeISOArray()` Javadoc Those who are touching to these methods should well be aware of the details elaborated in the `@apiNote`, no need to put it on a display. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25998/files - new: https://git.openjdk.org/jdk/pull/25998/files/9b721bb9..d5aabf0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=13-14 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998 PR: https://git.openjdk.org/jdk/pull/25998 From burban at openjdk.org Tue Aug 12 08:34:15 2025 From: burban at openjdk.org (Bernhard Urban-Forster) Date: Tue, 12 Aug 2025 08:34:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <43yDEnGr5BeprhNzSr7k2081hI5P4f77FdLojqBWiXE=.1655da99-7bda-482d-8137-d47eced82f2e@github.com> Message-ID: <9Xaqecl6MGDevKu_HxWr7stvIpmdA-9I8zLiMEp8eW0=.de649a5f-9f61-4a18-83c0-e17589bbb034@github.com> On Tue, 12 Aug 2025 07:54:38 GMT, Andrew Haley wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 265: >> >>> 263: // is called by the signal handler at arbitrary point of >>> 264: // execution. >>> 265: ThreadWXEnable wx(WXWrite, thread); >> >> Having this done by default is a bit scary. How about adding a flag to enable it e.g. with `-XX:+WXHealing` and error out here if not enabled, with a helpful message that mentions the option to enable WX healing? > >> Having this done by default is a bit scary. > > It's not new, it's just been moved a bit later. > >> How about adding a flag to enable it e.g. with `-XX:+WXHealing` and error out here if not enabled, with a helpful message that mentions the option to enable WX healing? > > It's not really connected with healing. Sorry, my comment was meant for the block handling `SIGBUS`. I guess the argument why it's safer than e.g. the previous approach in https://github.com/openjdk/jdk/pull/18762/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40, is that the transition is only done if the WX state is already "armed". Sounds okay to have this on by default, so disregard my initial comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269107697 From sspitsyn at openjdk.org Tue Aug 12 08:53:18 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Aug 2025 08:53:18 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v8] In-Reply-To: <733zJmz4QYLOKTZ5lU1rp13UvWeJaQ7fesb5cBmLFr8=.8a9f7720-fec8-4c84-8cd7-7b04c6b74dd2@github.com> References: <733zJmz4QYLOKTZ5lU1rp13UvWeJaQ7fesb5cBmLFr8=.8a9f7720-fec8-4c84-8cd7-7b04c6b74dd2@github.com> Message-ID: <0rVOOyK81m9nk1SUlvCi9br-ZSC1QnX5kBHc6GJ1HV8=.e32716e1-0e74-4b52-81b7-980785d5969d@github.com> On Wed, 6 Aug 2025 19:12:31 GMT, Alex Menkov wrote: >> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. >> >> Testing: tier1..5 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/classfile/javaClasses.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> This looks good to me. I've posted one nit though. src/hotspot/share/classfile/javaClasses.cpp line 1906: > 1904: GrowableArray* _bcis; > 1905: > 1906: GetStackTraceHandshakeClosure(Handle thread_oop) : Nit: I'd suggest to rename: `thread_oop` => `thread_h` ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-3109335046 PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2269158840 From tschatzl at openjdk.org Tue Aug 12 09:05:43 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Aug 2025 09:05:43 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v47] In-Reply-To: References: Message-ID: <8MXGEs7h-FkEkdBqBvzmyaV0yIQS-w2w3VV4nIrqtoI=.90d71538-ac03-479f-9772-d256703bb1a9@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into pull/23739 - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 54 more: https://git.openjdk.org/jdk/compare/5a442197...7fe518ec ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=46 Stats: 7108 lines in 112 files changed: 2582 ins; 3587 del; 939 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From adinn at openjdk.org Tue Aug 12 09:14:16 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 09:14:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/share/code/codeBlob.cpp line 397: > 395: > 396: BufferBlob* BufferBlob::create(const char* name, uint buffer_size) { > 397: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); I'm not sure why write has to be enabled here when it is not needed in any of the other create methods. The new operation below will call CodeCache::allocate (just as happens with with, say, VtableBlob::create). So, why is that not enough? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269212625 From akozlov at openjdk.org Tue Aug 12 09:18:15 2025 From: akozlov at openjdk.org (Anton Kozlov) Date: Tue, 12 Aug 2025 09:18:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Mon, 11 Aug 2025 15:59:40 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > >> ### Progress >> >> * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> >> * [x] Change must not contain extraneous whitespace >> >> * [x] Commit message must refer to an issue >> >> >> ### Error >> >> ?? The pull request body must not be empty. >> ### Integration blocker >> >> ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) >> ### Issue >> >> * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. >> >> >> ### Reviewing >> Using `git` >> >> Using Skara CLI tools >> >> Using diff file > > > >> ### Progress >> >> * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> >> * [x] Change must not contain extraneous whitespace >> >> * [x] Commit message must refer to an issue >> >> >> ### Error >> >> ?? The pull request body must not be empty. >> ### Integration blocker >> >> ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) >> ### Issue >> >> * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. >> >> >> ### Reviewing >> Using `git` >> >> Using Skara CLI tools >> >> Using diff file @theRealAph Thank you so much for taking care of this! The combination of "healing" and "markers" could be the most optimal way to implement W^X transitions, it's great to see it implemented. On the start-up time, do you see the combination of healing+markers outperforms just healing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3178475021 From duke at openjdk.org Tue Aug 12 09:21:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 09:21:28 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v6] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Introduced replace_if_null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/094eb14a..75aee91d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=04-05 Stats: 11 lines in 2 files changed: 3 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From duke at openjdk.org Tue Aug 12 09:21:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 09:21:28 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Thu, 7 Aug 2025 07:34:50 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments I think we have 2 orthogonal problems here: 1) We want to make a value stored in that global variables to be visible to all threads. 2) We may have multiple updates of that value cause by (theoretically) more than one thread timed out. I came to conclusion that the 1st issue is not an issue, as signal firing and receiving is very heavy compared by a simple store to a variable. One can safely assume that by the time the signal is received on the target thread the memory operation has been already finished and the value will be visible. Hence we do not need a fence. We may have it, but it is not a must. The 2nd issue has more a hypothetical one. If we ever see more than one thread timing out, the variable keeping the thread address of the timed out thread will be updated more than once. More than one signal will be sent. But, as the comment on top of `VMError::report()` says, "Only one thread can call this function, so we don't need to worry about MT-safety." And we do not know which thread will execute this method anyway. Therefore, I suggest to use `Atomic::replace_if_null()` in the setter with the default (conservative) memory order. This will discard all updates except the 1st one and give us fences addressing the 1st not-really-an-issue. In case of a mismatch between the reporting thread and the thread stored in the variable we fall back to default reporting, but I think it will be an extremely rare case. I also brought back the `volatile` keyword for indicative purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3178476744 From adinn at openjdk.org Tue Aug 12 09:25:16 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 09:25:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <5m-kowi6UhJtFdlKycGvc9vQ4SyjvsIToSROYPAO2vI=.c620c11b-ac93-41f4-be1c-3771aa39600d@github.com> On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/share/code/nmethod.cpp line 2394: > 2392: > 2393: bool nmethod::is_unloading() { > 2394: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); This is very opaque. Why is the write enable placed here rather than lower down where we drop past the return true and return false cases and potentially start monkeying around with state updates? Currently, it looks as if the fact that a caller has tested the state may imply that said caller might write to the nmethod even when we determine the state via the first two checks. Is that really true? If so then an explanation as to why would be highly appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269246068 From duke at openjdk.org Tue Aug 12 09:29:06 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 09:29:06 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v7] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Fixed whitespace error. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/75aee91d..07bc86a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From adinn at openjdk.org Tue Aug 12 09:36:12 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 09:36:12 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/share/runtime/interfaceSupport.inline.hpp line 288: > 286: static WXMode wx_mode = DefaultWXWriteMode; \ > 287: ThreadWXEnable __wx(&wx_mode, current); \ > 288: ) \ Why plant the WXEnable before the thread transition here when it is placed after the thread transition in the NO_ASYNC macro? Why not after in both? Likewise in later occurrences what governs the placement? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269268076 From adinn at openjdk.org Tue Aug 12 09:43:13 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 09:43:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/share/runtime/threadWXSetters.inline.hpp line 38: > 36: > 37: class ThreadWXEnable { > 38: Thread *_thread; * needs to be attached to type not field here and below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269294121 From adinn at openjdk.org Tue Aug 12 09:53:15 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 09:53:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/share/runtime/threads.cpp line 599: > 597: } > 598: > 599: MACOS_AARCH64_ONLY(os::current_thread_enable_wx(WXWrite)); I think for clarity this call should really precede the call to init_globals() a few lines up. That function calls, amongst other things, codeCache_init() then VM_Version_init() and the latter may need to write into the code cache for some architectures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269319279 From aph at openjdk.org Tue Aug 12 09:58:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 09:58:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 09:11:24 GMT, Andrew Dinn wrote: > I'm not sure why write has to be enabled here when it is not needed in any of the other create methods. The new operation below will call CodeCache::allocate (just as happens with with, say, VtableBlob::create). So, why is that not enough? I have no idea, I've never tried! I'll give that a spin. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269330715 From shade at openjdk.org Tue Aug 12 10:02:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Aug 2025 10:02:16 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v7] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <0OZAOSLaBzWpvdI5HDAL-m3EM00dz8NihXVG0iAjSfo=.02d47d14-2167-41e7-b955-0fea147925dd@github.com> On Tue, 12 Aug 2025 09:29:06 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Fixed whitespace error. OK, this looks more straight-forward. I would still prefer to see `Atomic::load` (can be without acquire) for loads on reader side to match the `Atomic` RMW on writer side. This would give us at least coherency for the load. ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3109698132 From ayang at openjdk.org Tue Aug 12 10:12:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 10:12:13 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 12 Aug 2025 09:16:21 GMT, Anton Artemov wrote: > I think we have 2 orthogonal problems here: I was aware of only the first one. Thank you for the clarification. Conventionally, the `Atomic::X` is used to access `volatile` vars, so the getters should be updated as well. > I came to conclusion that the 1st issue is not an issue, as signal firing and receiving is very heavy compared by a simple store to a variable. Maybe such "heavy" operation contains enough instructions that CPU doesn't/couldn't reorder the important read... Just to be explicit, the following is the problematic scenario I had in mind, and I assume it's the same one Aleksey talked about.

litmus source C signal { [x] = 0; [y] = 0; } P0 (atomic_int* x, atomic_int* y) { atomic_store_explicit(x, 1, memory_order_relaxed); atomic_thread_fence(memory_order_seq_cst); atomic_store_explicit(y, 1, memory_order_seq_cst); } P1 (atomic_int* x, atomic_int* y) { r0 = atomic_load_explicit(y, memory_order_relaxed); // required to prevent loading-x from floating up atomic_thread_fence(memory_order_acquire); if (r0 == 1) { r1 = atomic_load_explicit(x, memory_order_relaxed); } } exists ( true /\ 1:r0 == 1 /\ 1:r1 == 0 )
`herd7 -c11 -cat rc11.cat signal.litmus` shows that the `acquire`-fence on the reader side is necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3178683893 From aph at openjdk.org Tue Aug 12 10:12:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 10:12:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <9Xaqecl6MGDevKu_HxWr7stvIpmdA-9I8zLiMEp8eW0=.de649a5f-9f61-4a18-83c0-e17589bbb034@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <43yDEnGr5BeprhNzSr7k2081hI5P4f77FdLojqBWiXE=.1655da99-7bda-482d-8137-d47eced82f2e@github.com> <9Xaqecl6MGDevKu_HxWr7stvIpmdA-9I8zLiMEp8eW0=.de649a5f-9f61-4a18-83c0-e17589bbb034@github.com> Message-ID: <_WvbB_CAqnD4xBE6oj_R4dtoSBN6eKlOUR438Jbk6Uo=.4aa4b6af-6e69-4b74-b92a-dfc1bc815cbe@github.com> On Tue, 12 Aug 2025 08:31:09 GMT, Bernhard Urban-Forster wrote: > Sorry, my comment was meant for the block handling `SIGBUS`. > > I guess the argument why it's safer than e.g. the previous approach in https://github.com/openjdk/jdk/pull/18762/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40, is that the transition is only done if the WX state is already "armed". Yes, exactly. The transition is only done once, and only if WX would otherwise have been set to true already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269366559 From aph at openjdk.org Tue Aug 12 10:12:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 10:12:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> On Tue, 12 Aug 2025 09:31:50 GMT, Andrew Dinn wrote: > Why plant the WXEnable before the thread transition here when it is placed after the thread transition in the NO_ASYNC macro? Why not after in both? OK. > Likewise in later occurrences what governs the placement? The process of discovering the sweet spots we entirely empirical, not analytical. > * needs to be attached to type not field here and below. I'm afraid this is against the guidelines. At least that is what I've been told, but I can't find it in the guidelines, so maybe that isn't true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269365076 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269361273 From adinn at openjdk.org Tue Aug 12 10:24:15 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 10:24:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> Message-ID: <4paL_6pij2g1Wt30YKY8140rtQVuilhjNBdOz_xjYPs=.0c0a36fe-e05d-4401-b6ba-53f0c5601d10@github.com> On Tue, 12 Aug 2025 10:09:11 GMT, Andrew Haley wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 288: >> >>> 286: static WXMode wx_mode = DefaultWXWriteMode; \ >>> 287: ThreadWXEnable __wx(&wx_mode, current); \ >>> 288: ) \ >> >> Why plant the WXEnable before the thread transition here when it is placed after the thread transition in the NO_ASYNC macro? Why not after in both? >> >> Likewise in later occurrences what governs the placement? > >> Why plant the WXEnable before the thread transition here when it is placed after the thread transition in the NO_ASYNC macro? Why not after in both? > > OK. > >> Likewise in later occurrences what governs the placement? > > The process of discovering the sweet spots we entirely empirical, not analytical. I don't believe the order is going to matter (tell me if I am wrong) but I think it would be better to order them consistently, not just because I am a 'typical computer programmer' but because someone might be puzzled as to whether the re-ordering is significant (ok, yes, I guess that 'someone' would be a 'typical computer programmer' or maybe just me). I suggested both after because the async thread transition has a bail out and we might as well bail early . . . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269395398 From adinn at openjdk.org Tue Aug 12 10:30:16 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 12 Aug 2025 10:30:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> Message-ID: On Tue, 12 Aug 2025 10:07:42 GMT, Andrew Haley wrote: >> src/hotspot/share/runtime/threadWXSetters.inline.hpp line 38: >> >>> 36: >>> 37: class ThreadWXEnable { >>> 38: Thread *_thread; >> >> * needs to be attached to type not field here and below. > >> * needs to be attached to type not field here and below. > > I'm afraid this is against the guidelines. At least that is what I've been told, but I can't find it in the guidelines, so maybe that isn't true. No, it's not explicitly stated in the [guidelines](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md) but it is adopted 'almost everywhere' in the code base. Likewise with reference parameter declarations the '&' attaches to the type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269408869 From jsjolen at openjdk.org Tue Aug 12 10:45:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 12 Aug 2025 10:45:09 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v3] In-Reply-To: References: Message-ID: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: This should be preferred ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26729/files - new: https://git.openjdk.org/jdk/pull/26729/files/c7ce8dea..4e143035 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=01-02 Stats: 36 lines in 16 files changed: 18 ins; 16 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729 PR: https://git.openjdk.org/jdk/pull/26729 From ihse at openjdk.org Tue Aug 12 10:52:23 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 12 Aug 2025 10:52:23 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - magic number: 400 > - inline Can you re-run the test with your updated and more stable testing setup with a default, out-of-the-box configured `server` variant, comparing the baseline PCH file with your updated one? Your updated result seemed more reliable and probable, but they also do not differ that much from the baseline. I still saw a few improvements and no regression, so it might still be worth pursuing, but maybe your suggested change does not bring as much improvement as was first hinted at. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3178797213 PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3178802150 From duke at openjdk.org Tue Aug 12 11:32:42 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 12 Aug 2025 11:32:42 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: References: Message-ID: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - conditional includes - variants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/be25d341..c0b8c277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=09-10 Stats: 119 lines in 2 files changed: 114 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From ayang at openjdk.org Tue Aug 12 11:56:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 11:56:19 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve robustness src/hotspot/os/linux/os_linux.cpp line 4953: > 4951: // to detach itself from the VM - which should result in ESRCH. > 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); > 4953: log_warning(os)("Could not sample thread CPU time"); Maybe diff msgs can be printed so that we know better what went wrong if `-1` is returned. src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > 608: } > 609: > 610: double calc_usage(double component_cpu_time, double process_cpu_time) { Could `percent_of` be used instead? src/hotspot/share/gc/shared/collectedHeap.cpp line 627: > 625: > 626: LogTarget(Info, cpu) cpuLog; > 627: if (cpuLog.is_enabled()) { Can use early-return to reduce one indentation level. src/hotspot/share/gc/shared/collectedHeap.hpp line 468: > 466: virtual void gc_threads_do(ThreadClosure* tc) const = 0; > 467: > 468: jlong elapsed_gc_cpu_time() const; Seems unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269575257 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269582730 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269586175 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269589768 From jsjolen at openjdk.org Tue Aug 12 12:02:13 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 12 Aug 2025 12:02:13 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4] In-Reply-To: References: Message-ID: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Found the instructions for how to run the script in the error log ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26729/files - new: https://git.openjdk.org/jdk/pull/26729/files/4e143035..5c58e011 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=02-03 Stats: 20 lines in 7 files changed: 10 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729 PR: https://git.openjdk.org/jdk/pull/26729 From duke at openjdk.org Tue Aug 12 12:07:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 12:07:53 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v7] In-Reply-To: <0OZAOSLaBzWpvdI5HDAL-m3EM00dz8NihXVG0iAjSfo=.02d47d14-2167-41e7-b955-0fea147925dd@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> <0OZAOSLaBzWpvdI5HDAL-m3EM00dz8NihXVG0iAjSfo=.02d47d14-2167-41e7-b955-0fea147925dd@github.com> Message-ID: On Tue, 12 Aug 2025 09:59:04 GMT, Aleksey Shipilev wrote: > OK, this looks more straight-forward. I would still prefer to see `Atomic::load` (can be without acquire) for loads on reader side to match the `Atomic` RMW on writer side. This would give us at least coherency for the load. Okay, I added `Atomic::load()` where necessary to support coherency, although, first of all, it is not the case in a significant number of places in the codebase for `cmpxchg`, and, second of all, I do think it is not needed in **this particular case**. We do not need atomicity here as there is no possible concurrent mutation of that value, as there can be only one such, which **happed before** the read happens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3179037773 From duke at openjdk.org Tue Aug 12 12:07:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 12:07:53 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Added atomic loads to getters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/07bc86a2..b833bf5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From shade at openjdk.org Tue Aug 12 12:16:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Aug 2025 12:16:14 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 12 Aug 2025 12:07:53 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Added atomic loads to getters Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3110297701 From duke at openjdk.org Tue Aug 12 12:24:15 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 12 Aug 2025 12:24:15 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 12 Aug 2025 10:09:08 GMT, Albert Mingkun Yang wrote: > Conventionally, the `Atomic::X` is used to access `volatile` vars, so the getters should be updated as well. I do not think so, getters return a copy of the thread's address. > Maybe such "heavy" operation contains enough instructions that CPU doesn't/couldn't reorder the important read... Just to be explicit, the following is the problematic scenario I had in mind, and I assume it's the same one Aleksey talked about. I am not familiar with herd7 tool and with ARM nuances, but I do not think the example is relevant. This scenario cannot be applied to **this particular case**, as we never will have update of the value happening concurrently with the read, as there is a expensive operation between the two. Let's not overengineer the solution for this failing code path. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3179096986 From duke at openjdk.org Tue Aug 12 12:24:35 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 12 Aug 2025 12:24:35 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Feedback from Albert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/3f552362..143fcacb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=03-04 Stats: 34 lines in 3 files changed: 2 ins; 7 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Tue Aug 12 12:24:37 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 12 Aug 2025 12:24:37 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v4] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Improve robustness Thanks for the review @albertnetymk! I pushed changes reflecting your feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3179095971 From duke at openjdk.org Tue Aug 12 12:30:18 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 12 Aug 2025 12:30:18 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v10] In-Reply-To: References: Message-ID: <8AAOto8QChuSmsPAhI98ld31aUpETaWhOL27HCnUPOg=.f2d82805-0d57-4aea-b2b1-646cd3296fb5@github.com> On Tue, 12 Aug 2025 10:49:19 GMT, Magnus Ihse Bursie wrote: > Your updated result seemed more reliable and probable, but they also do not differ that much from the baseline. I still saw a few improvements and no regression, so it might still be worth pursuing, but maybe your suggested change does not bring as much improvement as was first hinted at. I'd say individual improvements are a bit harder to observe in the kind of measurements I'm doing now, and the likelihood of measuring noise is higher. Also, the minimum inclusion threshold I'm using now is the same for all features, but that's unlikely to be optimal. Maybe we could revert to the original approach (count inclusion for a typical build)? That proved to improve compile time, and I could hide non-standard headers behind an `#if`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3179118681 From duke at openjdk.org Tue Aug 12 12:35:13 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Tue, 12 Aug 2025 12:35:13 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 05:58:16 GMT, Yuri Gaevsky wrote: >> Hello All, >> >> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. >> >> Thank you, >> -Yuri Gaevsky >> >> **Correctness checks:** >> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. > > Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: > > - moved vector register declarations into vectorized_mismatch() body. > - added initial support for ArrayOperationPartialInlineSize. Changeset `6341020` (BPI-F3 16g): ============================================================================================================================= | -UseRVV | +UseRVV (m1) | +UseRVV (m2) | +UseRVV (m4) | +UseRVV (m8) | ============================================================================================================================= Int.mismatchEnd 5 avgt 30 13.176 ? 0.016 13.154 ? 0.003 13.185 ? 0.018 13.157 ? 0.005 13.155 ? 0.003 ns/op Int.mismatchEnd 8 avgt 30 29.410 ? 0.272 32.821 ? 0.362 35.331 ? 0.383 41.645 ? 0.153 55.595 ? 1.066 ns/op Int.mismatchEnd 16 avgt 30 37.623 ? 0.421 46.344 ? 0.006 35.368 ? 0.358 41.687 ? 0.148 54.483 ? 0.007 ns/op Int.mismatchEnd 32 avgt 30 57.399 ? 0.444 72.661 ? 0.024 50.619 ? 0.808 41.764 ? 0.192 54.265 ? 0.161 ns/op Int.mismatchEnd 40 avgt 30 66.177 ? 0.279 85.869 ? 0.048 64.599 ? 1.164 62.919 ? 0.702 53.939 ? 0.356 ns/op Int.mismatchEnd 50 avgt 30 75.398 ? 0.198 95.191 ? 0.014 65.218 ? 0.077 62.627 ? 0.013 53.862 ? 0.008 ns/op Int.mismatchEnd 64 avgt 30 95.176 ? 0.558 121.951 ? 3.239 81.017 ? 1.581 63.682 ? 0.310 53.703 ? 0.379 ns/op ----------------------------------------------------------------------------------------------------------------------------- Int.mismatchMid 5 avgt 30 28.893 ? 0.079 33.316 ? 0.075 36.333 ? 0.009 42.867 ? 0.963 59.605 ? 0.106 ns/op Int.mismatchMid 8 avgt 30 25.275 ? 0.154 33.226 ? 0.026 36.343 ? 0.011 43.961 ? 0.040 58.947 ? 0.645 ns/op Int.mismatchMid 16 avgt 30 34.135 ? 0.560 46.345 ? 0.007 34.921 ? 0.447 41.443 ? 0.307 55.132 ? 1.252 ns/op Int.mismatchMid 32 avgt 30 42.832 ? 0.156 59.564 ? 0.064 51.378 ? 0.008 42.631 ? 0.646 54.488 ? 0.012 ns/op Int.mismatchMid 40 avgt 30 47.237 ? 0.233 58.246 ? 1.199 50.526 ? 0.809 41.827 ? 0.127 54.509 ? 0.026 ns/op Int.mismatchMid 50 avgt 30 52.497 ? 0.208 72.730 ? 0.065 50.539 ? 0.803 41.027 ? 0.228 54.484 ? 0.010 ns/op Int.mismatchMid 64 avgt 30 62.040 ? 0.316 85.900 ? 0.070 65.797 ? 1.179 63.050 ? 0.796 54.285 ? 0.187 ns/op ----------------------------------------------------------------------------------------------------------------------------- Int.mismatchStart 5 avgt 30 29.101 ? 0.176 32.602 ? 0.019 35.125 ? 0.031 42.606 ? 0.612 58.884 ? 0.031 ns/op Int.mismatchStart 8 avgt 30 28.884 ? 0.071 33.223 ? 0.018 35.740 ? 0.033 43.837 ? 0.006 58.016 ? 1.691 ns/op Int.mismatchStart 16 avgt 30 28.845 ? 0.044 33.205 ? 0.010 36.400 ? 0.040 42.792 ? 1.004 59.635 ? 0.100 ns/op Int.mismatchStart 32 avgt 30 28.852 ? 0.082 32.790 ? 0.397 35.706 ? 0.010 41.960 ? 0.006 54.334 ? 0.144 ns/op Int.mismatchStart 40 avgt 30 29.137 ? 0.295 32.787 ? 0.392 35.294 ? 0.404 41.956 ? 0.011 55.855 ? 1.753 ns/op Int.mismatchStart 50 avgt 30 29.543 ? 0.359 32.611 ? 0.034 35.144 ? 0.076 41.391 ? 0.059 55.545 ? 1.604 ns/op Int.mismatchStart 64 avgt 30 28.988 ? 0.112 32.786 ? 0.403 35.748 ? 0.053 43.089 ? 0.773 54.114 ? 0.192 ns/op ============================================================================================================================= Byte.mismatchEnd 5 avgt 30 17.567 ? 0.043 18.193 ? 0.027 17.959 ? 0.199 18.221 ? 0.035 17.870 ? 0.184 ns/op Byte.mismatchEnd 8 avgt 30 22.356 ? 0.390 35.551 ? 1.248 38.292 ? 1.557 44.816 ? 1.372 63.172 ? 0.025 ns/op Byte.mismatchEnd 16 avgt 30 29.471 ? 0.396 35.766 ? 1.125 38.635 ? 1.098 47.061 ? 1.024 63.978 ? 0.115 ns/op Byte.mismatchEnd 32 avgt 30 35.606 ? 0.352 35.006 ? 1.269 38.867 ? 1.013 44.779 ? 1.354 58.762 ? 0.061 ns/op Byte.mismatchEnd 40 avgt 30 36.299 ? 0.233 49.543 ? 0.068 39.384 ? 0.069 45.629 ? 0.052 58.155 ? 0.058 ns/op Byte.mismatchEnd 50 avgt 30 40.831 ? 0.400 48.221 ? 1.205 38.515 ? 1.186 44.252 ? 1.380 59.907 ? 1.547 ns/op Byte.mismatchEnd 64 avgt 30 50.740 ? 0.269 49.471 ? 1.201 38.981 ? 1.240 43.970 ? 1.056 57.533 ? 1.517 ns/op ----------------------------------------------------------------------------------------------------------------------------- Byte.mismatchMid 5 avgt 30 30.346 ? 1.820 28.527 ? 1.364 28.992 ? 1.322 28.991 ? 1.782 29.945 ? 1.755 ns/op Byte.mismatchMid 8 avgt 30 21.933 ? 0.023 36.217 ? 1.245 37.457 ? 1.231 48.120 ? 0.046 63.750 ? 0.021 ns/op Byte.mismatchMid 16 avgt 30 29.273 ? 0.146 35.789 ? 1.262 38.637 ? 1.210 44.467 ? 1.936 60.595 ? 3.065 ns/op Byte.mismatchMid 32 avgt 30 27.632 ? 0.558 36.155 ? 1.253 39.978 ? 0.541 46.168 ? 1.093 60.817 ? 1.509 ns/op Byte.mismatchMid 40 avgt 30 28.596 ? 0.400 37.000 ? 0.404 38.030 ? 1.664 47.003 ? 1.031 62.470 ? 1.401 ns/op Byte.mismatchMid 50 avgt 30 35.171 ? 0.468 37.034 ? 0.428 39.550 ? 0.404 45.030 ? 0.958 57.389 ? 0.989 ns/op Byte.mismatchMid 64 avgt 30 35.879 ? 0.672 49.512 ? 1.219 39.994 ? 0.047 44.351 ? 1.392 57.130 ? 2.729 ns/op ----------------------------------------------------------------------------------------------------------------------------- Byte.mismatchStart 5 avgt 30 29.944 ? 1.876 30.086 ? 1.849 31.777 ? 0.808 30.560 ? 2.040 29.034 ? 1.821 ns/op Byte.mismatchStart 8 avgt 30 22.159 ? 0.219 34.091 ? 1.294 38.037 ? 1.270 44.722 ? 1.341 58.877 ? 2.451 ns/op Byte.mismatchStart 16 avgt 30 21.942 ? 0.021 34.797 ? 1.349 38.725 ? 1.277 46.050 ? 0.997 58.949 ? 0.664 ns/op Byte.mismatchStart 32 avgt 30 22.166 ? 0.188 33.611 ? 1.230 40.017 ? 0.084 47.512 ? 0.643 63.875 ? 0.039 ns/op Byte.mismatchStart 40 avgt 30 21.936 ? 0.013 34.460 ? 1.151 38.701 ? 1.280 46.868 ? 0.605 63.365 ? 0.120 ns/op Byte.mismatchStart 50 avgt 30 22.136 ? 0.198 34.251 ? 1.299 37.158 ? 1.409 44.893 ? 1.654 61.724 ? 1.344 ns/op Byte.mismatchStart 64 avgt 30 21.953 ? 0.037 34.875 ? 1.244 39.218 ? 1.389 48.289 ? 0.062 61.671 ? 2.012 ns/op ============================================================================================================================= ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3179138714 From aph at openjdk.org Tue Aug 12 12:50:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 12:50:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> Message-ID: On Tue, 12 Aug 2025 10:27:24 GMT, Andrew Dinn wrote: >>> * needs to be attached to type not field here and below. >> >> I'm afraid this is against the guidelines. At least that is what I've been told, but I can't find it in the guidelines, so maybe that isn't true. > > No, it's not explicitly stated in the [guidelines](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md) but it is adopted 'almost everywhere' in the code base. Likewise with reference parameter declarations the '&' attaches to the type. Ah, I see. I mistakenly thought the snippet above was a suggestion you were making... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2269733847 From mablakatov at openjdk.org Tue Aug 12 13:14:12 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Tue, 12 Aug 2025 13:14:12 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> Message-ID: <85LplXOcz4drG4k9TQo6T-iDnzxZtq1XiJPQL9HHdTg=.75f63acc-156f-482d-a0cc-afc702a6f720@github.com> On Sun, 10 Aug 2025 07:24:18 GMT, Andrew Haley wrote: > There may still be a race in set_to_clean(), which doesn't zero out the [method, entry} fields in the stub. I'd fix that, to be safe. It'd be tricky to test. It appears that `CompiledDirectCall::set_stub_to_clean` is currently unused. I would suggest either leaving it as-is or even better removing it entirely to avoid the risk of someone using it in the future since it's not safe under all conditions. For example, consider a situation when a system thread is preempted by the OS while executing a static stub. If another thread clears that static stub before the preempted thread resumes, the first thread might execute a partially cleared sequence of `movk`/`movz` instructions. Here's a simplified scenario: | Thread A | Thread B | |-|-| | `isb` | - | | `movk` | - | | `movz` | - | | PREEMPTED | Clears the static stub | | `movz` (cleared) | - | | ... | ... | ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3179283141 From aph at openjdk.org Tue Aug 12 13:45:20 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 13:45:20 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: <85LplXOcz4drG4k9TQo6T-iDnzxZtq1XiJPQL9HHdTg=.75f63acc-156f-482d-a0cc-afc702a6f720@github.com> References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> <85LplXOcz4drG4k9TQo6T-iDnzxZtq1XiJPQL9HHdTg=.75f63acc-156f-482d-a0cc-afc702a6f720@github.com> Message-ID: On Tue, 12 Aug 2025 13:11:44 GMT, Mikhail Ablakatov wrote: > > There may still be a race in set_to_clean(), which doesn't zero out the [method, entry} fields in the stub. I'd fix that, to be safe. It'd be tricky to test. > > It appears that `CompiledDirectCall::set_stub_to_clean` is currently unused. My mistake. I should have written `CompiledIC::set_to_clean()`, which is used. I would suggest either leaving it as-is or even better removing it entirely to avoid the risk of someone using it in the future since it's not safe under all conditions. > > For example, consider a situation when a system thread is preempted by the OS while executing a static stub. If another thread clears that static stub before the preempted thread resumes, the first thread might execute a partially cleared sequence of `movk`/`movz` instructions. Indeed. In fact, it's not safe to clear the stub in any case because stubs are _shared_ between calls to the same method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3179400393 From dfenacci at openjdk.org Tue Aug 12 14:03:17 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 12 Aug 2025 14:03:17 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 In-Reply-To: <0JLBGmyrRt-y1IHz5j-UYkiXutQ1FgrOqeO0gQTFhcs=.fb1ff8ce-67d9-4963-9adb-758e17b66f98@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <0JLBGmyrRt-y1IHz5j-UYkiXutQ1FgrOqeO0gQTFhcs=.fb1ff8ce-67d9-4963-9adb-758e17b66f98@github.com> Message-ID: On Mon, 11 Aug 2025 08:38:49 GMT, Ruben wrote: > I've run tier1-tier3 tests, however only on AArch64 and x86-64. I can run more tests on these platforms if that might be useful. As you've touched a few other platforms' files it might be a good idea (to be on the safe-side). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3179477981 From mablakatov at openjdk.org Tue Aug 12 14:15:15 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Tue, 12 Aug 2025 14:15:15 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: <-2nFSgxvTQDnTjG1yW-Lq1zfj5plegc9RCcplg3SWKs=.fb5feaf6-10ab-413e-bf64-eef5f3f5e8c2@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> <-2nFSgxvTQDnTjG1yW-Lq1zfj5plegc9RCcplg3SWKs=.fb5feaf6-10ab-413e-bf64-eef5f3f5e8c2@github.com> Message-ID: On Thu, 7 Aug 2025 15:52:42 GMT, Evgeny Astigeevich wrote: > There should not be any duplication. Why do you think so? `StubRoutines::aarch64::large_arrays_hashcode` is both a key and a part of the value in the example above. > I dont understand what you mean "the current approach". Do you mean using Pair and checking relocInfo::relocType? Mostly the latter. I agree that the implementation would benefit from using something more explicit instead of `Pair<>`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2269997597 From mablakatov at openjdk.org Tue Aug 12 14:27:14 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Tue, 12 Aug 2025 14:27:14 GMT Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() In-Reply-To: References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com> <85LplXOcz4drG4k9TQo6T-iDnzxZtq1XiJPQL9HHdTg=.75f63acc-156f-482d-a0cc-afc702a6f720@github.com> Message-ID: On Tue, 12 Aug 2025 13:42:04 GMT, Andrew Haley wrote: > My mistake. I should have written CompiledIC::set_to_clean(), which is used. Doesn't `CompiledIC::set_to_clean()` handle virtual call sites? If you referred to `CompiledDirectCall::set_to_clean()` instead, I believe no miscommunication happened here. What I meant is that `CompiledDirectCall::set_to_clean()` must not *zero out the [method, entry} fields in the stub* by calling `CompiledDirectCall::set_stub_to_clean()`. The latter is currently unused. Should it be removed entirely perhaps? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3179577933 From vaivanov at openjdk.org Tue Aug 12 15:02:21 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 12 Aug 2025 15:02:21 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Message-ID: On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 while for 'bad' case these metrics are MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra SRF 6740E | Size | orig | pathed | pO/orig -- | -- | -- | -- | -- ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 ArraysFill.testShortFill | 8195 | 5922.547 | 5799.964 | 0.98 ------------- Commit messages: - JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Changes: https://git.openjdk.org/jdk/pull/26747/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365290 Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From duke at openjdk.org Tue Aug 12 15:08:07 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 12 Aug 2025 15:08:07 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads Message-ID: Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. This excludes floats and doubles, as they do not have equivalent load-acquire instructions. ------------- Commit messages: - 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile loads Changes: https://git.openjdk.org/jdk/pull/26748/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26748&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365147 Stats: 120 lines in 10 files changed: 96 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/26748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26748/head:pull/26748 PR: https://git.openjdk.org/jdk/pull/26748 From duke at openjdk.org Tue Aug 12 15:11:13 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 12 Aug 2025 15:11:13 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: <9u60pD-ApmVWl93_Mwy0PZdqNx20Ntckri6tT0R9NL4=.afc13117-b4e9-43c9-a96b-77eaac438fe8@github.com> On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. Passes entire jcstress test-suite. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3179761865 From aph at openjdk.org Tue Aug 12 15:17:21 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 15:17:21 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 917: > 915: LIR_PatchCode patch_code, CodeEmitInfo* info) { > 916: if (is_floating_point_type(type)) { > 917: // Use LDAR instead of DMB+LD+DMB, except for floats/doubles (no LDAR equivalent). We need more information here. If we're using LDAR, we should `ldar x8, mem; movd dest, x8` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2270232188 From ayang at openjdk.org Tue Aug 12 15:20:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 15:20:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Albert src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > 608: } > 609: > 610: double percent_of(double component_cpu_time, double process_cpu_time) { There is global function, `percent_of`. Can that be used directly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2270240264 From mablakatov at openjdk.org Tue Aug 12 15:28:14 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Tue, 12 Aug 2025 15:28:14 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v4] In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> Message-ID: <7UNfMDlrrnlIXWOt72vfVh2MuucJCgeVo3sPcZ_cG2U=.24099dd8-8142-47ac-8189-d85f41f82b58@github.com> > Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. > > This has passed tier1-3 and jcstress testing on AArch64. Mikhail Ablakatov has updated the pull request incrementally with three additional commits since the last revision: - cleanup: update copyright headers - Make the value type of the dictionary a struct instead of Pair typedef - Remove share_rc_trampoline_for and share_sc_trampoline_for ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25954/files - new: https://git.openjdk.org/jdk/pull/25954/files/e563a2c3..9912e5c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=02-03 Stats: 34 lines in 8 files changed: 9 ins; 10 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954 PR: https://git.openjdk.org/jdk/pull/25954 From eastigeevich at openjdk.org Tue Aug 12 16:22:17 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 12 Aug 2025 16:22:17 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v3] In-Reply-To: References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <_Mianizit7riu3uwfRRkJUUMa7CDFW-HPtbjHSYXbYI=.9f1e4dd5-d3a6-4e06-aedf-152f2224ca04@github.com> <-2nFSgxvTQDnTjG1yW-Lq1zfj5plegc9RCcplg3SWKs=.fb5feaf6-10ab-413e-bf64-eef5f3f5e8c2@github.com> Message-ID: On Tue, 12 Aug 2025 14:12:23 GMT, Mikhail Ablakatov wrote: > > There should not be any duplication. Why do you think so? > > `StubRoutines::aarch64::large_arrays_hashcode` is both a key and a part of the value in the example above. An unordered set always has some duplication because it is implemented on top of hash table. If `SharedTrampolineRequests` were declared as a set, this duplication would not be exposed. I prefer code without IFs. Duplication is not a big price to pay. If you want you can add a class `SharedTrampolineRequests` with `ResizeableResourceHashtable` hidden inside. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2270482625 From aph at openjdk.org Tue Aug 12 16:36:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 16:36:10 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. That looks good, nice work. A little refactoring could make it even better. Try this: untested, but you get the idea. diff --git a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp index 2e35763aa43..3e7a285d5aa 100644 --- a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp @@ -1274,6 +1274,13 @@ class Assembler : public AbstractAssembler { sz, 0b000, ordered); } + void load_store_ordered(Register data, BasicType type, Register addr, + bool is_load) { + load_store_exclusive(dummy_reg, data, dummy_reg, addr, + (Assembler::operand_size)exact_log2(type2aelembytes(type)), + is_load ? 0b110: 0b100, 1); + } + #define INSN4(NAME, sz, op, o0) /* Four registers */ \ void NAME(Register Rs, Register Rt1, Register Rt2, Register Rn) { \ guarantee(Rs != Rn && Rs != Rt1 && Rs != Rt2, "unpredictable instruction"); \ diff --git a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp index 6ac4f5df166..0246ab61351 100644 --- a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp @@ -938,45 +938,21 @@ void LIR_Assembler::mem2reg_volatile(LIR_Opr src, LIR_Opr dest, BasicType type, int null_check_here = code_offset(); __ lea(rscratch1, as_Address(from_addr)); - switch (type) { - case T_BOOLEAN: - __ ldarb(dest->as_register(), rscratch1); - break; - case T_BYTE: // LDAR is unsigned so need to sign-extend for byte - __ ldarb(dest->as_register(), rscratch1); - __ sxtb(dest->as_register(), dest->as_register()); - break; - case T_CHAR: - __ ldarh(dest->as_register(), rscratch1); - break; - case T_SHORT: // LDAR is unsigned so need to sign-extend for short - __ ldarh(dest->as_register(), rscratch1); - __ sxth(dest->as_register(), dest->as_register()); - break; - case T_INT: - __ ldarw(dest->as_register(), rscratch1); - break; - case T_ADDRESS: - __ ldar(dest->as_register(), rscratch1); - break; - case T_LONG: - __ ldar(dest->as_register_lo(), rscratch1); - break; - case T_ARRAY: - case T_OBJECT: - if (UseCompressedOops) { - __ ldarw(dest->as_register(), rscratch1); - } else { - __ ldar(dest->as_register(), rscratch1); - } - break; - case T_METADATA: - // We get here to store a method pointer to the stack to pass to - // a dtrace runtime call. This can't work on 64 bit with - // compressed klass ptrs: T_METADATA can be a compressed klass - // ptr or a 64 bit method pointer. - default: - ShouldNotReachHere(); + Register dest_reg = (dest->is_single_cpu() + ? dest->as_register() : dest->as_register_lo()); + __ load_store_ordered(dest_reg, type, rscratch1, /*is_load*/true); + + if (is_signed_subword_type(type)) { + switch (type) { + case T_BYTE: // LDAR is unsigned so need to sign-extend for byte + __ sxtb(dest_reg, dest_reg); + break; + case T_SHORT: // LDAR is unsigned so need to sign-extend for short + __ sxth(dest_reg, dest_reg); + break; + default: + ShouldNotReachHere(); + } } if (is_reference_type(type)) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3180149720 From duke at openjdk.org Tue Aug 12 16:40:15 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Tue, 12 Aug 2025 16:40:15 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 05:58:16 GMT, Yuri Gaevsky wrote: >> Hello All, >> >> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. >> >> Thank you, >> -Yuri Gaevsky >> >> **Correctness checks:** >> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. > > Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: > > - moved vector register declarations into vectorized_mismatch() body. > - added initial support for ArrayOperationPartialInlineSize. In general the numbers seem better with LMUL=m2, so let's use it instead of m8. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3180162597 From aph at openjdk.org Tue Aug 12 17:05:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 17:05:15 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 16:33:05 GMT, Andrew Haley wrote: > + load_store_exclusive(dummy_reg, data, dummy_reg, addr, My mistake: this should be `load_store_volatile`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3180233322 From aph at openjdk.org Tue Aug 12 17:05:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 12 Aug 2025 17:05:14 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. Do you intend to do the volatile transformation to STLR as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3180231670 From lkorinth at openjdk.org Tue Aug 12 17:09:32 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 12 Aug 2025 17:09:32 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Message-ID: This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. These fixes have been created when I have ploughed through test cases: JDK-8352719: Add an equals sign to the modules statement JDK-8352709: Remove bad timing annotations from WhileOpTest.java JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE CODETOOLS-7903961: Make default timeout configurable After the review, I will update the copyrights. I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. I got 4 timing related faults: 1) runtime/Thread/TestThreadDumpMonitorContention.java This is probably: https://bugs.openjdk.org/browse/JDK-8361370 2) sun/tools/jhsdb/BasicLauncherTest.java I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. 3) gc/stress/TestReclaimStringsLeaksMemory.java I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. 4) sun/security/ssl/X509KeyManager/CertChecking.java This is a new test that I got on last rebase. I have added a timeout of 480 to it. In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions: 1) in testing(md|html): interpreted mode -> forced compilation mode 2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with) I am now re-running tier 1-8. ------------- Commit messages: - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Changes: https://git.openjdk.org/jdk/pull/26749/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8260555 Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From cjplummer at openjdk.org Tue Aug 12 17:54:13 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 12 Aug 2025 17:54:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. @lkorinth Can you send me a link to the failure? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310 From ayang at openjdk.org Tue Aug 12 19:24:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Aug 2025 19:24:15 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len wrote: >> Hi, >> >> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. >> >> I didn't change any copyright years for this change. >> >> Thanks > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Found the instructions for how to run the script in the error log Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3112432948 From duke at openjdk.org Tue Aug 12 19:54:14 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Tue, 12 Aug 2025 19:54:14 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: References: Message-ID: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> > Hello All, > > Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. > > Thank you, > -Yuri Gaevsky > > **Correctness checks:** > hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: removed unneeded check for zero length; changed lmul from m8 to m2. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17750/files - new: https://git.openjdk.org/jdk/pull/17750/files/63410201..671546a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17750/head:pull/17750 PR: https://git.openjdk.org/jdk/pull/17750 From amenkov at openjdk.org Tue Aug 12 20:25:23 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 12 Aug 2025 20:25:23 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v8] In-Reply-To: <0rVOOyK81m9nk1SUlvCi9br-ZSC1QnX5kBHc6GJ1HV8=.e32716e1-0e74-4b52-81b7-980785d5969d@github.com> References: <733zJmz4QYLOKTZ5lU1rp13UvWeJaQ7fesb5cBmLFr8=.8a9f7720-fec8-4c84-8cd7-7b04c6b74dd2@github.com> <0rVOOyK81m9nk1SUlvCi9br-ZSC1QnX5kBHc6GJ1HV8=.e32716e1-0e74-4b52-81b7-980785d5969d@github.com> Message-ID: On Tue, 12 Aug 2025 08:50:20 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/classfile/javaClasses.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/classfile/javaClasses.cpp line 1906: > >> 1904: GrowableArray* _bcis; >> 1905: >> 1906: GetStackTraceHandshakeClosure(Handle thread_oop) : > > Nit: I'd suggest to rename: `thread_oop` => `thread_h` Done (`thread_oop` => `thread_h` and `_thread_oop` => `_thread_h`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2271116461 From amenkov at openjdk.org Tue Aug 12 20:25:22 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 12 Aug 2025 20:25:22 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v9] In-Reply-To: References: Message-ID: > The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. > > Testing: tier1..5 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: renamed thread_oop to thread_h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26119/files - new: https://git.openjdk.org/jdk/pull/26119/files/3cc69d8f..eb2f13cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=07-08 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119 PR: https://git.openjdk.org/jdk/pull/26119 From sspitsyn at openjdk.org Tue Aug 12 20:50:14 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Aug 2025 20:50:14 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v9] In-Reply-To: References: Message-ID: <2vzJGLtr-dd3xn73oNFoGG-yn9cF-kzJo5X9J9xjx8M=.a71cb96c-3e83-4fb3-b18d-a1b20492351c@github.com> On Tue, 12 Aug 2025 20:25:22 GMT, Alex Menkov wrote: >> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. >> >> Testing: tier1..5 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > renamed thread_oop to thread_h Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-3112773666 From eastigeevich at openjdk.org Tue Aug 12 22:27:14 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 12 Aug 2025 22:27:14 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v4] In-Reply-To: <7UNfMDlrrnlIXWOt72vfVh2MuucJCgeVo3sPcZ_cG2U=.24099dd8-8142-47ac-8189-d85f41f82b58@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <7UNfMDlrrnlIXWOt72vfVh2MuucJCgeVo3sPcZ_cG2U=.24099dd8-8142-47ac-8189-d85f41f82b58@github.com> Message-ID: On Tue, 12 Aug 2025 15:28:14 GMT, Mikhail Ablakatov wrote: >> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. >> >> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. >> >> This has passed tier1-3 and jcstress testing on AArch64. > > Mikhail Ablakatov has updated the pull request incrementally with three additional commits since the last revision: > > - cleanup: update copyright headers > - Make the value type of the dictionary a struct instead of Pair typedef > - Remove share_rc_trampoline_for and share_sc_trampoline_for src/hotspot/cpu/aarch64/codeBuffer_aarch64.cpp line 66: > 64: if (rtype == relocInfo::static_call_type) { > 65: dest = SharedRuntime::get_resolve_static_call_stub(); > 66: } You are pulling details of implementation, use of `SharedRuntime::get_resolve_static_call_stub` for unlinked static calls. There is no need for this. It was: create a trampoline to the destination and relocation infos for all places in code which will share it. This is simple. It does not rely on any information about call sites. Now it is: we are creating a trampoline for an unlinked static call, it must have `get_resolve_static_call_stub` as a destination. Why should we have this? `Address` will always contain a correct destination set by a compiler. So we do double job, we throw away a target set by a compiler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2271423605 From iklam at openjdk.org Wed Aug 13 00:04:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Aug 2025 00:04:07 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache Message-ID: During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: class X { A getA() { return new B(); } // Verifier requires B to be a subtype of A. } We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if - `A` fails verification - `B` is a signed class, which is always excluded from the AOT cache Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. Notes for reviewers: - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. ------------- Commit messages: - 8317269: Store old classes in linked state in AOT cache Changes: https://git.openjdk.org/jdk/pull/26754/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317269 Stats: 1237 lines in 29 files changed: 1154 ins; 22 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From iklam at openjdk.org Wed Aug 13 00:15:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Aug 2025 00:15:10 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:02:13 GMT, Johan Sj?len wrote: >> Hi, >> >> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. >> >> I didn't change any copyright years for this change. >> >> Thanks > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Found the instructions for how to run the script in the error log `hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example: `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`). `resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp` ------------- PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3181661293 From syan at openjdk.org Wed Aug 13 01:50:14 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 13 Aug 2025 01:50:14 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25: > 23: > 24: /* > 25: * @test Should we need to update the copyright year for the touch files ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564 From syan at openjdk.org Wed Aug 13 01:54:16 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 13 Aug 2025 01:54:16 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29: > 27: * @requires vm.debug > 28: * @summary Test running with StressRecompilation enabled. > 29: * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish. > grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn 55:elapsed time (seconds): 0.581 66:elapsed time (seconds): 0.575 116:elapsed time (seconds): 3.088 162:elapsed time (seconds): 0.001 173:elapsed time (seconds): 11.546 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024 From jbhateja at openjdk.org Wed Aug 13 03:11:00 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 13 Aug 2025 03:11:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v6] In-Reply-To: References: Message-ID: <-_yIOwHApwxDw0YIWJ7MnXqK2VknHMQYoGShNqaslRk=.26037fd7-5429-4f41-a829-14f485b0ff48@github.com> > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Cleanups, review resoultions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/f36ae6dd..d55fa594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=04-05 Stats: 25 lines in 7 files changed: 0 ins; 24 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Wed Aug 13 03:11:00 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 13 Aug 2025 03:11:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> Message-ID: On Tue, 12 Aug 2025 05:58:47 GMT, Xiaohong Gong wrote: >>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes. >>> >> >> Added comments. >> >>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT? >> >> Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator. > > Thanks for your updating! So maybe the matcher function `supports_vector_slice_with_non_constant_index()` could also be removed totally? Yes, idea here is just to intrinsify a perticular scenario where slice index is a constant value and not burden the inline expander with full-blown intrinsification of all possible control paths without impacting the performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2271958737 From jbhateja at openjdk.org Wed Aug 13 03:20:02 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 13 Aug 2025 03:20:02 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v7] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Review comments resolution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/d55fa594..70c22932 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=05-06 Stats: 6 lines in 6 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From sspitsyn at openjdk.org Wed Aug 13 06:07:21 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 06:07:21 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 05:51:04 GMT, Leonid Mesnik wrote: > I ran tier1-5 testing and separately verified that test pass with jvmti strass agent. Okay, thanks. I'd also run the tier 6 to be more safe. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3182306000 From sspitsyn at openjdk.org Wed Aug 13 06:07:22 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 06:07:22 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: On Sat, 9 Aug 2025 20:30:14 GMT, Leonid Mesnik wrote: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. src/hotspot/share/prims/jvmtiExport.cpp line 1839: > 1837: JRT_BLOCK > 1838: state = get_jvmti_thread_state(thread); > 1839: JRT_BLOCK_END The `JRT_BLOCK` is defined as: #define JRT_BLOCK \ { \ assert(current == JavaThread::current(), "Must be"); \ ThreadInVMfromJava __tiv(current); \ JavaThread* THREAD = current; /* For exception macros. */ \ DEBUG_ONLY(VMEntryWrapper __vew;) I'd suggest something like this instead of using `JRT_BLOCK`: - JvmtiThreadState *state = get_jvmti_thread_state(thread); + JvmtiThreadState *state = nullptr; + { + ThreadInVMfromJava __tiv(thread); + state = get_jvmti_thread_state(thread); + } Alternatively, the `JRT_BLOCK` can be started at the line 1837 and ended with `JRT_BLOCK_END` at the line 1875. Not sure, what issue we can encounter with this though. At least, it is worth a try. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272164623 From iklam at openjdk.org Wed Aug 13 06:22:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Aug 2025 06:22:15 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed bugs found in JCK testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/3ca97535..b7f51ed2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=00-01 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From lmesnik at openjdk.org Wed Aug 13 06:26:16 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 13 Aug 2025 06:26:16 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v2] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: simplified after feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/47a32e8c..7cce73e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=00-01 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Wed Aug 13 06:26:17 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 13 Aug 2025 06:26:17 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 06:03:38 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> simplified after feedback > > src/hotspot/share/prims/jvmtiExport.cpp line 1839: > >> 1837: JRT_BLOCK >> 1838: state = get_jvmti_thread_state(thread); >> 1839: JRT_BLOCK_END > > The `JRT_BLOCK` is defined as: > > #define JRT_BLOCK \ > { \ > assert(current == JavaThread::current(), "Must be"); \ > ThreadInVMfromJava __tiv(current); \ > JavaThread* THREAD = current; /* For exception macros. */ \ > DEBUG_ONLY(VMEntryWrapper __vew;) > > > I'd suggest something like this instead of using `JRT_BLOCK`: > > - JvmtiThreadState *state = get_jvmti_thread_state(thread); > + JvmtiThreadState *state = nullptr; > + { > + ThreadInVMfromJava __tiv(thread); > + state = get_jvmti_thread_state(thread); > + } > > > Alternatively, the `JRT_BLOCK` can be started at the line 1837 and ended with `JRT_BLOCK_END` at the line 1875. Not sure, what issue we can encounter with this though. At least, it is worth a try. As I understand the post_method_entry was called via JRT_BLOCK_ENTRY and not JRT_BLOCK by the reason. We need to be in Java. See comments for the method invocation. // This is a JRT_BLOCK_ENTRY because we have to stash away the return oop // before transitioning to VM, and restore it after transitioning back // to Java. The return oop at the top-of-stack, is not walked by the GC. JRT_BLOCK_ENTRY(void, InterpreterRuntime::post_method_exit(JavaThread* current)) LastFrameAccessor last_frame(current); JvmtiExport::post_method_exit(current, last_frame.method(), last_frame.get_frame()); JRT_END And thanks for simplification, it is a good idea. I've updated the PR. I am running tier1-8 for Hotspot tests to ensure that nothing is broken. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272174407 From jbhateja at openjdk.org Wed Aug 13 07:08:13 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 13 Aug 2025 07:08:13 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 03:11:04 GMT, Xiaohong Gong wrote: > I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement? All those are the ones with variable slice index , slice kernel performance of those benchmarks on AVX2 and AVX512 targets are at par with baseline, and deviations are statistically insignificant due to error margins. New benchmark complements the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2272272548 From xgong at openjdk.org Wed Aug 13 07:08:13 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 13 Aug 2025 07:08:13 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 07:02:34 GMT, Jatin Bhateja wrote: >> test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 36: >> >>> 34: @State(Scope.Thread) >>> 35: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector"}) >>> 36: public class VectorSliceBenchmark { >> >> I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement? > >> I remember that it has the micro benchmarks for slice/unslice under `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` on panama-vector. Can we reuse those JMHs to check the benchmark improvement? > > All those are the ones with variable slice index , slice kernel performance of those benchmarks on AVX2 and AVX512 targets are at par with baseline, and deviations are statistically insignificant due to error margins. > > New benchmark complements the code. OK. Make sense to me. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2272278442 From sspitsyn at openjdk.org Wed Aug 13 07:19:13 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 07:19:13 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 06:26:16 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > simplified after feedback looks good src/hotspot/share/prims/jvmtiExport.cpp line 1837: > 1835: JvmtiThreadState *state = nullptr; > 1836: { > 1837: ThreadInVMfromJava __tiv(thread); Nit: Maybe rename: `__tiv` => `tiv`. The prefix `__` is normally used in macros to avoid potential naming conflicts. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3114238397 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272301754 From dlong at openjdk.org Wed Aug 13 07:27:07 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 07:27:07 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v11] In-Reply-To: References: Message-ID: > The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. Dean Long has updated the pull request incrementally with two additional commits since the last revision: - more fixes and cleanup/refactoring - Graal fix and more cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26121/files - new: https://git.openjdk.org/jdk/pull/26121/files/e04fc720..4dab21bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=09-10 Stats: 102 lines in 3 files changed: 49 ins; 36 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121 PR: https://git.openjdk.org/jdk/pull/26121 From sspitsyn at openjdk.org Wed Aug 13 07:29:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 07:29:11 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042 From dlong at openjdk.org Wed Aug 13 07:29:20 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 07:29:20 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v10] In-Reply-To: References: Message-ID: <2PN-fohhq9t7gY7y374y47r4pz7xHbFJwdosL1wkDFA=.954d0300-1cf2-4b0e-abcf-40c5ce0ca953@github.com> On Wed, 6 Aug 2025 01:29:58 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long 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 13 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8278874-verifystack > - Merge branch 'openjdk:master' into 8278874-verifystack > - more cleanup > - simplify is_top_frame > - readability suggestion > - reviewer suggestions > - Update src/hotspot/share/runtime/vframeArray.cpp > > Co-authored-by: Manuel H?ssig > - Update src/hotspot/share/runtime/vframeArray.cpp > > Co-authored-by: Manuel H?ssig > - better name for frame index > - Update src/hotspot/share/runtime/deoptimization.cpp > > Co-authored-by: Manuel H?ssig > - ... and 3 more: https://git.openjdk.org/jdk/compare/2ead4528...e04fc720 Hopefully these last couple commits fix the remaining edge cases, but Graal testing is still running. I'm testing with VerifyStack hard-coded to true so that vm.flagless tests also run, which does cause some failures due to timeouts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3182509262 From jsjolen at openjdk.org Wed Aug 13 07:47:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Aug 2025 07:47:05 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5] In-Reply-To: References: Message-ID: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Ioi's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26729/files - new: https://git.openjdk.org/jdk/pull/26729/files/5c58e011..eb5a4ea6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26729&range=03-04 Stats: 56 lines in 51 files changed: 0 ins; 0 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/26729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26729/head:pull/26729 PR: https://git.openjdk.org/jdk/pull/26729 From chagedorn at openjdk.org Wed Aug 13 08:43:17 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 13 Aug 2025 08:43:17 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v5] In-Reply-To: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> References: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> Message-ID: <7ZSL2sR91qOFup-zauB0VKCoLYB9dHMn3GGwLmo-gEk=.e790e543-fb41-42cd-add2-1f5f4a141afb@github.com> On Fri, 8 Aug 2025 10:51:42 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into JDK-8308094-timeout > - Rename _timer > - remove _timeout_armed > - ASSERT > - Merge branch 'master' into JDK-8308094-timeout > - No acquire release semantics > - Factor Linux specific timeout functionality out of share/ > - Move timeout disarm above if > - Merge branch 'master' into JDK-8308094-timeout > - Fix SIGALRM test > - ... and 1 more: https://git.openjdk.org/jdk/compare/c5920029...8bb5eb7a Nice improvement! I left some small comments in the code but otherwise the change looks reasonable! Can we also add some tests for the new `CompileTaskTimeout` flag? Maybe we can add a positive test and negative test: - Positive test: Could just be a hello world test with a reasonably large non-zero value for `CompileTaskTimeout`. - Negative test: Maybe we can just set `CompileTaskTimeout=1` which will probably crash immediately for a hello world program. That could be run in a separate VM and then we can check the output. If we are able to also dump the compile task/method that is timing out, we might even be able to match on that when run with `CompileOnly` for a single method. But not sure if the latter is possible. What do you think? src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 43: > 41: switch (signo) { > 42: case TIMEOUT_SIGNAL: { > 43: assert(false, "compile task timed out"); Can you somehow also print the task which caused the timeout? Will just accessing `CompilerThread::current()->task()` work? src/hotspot/os/linux/compilerThreadTimeout_linux.hpp line 46: > 44: #endif // !PRODUCT > 45: public: > 46: CompilerThreadTimeoutLinux() NOT_PRODUCT(DEBUG_ONLY(: _timer(nullptr))) {}; Why do you need the `NOT_PRODUCT`? It only wraps `DEBUG_ONLY`. If that's not set, the `NOT_PRODUCT` wraps nothing. src/hotspot/os/linux/globals_linux.hpp line 94: > 92: develop(intx, CompileTaskTimeout, 0, \ > 93: "Set the timeout for compile tasks' CPU time in milliseconds."\ > 94: "0 = no timeout (default)") \ Suggestion: " 0 = no timeout (default)") \ src/hotspot/share/compiler/compilerThread.hpp line 52: > 50: CompilerThreadTimeoutGeneric() {}; > 51: void arm() { return; }; > 52: void disarm() { return; }; You can remove the `return`: Suggestion: void arm() {}; void disarm() {}; src/hotspot/share/compiler/compilerThread.hpp line 54: > 52: void disarm() { return; }; > 53: bool init_timeout() { return true; }; > 54: }; Should we also guard this with `ifndef LINUX` since it's only used for non-Linux? ------------- PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3114494124 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2272483803 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2272509382 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2272512593 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2272517713 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2272516811 From jsjolen at openjdk.org Wed Aug 13 09:30:15 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Aug 2025 09:30:15 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v4] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 00:13:03 GMT, Ioi Lam wrote: > `hashtable.hpp` should become `hashTable.hpp`, which defines the type `HashTable`. (Existing example: `concurrentHashTable.hpp` defines the type `ConcurrentHashTable`). > > `resizeableResourceHash.hpp` should be renamed to `resizeableHashTable.hpp` Done! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3182953039 From aturbanov at openjdk.org Wed Aug 13 09:47:17 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 13 Aug 2025 09:47:17 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... test/langtools/tools/lib/toolbox/ToolBox.java line 480: > 478: > 479: private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0; > 480: private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0; Suggestion: private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651 From sspitsyn at openjdk.org Wed Aug 13 10:25:35 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 10:25:35 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v8] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 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 eight additional commits since the last revision: - Merge - Merge - Merge - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/0edab914..df91f171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=06-07 Stats: 29966 lines in 783 files changed: 17653 ins; 9650 del; 2663 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From duke at openjdk.org Wed Aug 13 12:22:16 2025 From: duke at openjdk.org (Samuel Chee) Date: Wed, 13 Aug 2025 12:22:16 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. Just to double check, `load_store_volatile` does not seem to exist, would I have to implement this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3183644954 From duke at openjdk.org Wed Aug 13 12:22:18 2025 From: duke at openjdk.org (Samuel Chee) Date: Wed, 13 Aug 2025 12:22:18 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 15:14:50 GMT, Andrew Haley wrote: >> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. >> >> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. >> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. >> >> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. >> >> This excludes floats and doubles, as they do not have equivalent load-acquire instructions. > > src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 917: > >> 915: LIR_PatchCode patch_code, CodeEmitInfo* info) { >> 916: if (is_floating_point_type(type)) { >> 917: // Use LDAR instead of DMB+LD+DMB, except for floats/doubles (no LDAR equivalent). > > We need more information here. If we're using LDAR, we should `ldar x8, mem; movd dest, x8` After looking it into more, we can use LDAR for floating types using LDAR; FMOV. Will update later to include this once I have addressed everything else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2273270422 From aph at openjdk.org Wed Aug 13 12:32:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 13 Aug 2025 12:32:17 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: <6HuoGme8PsEQAaBt-WTXiEgF1MwGapfgBY3RLJO_K6k=.49812b6e-b060-43b9-9798-1a92ea09e760@github.com> On Wed, 13 Aug 2025 12:20:14 GMT, Samuel Chee wrote: > Just to double check, `load_store_volatile` does not seem to exist, would I have to implement this? + void load_store_volatile(Register data, BasicType type, Register addr, + bool is_load) { + load_store_exclusive(dummy_reg, data, dummy_reg, addr, + (Assembler::operand_size)exact_log2(type2aelembytes(type)), + is_load ? 0b110: 0b100, 1); + } + ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3183712818 From fbredberg at openjdk.org Wed Aug 13 12:57:13 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 13 Aug 2025 12:57:13 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: On Fri, 8 Aug 2025 19:12:19 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address David's comments Nice fix! Just a small comment. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 108: > 106: // For stub/native frames the value is not used while frozen, and will be constructed > 107: // again when thawing the frame (see ThawBase::new_stack_frame). > 108: fp = FKind::compiled ? *(intptr_t**)(f.sp() - frame::sender_sp_offset) : nullptr; I would prefer to set `fp` to something else than `nullptr` for stub/native frames, maybe `not_used_fp`. It feels like it would be easier to debug when you look into frames. But if this is the only case where `fp` is set to something else than a "real" memory pointer, I guess it really doesn't matter. src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 105: > 103: // For stub/native frames the value is not used while frozen, and will be constructed > 104: // again when thawing the frame (see ThawBase::new_stack_frame). > 105: fp = FKind::compiled ? *(intptr_t**)(f.sp() - frame::sender_sp_offset) : nullptr; Same here. ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/26660#pullrequestreview-3115870676 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2273362105 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2273365243 From lkorinth at openjdk.org Wed Aug 13 13:09:13 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 13:09:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25: > >> 23: >> 24: /* >> 25: * @test > > Should we need to update the copyright year for the touched files `After the review, I will update the copyrights.` It is IMO easier to review big changes without the noise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872 From lkorinth at openjdk.org Wed Aug 13 13:21:11 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 13:21:11 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com> On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer wrote: > > sun/tools/jhsdb/BasicLauncherTest.java > > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > > @lkorinth Can you send me a link to the failure? I sent it to you on email. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453 From erikj at openjdk.org Wed Aug 13 13:28:18 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 13 Aug 2025 13:28:18 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... make/RunTests.gmk line 939: > 937: > 938: JTREG_AUTO_PROBLEM_LISTS := > 939: JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead. I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852 From mbaesken at openjdk.org Wed Aug 13 13:30:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 13 Aug 2025 13:30:57 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail Message-ID: When running with asan - enabled binaries, some oops related tests fail. This seems to be related to (small) changes in memory layout caused by asan. examples : runtime/CompressedOops/UseCompressedOops.java java.lang.RuntimeException: 'Zero based' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) at UseCompressedOops.main(UseCompressedOops.java:48) 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.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit Failed event: jdk.GCHeapConfiguration { startTime = 13:13:02.886 (2025-08-09) minSize = 100.0 MB maxSize = 100.0 MB initialSize = 100.0 MB usesCompressedOops = true compressedOopsMode = "Non-zero based" objectAlignment = 8 bytes heapAddressBits = 32 } ----------System.err:(20/1718)---------- java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) at jdk.test.lib.jfr.EventField.equal(EventField.java:50) at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) at jdk.jfr.event.gc.configuration.TestGCHeapConfigurationEventWith32BitOops.main(TestGCHeapConfigurationEventWith32BitOops.java:49) 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.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithZeroBasedOops.java Error: Value not equal to Zero based, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: Zero based Failed event: jdk.GCHeapConfiguration { startTime = 13:13:02.073 (2025-08-09) minSize = 8.0 MB maxSize = 4.0 GB initialSize = 1000.0 MB usesCompressedOops = true compressedOopsMode = "Non-zero based" objectAlignment = 8 bytes heapAddressBits = 32 } ----------System.err:(20/1754)---------- java.lang.RuntimeException: Value not equal to Zero based, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: Zero based at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) at jdk.test.lib.jfr.EventField.equal(EventField.java:50) at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) at jdk.jfr.event.gc.configuration.ZeroBasedOopsVerifier.verify(TestGCHeapConfigurationEventWithZeroBasedOops.java:67) at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) at jdk.jfr.event.gc.configuration.TestGCHeapConfigurationEventWithZeroBasedOops.main(TestGCHeapConfigurationEventWithZeroBasedOops.java:44) 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.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) ------------- Commit messages: - JDK-8365487 Changes: https://git.openjdk.org/jdk/pull/26760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365487 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26760/head:pull/26760 PR: https://git.openjdk.org/jdk/pull/26760 From lkorinth at openjdk.org Wed Aug 13 13:36:13 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 13:36:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29: > >> 27: * @requires vm.debug >> 28: * @summary Test running with StressRecompilation enabled. >> 29: * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation > > I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish. > > >> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn > 55:elapsed time (seconds): 0.581 > 66:elapsed time (seconds): 0.575 > 116:elapsed time (seconds): 3.088 > 162:elapsed time (seconds): 0.001 > 173:elapsed time (seconds): 11.546 I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236 From lkorinth at openjdk.org Wed Aug 13 13:53:12 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 13:53:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com> On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn wrote: > I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore. I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177 From lkorinth at openjdk.org Wed Aug 13 14:22:08 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 14:22:08 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: After suggestions from Erik and Andrey ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Wed Aug 13 14:22:10 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 14:22:10 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> After suggestions from Erik and Andrey > > make/RunTests.gmk line 939: > >> 937: >> 938: JTREG_AUTO_PROBLEM_LISTS := >> 939: JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead. > > I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate. I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868 From lkorinth at openjdk.org Wed Aug 13 14:22:11 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 13 Aug 2025 14:22:11 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> After suggestions from Erik and Andrey > > test/langtools/tools/lib/toolbox/ToolBox.java line 480: > >> 478: >> 479: private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0; >> 480: private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0; > > Suggestion: > > private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0; Fixed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076 From redestad at openjdk.org Wed Aug 13 14:23:22 2025 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 13 Aug 2025 14:23:22 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. I've done some testing on linux-amd64 and verified that on microbenchmarks that exercise for example `StringCoding.hasNegatives` (a front door of one of the intrinsics this PR changes) the generated assembly is identical under ideal conditions. Spurious regressions seen in some setups could be inlining related: moving from a simple range check emitted by the intrinsic to a call to `Preconditions.checkFromIndexSize` may push us over some inlining threshold in some cases. I'll try to get my hands on a linux-aarch64 machine to do some diagnostic runs on. An idea for future investigation could be to make `Preconditions.checkFromIndexSize` an intrinsic similar to `Preconditions.checkIndex` - to help the compiler do the right thing with more ease and perhaps slightly faster. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3116268132 From lmesnik at openjdk.org Wed Aug 13 14:36:48 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 13 Aug 2025 14:36:48 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v3] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/7cce73e3..977c9eb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Wed Aug 13 15:08:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 13 Aug 2025 15:08:55 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - added _ - wong phase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/977c9eb4..255c0ba8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From iklam at openjdk.org Wed Aug 13 15:57:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Aug 2025 15:57:11 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5] In-Reply-To: References: Message-ID: <1IxUyzkDpUinf8oPCbLLRXldc_btUhDSnEcQUEj8ikM=.9f65e529-d65a-461b-aa73-b666eebcaac3@github.com> On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len wrote: >> Hi, >> >> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. >> >> I didn't change any copyright years for this change. >> >> Thanks > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's comments LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26729#pullrequestreview-3116642805 From amenkov at openjdk.org Wed Aug 13 18:30:23 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 13 Aug 2025 18:30:23 GMT Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread [v4] In-Reply-To: References: <73NBrSzN1jXj3U8Rhuq0IECTEUhD-pxtx0QN0J43vms=.e6931f8e-fe8d-4dd0-8988-fabcb0dd188d@github.com> Message-ID: On Thu, 10 Jul 2025 23:19:30 GMT, David Holmes wrote: >>> > Added extra argument to cv_internal_thread_to_JavaThread to return carrrier's JavaThread. >>> >>> @alexmenkov I think we need a separate JBS issue for this and have runtime fix it. I want to be sure we are fixing it in the right/best way. I don't think we need the extra argument, but need to examine the existing usages. Chances are that any code trying to deal with virtual thread's via the API is actually doing it wrong and will need fixing anyway. I will file a bug. >> >> I think just update the method to use carrier is error prone and callers should explicitly request the functionality. >> I'm fine with separate issue, will remove changes in threadSMR.* and restore original handling of virtual thread carrier > > @alexmenkov Alex, the form of this fix will be determined by whatever we end up doing for [JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912). I don't see any point in re-doing this fix later, so I suggest just putting this on hold for now. I will ensure the other issue is fixed within the next week. Thank you for the review @dholmes-ora and @sspitsyn ------------- PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3185019637 From amenkov at openjdk.org Wed Aug 13 18:30:24 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 13 Aug 2025 18:30:24 GMT Subject: Integrated: 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 19:53:44 GMT, Alex Menkov wrote: > The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection. > > Testing: tier1..5 This pull request has now been integrated. Changeset: ecbdd340 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/ecbdd3405a1d46f555deb82098e1865b44601a1f Stats: 31 lines in 3 files changed: 1 ins; 4 del; 26 mod 8361103: java_lang_Thread::async_get_stack_trace does not properly protect JavaThread Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26119 From jsjolen at openjdk.org Wed Aug 13 18:42:19 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Aug 2025 18:42:19 GMT Subject: RFR: 8365264: Rename ResourceHashtable to HashTable [v5] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 07:47:05 GMT, Johan Sj?len wrote: >> Hi, >> >> This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. >> >> I didn't change any copyright years for this change. >> >> Thanks > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's comments Cheers! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26729#issuecomment-3185064264 From jsjolen at openjdk.org Wed Aug 13 18:45:21 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Aug 2025 18:45:21 GMT Subject: Integrated: 8365264: Rename ResourceHashtable to HashTable In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 15:57:41 GMT, Johan Sj?len wrote: > Hi, > > This PR renames `ResourceHashtable` to `HashTable`. The "resource" part of the name isn't true anymore, it does many types of allocations. The RHT should be HT to signify that it's the default choice of hashtable in Hotspot. > > I didn't change any copyright years for this change. > > Thanks This pull request has now been integrated. Changeset: 4680dc98 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/4680dc983169d48fcf83eb50dc60e32e79d5d976 Stats: 2233 lines in 71 files changed: 1058 ins; 1059 del; 116 mod 8365264: Rename ResourceHashtable to HashTable Reviewed-by: iklam, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26729 From asmehra at openjdk.org Wed Aug 13 18:53:36 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 13 Aug 2025 18:53:36 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods Message-ID: This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). Motivation for this change is described in the JBS issue. ------------- Commit messages: - 8365501: Remove speical AdapterHandlerEntry for abstract methods Changes: https://git.openjdk.org/jdk/pull/26764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26764&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365501 Stats: 55 lines in 5 files changed: 11 ins; 38 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26764/head:pull/26764 PR: https://git.openjdk.org/jdk/pull/26764 From dlong at openjdk.org Wed Aug 13 19:42:31 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 19:42:31 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: References: Message-ID: > The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. Dean Long has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26121/files - new: https://git.openjdk.org/jdk/pull/26121/files/4dab21bd..ffab3f1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=10-11 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121 PR: https://git.openjdk.org/jdk/pull/26121 From kvn at openjdk.org Wed Aug 13 19:45:10 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 13 Aug 2025 19:45:10 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 18:45:54 GMT, Ashutosh Mehra wrote: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. Nice. Let me test it. ------------- PR Review: https://git.openjdk.org/jdk/pull/26764#pullrequestreview-3117442108 From coleenp at openjdk.org Wed Aug 13 20:38:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Aug 2025 20:38:11 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: On Fri, 8 Aug 2025 19:12:19 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address David's comments Looks good. I agree with Fredrik that some debug value for fp might be better for detecting bugs. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 788: > 786: > 787: int adjust = frame::metadata_words_at_bottom; > 788: #if INCLUDE_ASAN && defined(AARCH64) Thank you for explaining this conditional compilation. If I understand correctly, this isn't strictly necessary but gives an anchor for the comment to explain why the adjustment is not needed in this case. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26660#pullrequestreview-3117607556 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2274566342 From sspitsyn at openjdk.org Wed Aug 13 21:23:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 21:23:12 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 07:16:05 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> simplified after feedback > > src/hotspot/share/prims/jvmtiExport.cpp line 1837: > >> 1835: JvmtiThreadState *state = nullptr; >> 1836: { >> 1837: ThreadInVMfromJava __tiv(thread); > > Nit: Maybe rename: `__tiv` => `tiv`. The prefix `__` is normally used in macros to avoid potential naming conflicts. Thank you for the update on this! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2274671305 From sspitsyn at openjdk.org Wed Aug 13 21:23:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Aug 2025 21:23:11 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 15:08:55 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - added _ > - wong phase Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3117745050 From dlong at openjdk.org Wed Aug 13 22:02:13 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 22:02:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Mon, 11 Aug 2025 15:59:40 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > >> ### Progress >> >> * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> >> * [x] Change must not contain extraneous whitespace >> >> * [x] Commit message must refer to an issue >> >> >> ### Error >> >> ?? The pull request body must not be empty. >> ### Integration blocker >> >> ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) >> ### Issue >> >> * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. >> >> >> ### Reviewing >> Using `git` >> >> Using Skara CLI tools >> >> Using diff file > > > >> ### Progress >> >> * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> >> * [x] Change must not contain extraneous whitespace >> >> * [x] Commit message must refer to an issue >> >> >> ### Error >> >> ?? The pull request body must not be empty. >> ### Integration blocker >> >> ?? Title mismatch between PR and JBS for issue [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306) >> ### Issue >> >> * [JDK-8328306](https://bugs.openjdk.org/browse/JDK-8328306): Allow VM to run with X memory execute by default (**Enhancement** - P4) ?? Title mismatch between PR and JBS. >> >> >> ### Reviewing >> Using `git` >> >> Using Skara CLI tools >> >> Using diff file Thanks @theRealAph for doing this. I think it will be an improvement in maintainability. FWIW, I did my own experiments in this area, where I focused on more fine-grained state tracking (JDK-8307817) and perhaps staying in Exec mode more than necessary (which is probably more secure), and saw similar improvement in the number of mode changes. But my implementation, having mode tracking logic around in the "middle", and around condition code, rather than pushing it down to the leaves or up to the entry point meant more maintenance when the code changed, so I'm happy to abandon my prototype in favor of this simpler apprach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3185969879 From pchilanomate at openjdk.org Wed Aug 13 22:02:34 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 13 Aug 2025 22:02:34 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v3] In-Reply-To: References: Message-ID: <7jnsZfWEq8fF6vmr9czvFxA44uSgViPcJO6s6WhQS_Q=.d273176d-fca6-4088-9b70-de1056763010@github.com> > Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. > > Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. > > The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: - use special marker for fp in freeze fast path too - use special marker value for unused fp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26660/files - new: https://git.openjdk.org/jdk/pull/26660/files/a000a06b..742e361d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=01-02 Stats: 48 lines in 8 files changed: 41 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26660/head:pull/26660 PR: https://git.openjdk.org/jdk/pull/26660 From dlong at openjdk.org Wed Aug 13 22:05:13 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 22:05:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <4paL_6pij2g1Wt30YKY8140rtQVuilhjNBdOz_xjYPs=.0c0a36fe-e05d-4401-b6ba-53f0c5601d10@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> <4paL_6pij2g1Wt30YKY8140rtQVuilhjNBdOz_xjYPs=.0c0a36fe-e05d-4401-b6ba-53f0c5601d10@github.com> Message-ID: <5d1VwviKHZ3PsV6ih-Sp4huqZS9aML3V5tg7fFPvMas=.9e1d8370-5d37-4e12-bf42-b5238dfcd84f@github.com> On Tue, 12 Aug 2025 10:22:00 GMT, Andrew Dinn wrote: >>> Why plant the WXEnable before the thread transition here when it is placed after the thread transition in the NO_ASYNC macro? Why not after in both? >> >> OK. >> >>> Likewise in later occurrences what governs the placement? >> >> The process of discovering the sweet spots we entirely empirical, not analytical. > > I don't believe the order is going to matter (tell me if I am wrong) but I think it would be better to order them consistently, not just because I am a 'typical computer programmer' but because someone might be puzzled as to whether the re-ordering is significant (ok, yes, I guess that 'someone' would be a 'typical computer programmer' or maybe just me). I suggested both after because the async thread transition has a bail out and we might as well bail early . . . I like having the mode change after the thread state change. In my experiements, I tried to assert that we only change thread state when we are in Exec mode, but ended up relaxing that for Compiler and GC threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2274744437 From pchilanomate at openjdk.org Wed Aug 13 22:09:13 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 13 Aug 2025 22:09:13 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: On Wed, 13 Aug 2025 12:50:42 GMT, Fredrik Bredberg wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> address David's comments > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 108: > >> 106: // For stub/native frames the value is not used while frozen, and will be constructed >> 107: // again when thawing the frame (see ThawBase::new_stack_frame). >> 108: fp = FKind::compiled ? *(intptr_t**)(f.sp() - frame::sender_sp_offset) : nullptr; > > I would prefer to set `fp` to something else than `nullptr` for stub/native frames, maybe `not_used_fp`. > It feels like it would be easier to debug when you look into frames. But if this is the only case where `fp` is set to something else than a "real" memory pointer, I guess it really doesn't matter. Agree. It?s also helpful to identify invalid accesses as Coleen mentioned. Added changes. > src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 105: > >> 103: // For stub/native frames the value is not used while frozen, and will be constructed >> 104: // again when thawing the frame (see ThawBase::new_stack_frame). >> 105: fp = FKind::compiled ? *(intptr_t**)(f.sp() - frame::sender_sp_offset) : nullptr; > > Same here. Added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2274747440 PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2274747612 From pchilanomate at openjdk.org Wed Aug 13 22:09:14 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 13 Aug 2025 22:09:14 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v2] In-Reply-To: References: <2QBp85PQqypHeK4V4VbA1lZH9W3vRj_0wPfnX-Kec5c=.80f47cfc-2bd0-4c2b-babe-d0e30ea6a6b1@github.com> Message-ID: <6xXNpEu3m7ClEAR6BGBnav3MA1eTaxZ0aN5dnBdUcpU=.d7f88319-ad72-40e2-9871-ab8c5e703f61@github.com> On Wed, 13 Aug 2025 20:34:55 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> address David's comments > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 788: > >> 786: >> 787: int adjust = frame::metadata_words_at_bottom; >> 788: #if INCLUDE_ASAN && defined(AARCH64) > > Thank you for explaining this conditional compilation. If I understand correctly, this isn't strictly necessary but gives an anchor for the comment to explain why the adjustment is not needed in this case. Right, the only purpose of that extra adjust is to avoid the asan error. Other than that, avoiding copying `frame::metadata_words_at_bottom` just implicitly sets the `fp` to whatever value is already stored in the stackChunk, so we don?t gain anything. But we can do the same thing we do in the slow path and always patch `fp` with the special unused value, which will also make both freeze paths consistent. I just pushed a commit that implements exactly that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2274749419 From dlong at openjdk.org Wed Aug 13 22:20:11 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 22:20:11 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: > 247: // If we got a SIGBUS because we tried to write into the code > 248: // cache, try enabling WXWrite mode. > 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr)) { Suggestion: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { I think we want to make sure the code doing the write is outside the codecache. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2274764496 From dlong at openjdk.org Wed Aug 13 22:25:14 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 13 Aug 2025 22:25:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 07:58:04 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Bernhard Urban-Forster src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 265: > 263: // is called by the signal handler at arbitrary point of > 264: // execution. > 265: ThreadWXEnable wx(WXWrite, thread); I'm not sure this ThreadWXEnable needs to use WXWrite. I had changed it to WXExec in my experiments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2274769412 From pchilanomate at openjdk.org Thu Aug 14 00:04:11 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 14 Aug 2025 00:04:11 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 15:08:55 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - added _ > - wong phase src/hotspot/share/prims/jvmtiExport.cpp line 1838: > 1836: { > 1837: ThreadInVMfromJava tiv(thread); > 1838: state = get_jvmti_thread_state(thread); The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2274899453 From iklam at openjdk.org Thu Aug 14 00:37:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 00:37:39 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache Message-ID: Implement `-Xlog:aot+map` in the production run: $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ -Xlog:aot+map=file=aot.map:none:filesize=0 \ HelloWorld I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. ------------- Commit messages: - Added test case for -Xlog:aot+map in production run - more clean up - Merge branch 'master' into 8362566-log-aot-map-for-existing-aot-cache - Fixed crashes on macos -- cannot use _narrow_oop_base as it can wrap around - More clean up; print dynamic archive - Fixed build - more clean up - No need for special code to print native ptrs in oops; More clean up - Implemented logging of heap roots and constant pool resolved_references() - Implemented FakeString - ... and 7 more: https://git.openjdk.org/jdk/compare/9c266ae8...889dd5e4 Changes: https://git.openjdk.org/jdk/pull/26514/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362566 Stats: 1617 lines in 13 files changed: 1156 ins; 452 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From duke at openjdk.org Thu Aug 14 00:37:39 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 14 Aug 2025 00:37:39 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 16:56:32 GMT, Ioi Lam wrote: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Tested locally and working fine: 0x00000008004c2128: @@ ConstantPool 528 java.lang.System$In {constant pool} - flags: 0x6 on_stack - holder: 0x00000008000da9c8 - cache: 0x0000000800313528 - resolved_references: 0x0000000000000000 - reference_map: 0x0000000000000000 - resolved_klasses: 0x00000008003134e8 - cp length: 57 - 1 : : klass_index=2 name_and_type_index=3 - 2 : : 'java/io/FileInputStream' {0x00000008000daf48} - 3 : : name_index=5 signature_index=6 - 4 : : 'java/io/FileInputStream' - 5 : : '' - 6 : : '(Ljava/io/FileDescriptor;)V' - 7 : : klass_index=8 name_and_type_index=9 [...] ------------- PR Comment: https://git.openjdk.org/jdk/pull/26514#issuecomment-3131536644 From iklam at openjdk.org Thu Aug 14 00:48:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 00:48:44 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v2] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: make CDSMapTest.java flagless ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/889dd5e4..e1435df6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From kvn at openjdk.org Thu Aug 14 00:52:10 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 14 Aug 2025 00:52:10 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 18:45:54 GMT, Ashutosh Mehra wrote: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. My tier1-5 testing passed ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26764#pullrequestreview-3118132374 From iklam at openjdk.org Thu Aug 14 02:15:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 02:15:02 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v3] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed include order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/e1435df6..b2d2ddda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From iklam at openjdk.org Thu Aug 14 02:39:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 02:39:30 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v4] In-Reply-To: References: Message-ID: <0bB4Rgy1cxBQONNfoubA0WHLNDT9dmqScqDdr62BoBA=.908e7f70-1927-4a13-9885-e6ef7e8e2eb8@github.com> > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed Windows crashes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/b2d2ddda..dab6f6ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=02-03 Stats: 30 lines in 1 file changed: 18 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From asmehra at openjdk.org Thu Aug 14 03:02:20 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 14 Aug 2025 03:02:20 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 00:49:45 GMT, Vladimir Kozlov wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > My tier1-5 testing passed @vnkozlov thanks for reviewing and testing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3186588848 From asmehra at openjdk.org Thu Aug 14 03:02:20 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 14 Aug 2025 03:02:20 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 18:45:54 GMT, Ashutosh Mehra wrote: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. @adinn can you please review it as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3186589583 From iklam at openjdk.org Thu Aug 14 04:27:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 04:27:23 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v5] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed crash with ZGC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/dab6f6ae..4cc90093 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From syan at openjdk.org Thu Aug 14 06:03:13 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 14 Aug 2025 06:03:13 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 13:23:45 GMT, Matthias Baesken wrote: > When running with asan - enabled binaries, some oops related tests fail. > This seems to be related to (small) changes in memory layout caused by asan. > examples : > runtime/CompressedOops/UseCompressedOops.java > > > java.lang.RuntimeException: 'Zero based' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) > at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) > at UseCompressedOops.main(UseCompressedOops.java:48) > 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.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > > > jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java > > > Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > Failed event: > jdk.GCHeapConfiguration { > startTime = 13:13:02.886 (2025-08-09) > minSize = 100.0 MB > maxSize = 100.0 MB > initialSize = 100.0 MB > usesCompressedOops = true > compressedOopsMode = "Non-zero based" > objectAlignment = 8 bytes > heapAddressBits = 32 > } > > ----------System.err:(20/1718)---------- > java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > at jdk.test.lib.Asserts.fail(Asserts.java:715) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) > at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) > at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) > at jdk.test.lib.jfr.EventField.equal(EventField.java:50) > at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) > at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) > ... LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/26760#pullrequestreview-3119130230 From kbarrett at openjdk.org Thu Aug 14 06:57:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 06:57:18 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 13:23:45 GMT, Matthias Baesken wrote: > When running with asan - enabled binaries, some oops related tests fail. > This seems to be related to (small) changes in memory layout caused by asan. > examples : > runtime/CompressedOops/UseCompressedOops.java > > > java.lang.RuntimeException: 'Zero based' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) > at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) > at UseCompressedOops.main(UseCompressedOops.java:48) > 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.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > > > jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java > > > Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > Failed event: > jdk.GCHeapConfiguration { > startTime = 13:13:02.886 (2025-08-09) > minSize = 100.0 MB > maxSize = 100.0 MB > initialSize = 100.0 MB > usesCompressedOops = true > compressedOopsMode = "Non-zero based" > objectAlignment = 8 bytes > heapAddressBits = 32 > } > > ----------System.err:(20/1718)---------- > java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > at jdk.test.lib.Asserts.fail(Asserts.java:715) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) > at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) > at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) > at jdk.test.lib.jfr.EventField.equal(EventField.java:50) > at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) > at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) > ... Other than the comment consistency suggestion, this looks good. test/hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java line 33: > 31: * java.management > 32: * @build jdk.test.whitebox.WhiteBox > 33: * @comment Do not run with asan enabled, because it changes memory layout and we get a different coops mode Consider making this comment consistent with the others in this change? ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26760#pullrequestreview-3119239876 PR Review Comment: https://git.openjdk.org/jdk/pull/26760#discussion_r2275652323 From stuefe at openjdk.org Thu Aug 14 07:01:12 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 14 Aug 2025 07:01:12 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 13:23:45 GMT, Matthias Baesken wrote: > When running with asan - enabled binaries, some oops related tests fail. > This seems to be related to (small) changes in memory layout caused by asan. > examples : > runtime/CompressedOops/UseCompressedOops.java > > > java.lang.RuntimeException: 'Zero based' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) > at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) > at UseCompressedOops.main(UseCompressedOops.java:48) > 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.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > > > jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java > > > Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > Failed event: > jdk.GCHeapConfiguration { > startTime = 13:13:02.886 (2025-08-09) > minSize = 100.0 MB > maxSize = 100.0 MB > initialSize = 100.0 MB > usesCompressedOops = true > compressedOopsMode = "Non-zero based" > objectAlignment = 8 bytes > heapAddressBits = 32 > } > > ----------System.err:(20/1718)---------- > java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > at jdk.test.lib.Asserts.fail(Asserts.java:715) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) > at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) > at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) > at jdk.test.lib.jfr.EventField.equal(EventField.java:50) > at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) > at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) > ... Good. We may run into similar problems with the compressed class pointer tests. Have you seen problems there, too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26760#issuecomment-3187190084 From mbaesken at openjdk.org Thu Aug 14 07:32:29 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Aug 2025 07:32:29 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail [v2] In-Reply-To: References: Message-ID: > When running with asan - enabled binaries, some oops related tests fail. > This seems to be related to (small) changes in memory layout caused by asan. > examples : > runtime/CompressedOops/UseCompressedOops.java > > > java.lang.RuntimeException: 'Zero based' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) > at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) > at UseCompressedOops.main(UseCompressedOops.java:48) > 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.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > > > jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java > > > Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > Failed event: > jdk.GCHeapConfiguration { > startTime = 13:13:02.886 (2025-08-09) > minSize = 100.0 MB > maxSize = 100.0 MB > initialSize = 100.0 MB > usesCompressedOops = true > compressedOopsMode = "Non-zero based" > objectAlignment = 8 bytes > heapAddressBits = 32 > } > > ----------System.err:(20/1718)---------- > java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > at jdk.test.lib.Asserts.fail(Asserts.java:715) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) > at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) > at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) > at jdk.test.lib.jfr.EventField.equal(EventField.java:50) > at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) > at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) > ... Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Unify comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26760/files - new: https://git.openjdk.org/jdk/pull/26760/files/27f7a820..55c5c055 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26760&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26760&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26760/head:pull/26760 PR: https://git.openjdk.org/jdk/pull/26760 From mbaesken at openjdk.org Thu Aug 14 07:38:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Aug 2025 07:38:17 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 06:58:27 GMT, Thomas Stuefe wrote: > Good. We may run into similar problems with the compressed class pointer tests. Have you seen problems there, too? The runtime/CompressedOops/CompressedClassPointers.java runtime/CompressedOops/CompressedClassPointersEncodingScheme.java worked with asan. At least on my setup. So I am not aware of issues with the tests you maybe mean. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26760#issuecomment-3187294629 From yzheng at openjdk.org Thu Aug 14 07:40:28 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 14 Aug 2025 07:40:28 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Tue, 5 Aug 2025 18:08:22 GMT, Ashutosh Mehra wrote: >> This PR implements the code for cpu features names string using ~FormatBuffer~ stringStream. ~It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer.~ It also adds a method to stringStream that that appends separated strings separated by a delimiter to the buffer. This is useful in creating the cpu features names string. >> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]. >> Platforms affected: x86-64 and aarch64 >> Other platforms can be done if and when Leyden changes are ported to them. >> >> [0] https://github.com/openjdk/leyden/pull/84 > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > > Signed-off-by: Ashutosh Mehra src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 148: > 146: > 147: enum Feature_Flag { > 148: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = bit, It would be greatly appreciated if you could give the Graal devs a heads-up when changing CPU feature flags. JVMCI sees different CPU features with this change, and eventually leads to SIGILL by generating instruction not supported by the underlying CPU. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2275745777 From ksakata at openjdk.org Thu Aug 14 07:43:44 2025 From: ksakata at openjdk.org (Koichi Sakata) Date: Thu, 14 Aug 2025 07:43:44 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 Message-ID: A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. This pull request fixes the issue and prevents the crash. # Details Example command to reproduce: $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- aarch64) # Problematic frame: # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc [full crash log omitted for brevity] The class list file that triggers the problem, generated by JDK 17, looks like this: @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; In contrast, the recent JDK generates class list contents as follows: @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 29 30 @cp java/lang/System$LoggerFinder 1 2 10 27 31 When an old-style class list file is used, the `_resolved_indy_entries` variable remains null, which leads to a crash during `-Xshare:dump`. This PR adds a null check to avoid the crash. After applying this fix, running with the same options no longer results in a crash. Instead, a warning is shown as expected: $ ./jdk-26_fixed/jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld [0.094s][warning][cds] No invoke dynamic constant pool entry can be found for class java/lang/System$LoggerFinder. The classlist is probably out-of-date. # Additional note We may also want to apply the same fix to the `resolved_indy_entry_at` function in the `ConstantPoolCache` class. Please let me know if that is desirable. For reference, the current implementation is: inline ResolvedIndyEntry* ConstantPoolCache::resolved_indy_entry_at(int index) const { return _resolved_indy_entries->adr_at(index); } ------------- Commit messages: - Fix crash occurring during -Xshare:dump Changes: https://git.openjdk.org/jdk/pull/26770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26770&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356324 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26770/head:pull/26770 PR: https://git.openjdk.org/jdk/pull/26770 From sjohanss at openjdk.org Thu Aug 14 08:05:17 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 14 Aug 2025 08:05:17 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Albert Thanks for looking at this and improving the CPU tracking and making it easily accessible. Overall I think the change looks good, just a few comments/questions. src/hotspot/os/linux/os_linux.cpp line 4953: > 4951: // to detach itself from the VM - which should result in ESRCH. > 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); > 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. The same goes for the other warnings below. src/hotspot/share/gc/shared/collectedHeap.cpp line 655: > 653: print_tracing_info(); > 654: > 655: log_cpu_time(); As mentioned offline, I would prefer if this was moved away from `CollectedHeap` since it is now not only GC/Heap related times that are tracked. We could add a `Universe::before_exit()` which firsts does the CPU logging before calling `heap()->before_exit()`. As long as we do the logging before, would there be any problem with this? ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3119416367 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275777432 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275805357 From fyang at openjdk.org Thu Aug 14 08:22:16 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 14 Aug 2025 08:22:16 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> References: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> Message-ID: On Tue, 12 Aug 2025 19:54:14 GMT, Yuri Gaevsky wrote: >> Hello All, >> >> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. >> >> Thank you, >> -Yuri Gaevsky >> >> **Correctness checks:** >> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. > > Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check for zero length; changed lmul from m8 to m2. Not sure if I understand it correctly, but from your JMH numbers seems we are using more `ns` for each `op` with UseRVV? I see the unit of the numbers is `ns/op`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3187438856 From aph at openjdk.org Thu Aug 14 08:22:56 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 14 Aug 2025 08:22:56 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <5FApr4WEXwj9m8ZW42vuiavfL1vv4-l9quJkfDnUKNU=.0600001e-5f14-48e8-a507-78903f9b5bdc@github.com> On Wed, 13 Aug 2025 22:17:48 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Bernhard Urban-Forster > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: > >> 247: // If we got a SIGBUS because we tried to write into the code >> 248: // cache, try enabling WXWrite mode. >> 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr)) { > > Suggestion: > > if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { > > I think we want to make sure the code doing the write is outside the codecache. Ah yes, good point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2275848624 From aph at openjdk.org Thu Aug 14 08:22:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 14 Aug 2025 08:22:55 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/df402a45..b82d1500 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Thu Aug 14 08:22:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 14 Aug 2025 08:22:55 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Wed, 13 Aug 2025 21:59:51 GMT, Dean Long wrote: > ...my implementation, having mode tracking logic around in the "middle", and around condition code, rather than pushing it down to the leaves or up to the entry point meant more maintenance when the code changed, so I'm happy to abandon my prototype in favor of this simpler apprach. Thank you for that, and for your help and advice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3187412144 From ayang at openjdk.org Thu Aug 14 08:30:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 08:30:12 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v5] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <6GlJhfeNLfQPk0ojR6IG1LMs-awAJkzNH7i2-p4xFx0=.358b9ada-97ff-4503-9f2d-ba92de70bee7@github.com> On Tue, 12 Aug 2025 12:21:53 GMT, Anton Artemov wrote: > I do not think so, getters return a copy of the thread's address. My previous msg was probably unclear -- I meant to use `Atomic::load` in the getter, which is exactly what is in the latest revision. > ... as we never will have update of the value happening concurrently with the read, as there is an expensive operation between the two I think it's fragile to rely on surrounding code to maintain the desired memory ordering. An `acquire` fence on the reader side makes it more explicit and convey the intention clearly. Maybe this is subjective, up to you and other reviewers to decide. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3187466382 From duke at openjdk.org Thu Aug 14 08:56:19 2025 From: duke at openjdk.org (Ruben) Date: Thu, 14 Aug 2025 08:56:19 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Ruben has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26678/files - new: https://git.openjdk.org/jdk/pull/26678/files/441008a8..2d8012a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From duke at openjdk.org Thu Aug 14 08:56:20 2025 From: duke at openjdk.org (Ruben) Date: Thu, 14 Aug 2025 08:56:20 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 11 Aug 2025 08:17:35 GMT, Ruben wrote: >> src/hotspot/cpu/s390/s390.ad line 1652: >> >>> 1650: public: >>> 1651: >>> 1652: static int emit_exception_handler(C2_MacroAssembler *masm); >> >> Is this declaration still needed? > > No, it should be removed as well - I will update the patch. Removed. >> src/hotspot/share/code/nmethod.cpp line 1486: >> >>> 1484: } >>> 1485: >>> 1486: assert(offsets->value(CodeOffsets::Deopt ) != -1, "must be set"); >> >> It might be good to leave this line where it was at the beginning of the block, just to avoid one more diff. > > Sure, I will update this. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2275957410 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2275957769 From sspitsyn at openjdk.org Thu Aug 14 09:17:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 14 Aug 2025 09:17:12 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 00:01:29 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - added _ >> - wong phase > > src/hotspot/share/prims/jvmtiExport.cpp line 1838: > >> 1836: { >> 1837: ThreadInVMfromJava tiv(thread); >> 1838: state = get_jvmti_thread_state(thread); > > The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else. Thank you, Patricio! Good catch and suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2276043185 From duke at openjdk.org Thu Aug 14 09:20:20 2025 From: duke at openjdk.org (Ruben) Date: Thu, 14 Aug 2025 09:20:20 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks for the feedback, I've updated the change. >> I've run tier1-tier3 tests, however only on AArch64 and x86-64. >> I can run more tests on these platforms if that might be useful. > As you've touched a few other platforms' files it might be a good idea (to be on the safe-side). To clarify my earlier comment: when I said "I can run more tests on these platforms if that might be useful.", I meant more testing on AArch64 and x86-64 only. I don't have any other platform available for testing. Does the testing infrastructure on the Github/CI provide a way to run the tests on other platforms by any chance? Otherwise, to stay on the safe side, I could revert the change for the platforms other than AArch64 and x86-64. Please let me know which path you prefer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3187709818 From kbarrett at openjdk.org Thu Aug 14 09:26:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Aug 2025 09:26:13 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail [v2] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:32:29 GMT, Matthias Baesken wrote: >> When running with asan - enabled binaries, some oops related tests fail. >> This seems to be related to (small) changes in memory layout caused by asan. >> examples : >> runtime/CompressedOops/UseCompressedOops.java >> >> >> java.lang.RuntimeException: 'Zero based' missing from stdout/stderr >> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) >> at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) >> at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) >> at UseCompressedOops.main(UseCompressedOops.java:48) >> 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.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1474) >> >> >> >> >> jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java >> >> >> Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit >> Failed event: >> jdk.GCHeapConfiguration { >> startTime = 13:13:02.886 (2025-08-09) >> minSize = 100.0 MB >> maxSize = 100.0 MB >> initialSize = 100.0 MB >> usesCompressedOops = true >> compressedOopsMode = "Non-zero based" >> objectAlignment = 8 bytes >> heapAddressBits = 32 >> } >> >> ----------System.err:(20/1718)---------- >> java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit >> at jdk.test.lib.Asserts.fail(Asserts.java:715) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) >> at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) >> at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) >> at jdk.test.lib.jfr.EventField.equal(EventField.java:50) >> at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) >> at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) >> at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) >> at jdk.jfr.event.gc.config... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Unify comments Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26760#pullrequestreview-3119794297 From ihse at openjdk.org Thu Aug 14 09:31:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Aug 2025 09:31:17 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - conditional includes > - variants If I recall correctly the original approach was even simpler: I counted the number of `#include`s in the C++ source files, not in the dependency files of a particular build. Crude but effective, and left out discussions about differences between platforms and feature configurations. And then I had to do some adjustments for Windows where my approach of excluding inline files did not hold and caused a regression. I think your approach seems more valid, but maybe we get stuck in details then instead... But then again, this is basically an optimization problem (even if it is not about running code in the JVM, but about optimizing build speed) so there is no way around the mantra of measure, measure and measure again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3187744222 From dlong at openjdk.org Thu Aug 14 09:33:22 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 09:33:22 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: > 247: // If we got a SIGBUS because we tried to write into the code > 248: // cache, try enabling WXWrite mode. > 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { This code is only needed if we forgot a call to os::thread_wx_enable_write(), right? Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are. Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2276085603 From dfenacci at openjdk.org Thu Aug 14 09:34:11 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 14 Aug 2025 09:34:11 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <9IEMl2w8CY_sdhRilbCqcyO_XAcJrPI3ZhEluhJlbA8=.081b62d2-a673-4562-a64c-8479d588fd7f@github.com> On Thu, 14 Aug 2025 09:17:32 GMT, Ruben wrote: > I don't have any other platform available for testing. Sorry, I misread your comment. > Does the testing infrastructure on the Github/CI provide a way to run the tests on other platforms by any chance? Not that I'm aware of but you could for instance ask port maintainers to run a few tiers for you: https://wiki.openjdk.org/display/HotSpot/Ports ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3187759699 From ogillespie at openjdk.org Thu Aug 14 09:45:30 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 14 Aug 2025 09:45:30 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <3hnIqLdW3eirP60O2I27nGiwIi16fnLh3fc_-P2UG90=.d0940341-0cfc-47d1-979f-9478059cbc78@github.com> On Mon, 16 May 2022 15:52:22 GMT, Oli Gillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I came back to this problem recently as I had another case of performance issues in Cascade Lake due to throttling. I'll open another PR with fresh data. > @olivergillespie you can test your application with -XX:MaxVectorSize=32 product flag to see effects of https://github.com/openjdk/jdk/pull/8877 changes. This idea makes a lot of sense, but I tested and it doesn't avoid throttling in all (any?) cases. For example with the SPECjvm mpegaudio benchmark, my Cascade Lake processor averages around 2.7GHz with `MaxVectorSize=32`, and 3.09GHz with `UseAVX=2`. I spent some time chasing down which instructions were causing it, but I think there's quite a few. Even with `UseAVX=2`, we do not avoid all throttling. For example, `vpxor` and `vpmovdqu` in `MacroAssembler::xmm_clear_mem` are each enough to trigger throttling on their own (I'm not sure why...). I have a benchmark which runs at 2.7GHz with `-XX:UseAVX=2`, and 3.1GHz if using `-XX:-UseXMMForObjInit`, or if I manually skip the `vpxor` and `vpmovdqu` in `xmm_clear_mem`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/8731#issuecomment-3187811516 From shade at openjdk.org Thu Aug 14 09:49:12 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Aug 2025 09:49:12 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... Have you figured out why it started crashing with 21.0.5? I.e. what was the change that triggered it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26770#issuecomment-3187823940 From jbhateja at openjdk.org Thu Aug 14 10:44:33 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 14 Aug 2025 10:44:33 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, Oli Gillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. > I came back to this problem recently as I had another case of performance issues in Cascade Lake due to throttling. I'll open another PR with fresh data. > > > @olivergillespie you can test your application with -XX:MaxVectorSize=32 product flag to see effects of #8877 changes. > > This idea makes a lot of sense, but I tested and it doesn't avoid throttling in all (any?) cases. For example with the SPECjvm mpegaudio benchmark, my Cascade Lake processor averages around 2.7GHz with `MaxVectorSize=32`, and 3.09GHz with `UseAVX=2`. I spent some time chasing down which instructions were causing it, but I think there's quite a few. > > Even with `UseAVX=2`, we do not avoid all throttling. For example, `vpxor` and `vpmovdqu` in `MacroAssembler::xmm_clear_mem` are each enough to trigger throttling on their own (I'm not sure why...). I have a benchmark which runs at 2.7GHz with `-XX:UseAVX=2`, and 3.1GHz if using `-XX:-UseXMMForObjInit`, or if I manually skip the `vpxor` and `vpmovdqu` in `xmm_clear_mem`. One good way to justify your claim is to write a C-micro with inline assembly sequence to clear a blob of memory using vmovduq and vpxor instructions operating over YMM register and XMM registers. In general, both VMOVDQU and VPXOR are AVX2 light instructions and should fall in same frequency/licensingn level of SSE instructions. image ------------- PR Comment: https://git.openjdk.org/jdk/pull/8731#issuecomment-3187981493 From ogillespie at openjdk.org Thu Aug 14 11:12:32 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 14 Aug 2025 11:12:32 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, Oli Gillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Thanks! I did that but I have not been able to reproduce it like that, so I'm confused. I've also used https://github.com/travisdowns/avx-turbo to do the same, and equally it doesn't show throttling from those instructions. I must be missing something subtle about the encoding or the register usage. diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp b/src/hotspot/cpu/x86/macroAssembler_x86.cpp index 6ebf3b50172..01a67856785 100644 --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp @@ -5978,7 +5978,7 @@ void MacroAssembler::xmm_clear_mem(Register base, Register cnt, Register rtmp, X bool use64byteVector = (MaxVectorSize == 64) && (VM_Version::avx3_threshold() == 0); if (use64byteVector) { vpxor(xtmp, xtmp, xtmp, AVX_512bit); - } else if (MaxVectorSize >= 32) { + } else if (MaxVectorSize >= 32 && !UseNewCode) { vpxor(xtmp, xtmp, xtmp, AVX_256bit); } else { pxor(xtmp, xtmp); @@ -5986,7 +5986,7 @@ void MacroAssembler::xmm_clear_mem(Register base, Register cnt, Register rtmp, X jmp(L_zero_64_bytes); BIND(L_loop); - if (MaxVectorSize >= 32) { + if (MaxVectorSize >= 32 && !UseNewCode2) { fill64(base, 0, xtmp, use64byteVector); } else { movdqu(Address(base, 0), xtmp); Against my benchmark (a subset of mpegaudio): +UseNewCode -UseNewCode2 -> fill64, no vpxor throttle (2.7GHz) -UseNewCode +UseNewCode2 -> no fill64, vpxor throttle (2.7GHz) +UseNewCode +UseNewCode2 -> no fill64, no vpxor no throttle (3.1GHz) ------------- PR Comment: https://git.openjdk.org/jdk/pull/8731#issuecomment-3188062666 From mbaesken at openjdk.org Thu Aug 14 11:15:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Aug 2025 11:15:22 GMT Subject: RFR: 8365487: [asan] some oops (mode) related tests fail [v2] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:32:29 GMT, Matthias Baesken wrote: >> When running with asan - enabled binaries, some oops related tests fail. >> This seems to be related to (small) changes in memory layout caused by asan. >> examples : >> runtime/CompressedOops/UseCompressedOops.java >> >> >> java.lang.RuntimeException: 'Zero based' missing from stdout/stderr >> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) >> at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) >> at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) >> at UseCompressedOops.main(UseCompressedOops.java:48) >> 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.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1474) >> >> >> >> >> jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java >> >> >> Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit >> Failed event: >> jdk.GCHeapConfiguration { >> startTime = 13:13:02.886 (2025-08-09) >> minSize = 100.0 MB >> maxSize = 100.0 MB >> initialSize = 100.0 MB >> usesCompressedOops = true >> compressedOopsMode = "Non-zero based" >> objectAlignment = 8 bytes >> heapAddressBits = 32 >> } >> >> ----------System.err:(20/1718)---------- >> java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit >> at jdk.test.lib.Asserts.fail(Asserts.java:715) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) >> at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) >> at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) >> at jdk.test.lib.jfr.EventField.equal(EventField.java:50) >> at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) >> at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) >> at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) >> at jdk.jfr.event.gc.config... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Unify comments Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26760#issuecomment-3188063999 From mbaesken at openjdk.org Thu Aug 14 11:15:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Aug 2025 11:15:23 GMT Subject: Integrated: 8365487: [asan] some oops (mode) related tests fail In-Reply-To: References: Message-ID: <8nf5bk0-TBe4FuvP_Lye2Phx-OQId_3NNoQUaGmxCa0=.178e8276-e682-42ea-b9cb-46566889982e@github.com> On Wed, 13 Aug 2025 13:23:45 GMT, Matthias Baesken wrote: > When running with asan - enabled binaries, some oops related tests fail. > This seems to be related to (small) changes in memory layout caused by asan. > examples : > runtime/CompressedOops/UseCompressedOops.java > > > java.lang.RuntimeException: 'Zero based' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:98) > at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:59) > at UseCompressedOops.main(UseCompressedOops.java:48) > 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.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > > > jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java > > > Error: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > Failed event: > jdk.GCHeapConfiguration { > startTime = 13:13:02.886 (2025-08-09) > minSize = 100.0 MB > maxSize = 100.0 MB > initialSize = 100.0 MB > usesCompressedOops = true > compressedOopsMode = "Non-zero based" > objectAlignment = 8 bytes > heapAddressBits = 32 > } > > ----------System.err:(20/1718)---------- > java.lang.RuntimeException: Value not equal to 32-bit, field='compressedOopsMode', value='Non-zero based' expected: Non-zero based but was: 32-bit > at jdk.test.lib.Asserts.fail(Asserts.java:715) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) > at jdk.test.lib.jfr.EventField.lambda$equal$0(EventField.java:50) > at jdk.test.lib.jfr.EventField.doAssert(EventField.java:114) > at jdk.test.lib.jfr.EventField.equal(EventField.java:50) > at jdk.test.lib.jfr.EventVerifier.verifyEquals(EventVerifier.java:35) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventVerifier.verifyCompressedOopModeIs(GCHeapConfigurationEventVerifier.java:59) > at jdk.jfr.event.gc.configuration.ThirtyTwoBitsVerifier.verify(TestGCHeapConfigurationEventWith32BitOops.java:74) > at jdk.jfr.event.gc.configuration.GCHeapConfigurationEventTester.run(GCHeapConfigurationEventTester.java:46) > ... This pull request has now been integrated. Changeset: 98f54d90 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/98f54d90ea56f63c2fc5137af98b57dbc90fe150 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod 8365487: [asan] some oops (mode) related tests fail Reviewed-by: kbarrett, syan ------------- PR: https://git.openjdk.org/jdk/pull/26760 From ogillespie at openjdk.org Thu Aug 14 11:28:27 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 14 Aug 2025 11:28:27 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, Oli Gillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. FWIW, I also gathered perf counters on a Skylake (stepping=4) host (my EC2 Cascade Lake instance does not expose hardware perf counters). In the full `mpegaudio` benchmark: java -jar SPECjvm2008.jar --ignoreCheckTest -ikv --benchmarkThreads 1 --iterationTime 10s --warmupTime 10s mpegaudio # after warmup sudo perf stat -a -C 1 -e core_power.lvl0_turbo_license -e core_power.lvl1_turbo_license -e core_power.lvl2_turbo_license -e core_power.throttle -- sleep 5 UseAVX=3 352,262,777 core_power.lvl0_turbo_license 13,606,422,784 core_power.lvl1_turbo_license 1,304,765,823 core_power.lvl2_turbo_license 43,879,483 core_power.throttle UseAVX=3 MaxVectorSize=32 308,363,591 core_power.lvl0_turbo_license 15,169,908,798 core_power.lvl1_turbo_license 0 core_power.lvl2_turbo_license 103,330 core_power.throttle UseAVX=2 16,231,858,845 core_power.lvl0_turbo_license 9,584,504 core_power.lvl1_turbo_license 0 core_power.lvl2_turbo_license 59,489 core_power.throttle So MaxVectorSize=32 does remove lvl2 throttling, but leaves a huge amount of lvl1, which UseAVX2 all but eliminates. And for my subset benchmark, AVX=2 does not make any difference, but removing xmm_clear_mem clearly does. UseAVX=3 29,136,581 core_power.lvl0_turbo_license 15,712,155,433 core_power.lvl1_turbo_license 0 core_power.lvl2_turbo_license 8,726 core_power.throttle UseAVX=2 45,202,936 core_power.lvl0_turbo_license 15,717,333,898 core_power.lvl1_turbo_license 0 core_power.lvl2_turbo_license 10,711 core_power.throttle UseAVX=3 -UseXMMForObjInit 16,550,998,060 core_power.lvl0_turbo_license 6,456,252 core_power.lvl1_turbo_license 0 core_power.lvl2_turbo_license 482 core_power.throttle ------------- PR Comment: https://git.openjdk.org/jdk/pull/8731#issuecomment-3188104949 From sjohanss at openjdk.org Thu Aug 14 11:30:18 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 14 Aug 2025 11:30:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:49:26 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > src/hotspot/os/linux/os_linux.cpp line 4953: > >> 4951: // to detach itself from the VM - which should result in ESRCH. >> 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >> 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); > > Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? > > The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. > > The same goes for the other warnings below. Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276356967 From mhaessig at openjdk.org Thu Aug 14 12:01:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 14 Aug 2025 12:01:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v6] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from Christian Co-authored-by: Christian Hagedorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/8bb5eb7a..3689fc71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Thu Aug 14 12:01:08 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 14 Aug 2025 12:01:08 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v5] In-Reply-To: <7ZSL2sR91qOFup-zauB0VKCoLYB9dHMn3GGwLmo-gEk=.e790e543-fb41-42cd-add2-1f5f4a141afb@github.com> References: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> <7ZSL2sR91qOFup-zauB0VKCoLYB9dHMn3GGwLmo-gEk=.e790e543-fb41-42cd-add2-1f5f4a141afb@github.com> Message-ID: On Wed, 13 Aug 2025 08:31:11 GMT, Christian Hagedorn wrote: >> Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8308094-timeout >> - Rename _timer >> - remove _timeout_armed >> - ASSERT >> - Merge branch 'master' into JDK-8308094-timeout >> - No acquire release semantics >> - Factor Linux specific timeout functionality out of share/ >> - Move timeout disarm above if >> - Merge branch 'master' into JDK-8308094-timeout >> - Fix SIGALRM test >> - ... and 1 more: https://git.openjdk.org/jdk/compare/098f25d4...8bb5eb7a > > src/hotspot/os/linux/compilerThreadTimeout_linux.hpp line 46: > >> 44: #endif // !PRODUCT >> 45: public: >> 46: CompilerThreadTimeoutLinux() NOT_PRODUCT(DEBUG_ONLY(: _timer(nullptr))) {}; > > Why do you need the `NOT_PRODUCT`? It only wraps `DEBUG_ONLY`. If that's not set, the `NOT_PRODUCT` wraps nothing. The initialization list should only be generated if `!PRODUCT && ASSERT`, so it does not appear in `optimized`. This is one way of expressing this conjunction in macros. > src/hotspot/share/compiler/compilerThread.hpp line 54: > >> 52: void disarm() { return; }; >> 53: bool init_timeout() { return true; }; >> 54: }; > > Should we also guard this with `ifndef LINUX` since it's only used for non-Linux? Sounds reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2276419674 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2276420718 From ayang at openjdk.org Thu Aug 14 12:22:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Aug 2025 12:22:13 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:27:10 GMT, Stefan Johansson wrote: >> src/hotspot/os/linux/os_linux.cpp line 4953: >> >>> 4951: // to detach itself from the VM - which should result in ESRCH. >>> 4952: assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed"); >>> 4953: log_warning(os)("Could not sample thread CPU time (return code %d)", rc); >> >> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal? >> >> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output. >> >> The same goes for the other warnings below. > > Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. > ... it might happen from time to time without it being a very big deal? My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276473605 From duke at openjdk.org Thu Aug 14 13:11:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 13:11:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 12:19:58 GMT, Albert Mingkun Yang wrote: >> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings. > >> ... it might happen from time to time without it being a very big deal? > > My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276583734 From duke at openjdk.org Thu Aug 14 13:11:14 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 13:11:14 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 15:17:19 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > src/hotspot/share/gc/shared/collectedHeap.cpp line 610: > >> 608: } >> 609: >> 610: double percent_of(double component_cpu_time, double process_cpu_time) { > > There is global function, `percent_of`. Can that be used directly? Thanks! Certainly I misread your previous suggestion as a rename suggestion as I was not aware of that global function :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276587345 From mablakatov at openjdk.org Thu Aug 14 13:56:15 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Thu, 14 Aug 2025 13:56:15 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v5] In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> Message-ID: > Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. > > This has passed tier1-3 and jcstress testing on AArch64. Mikhail Ablakatov has updated the pull request incrementally with one additional commit since the last revision: remove implementation-dependent logic from emit_shared_trampolines() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25954/files - new: https://git.openjdk.org/jdk/pull/25954/files/9912e5c4..de2464d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=03-04 Stats: 13 lines in 4 files changed: 0 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954 PR: https://git.openjdk.org/jdk/pull/25954 From mhaessig at openjdk.org Thu Aug 14 14:02:02 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 14 Aug 2025 14:02:02 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v7] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with four additional commits since the last revision: - Add test - Remove superfluous NOT_PRODUCT - Report which compilation timed out - Exclude generic class for Linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/3689fc71..9a43ef26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=05-06 Stats: 63 lines in 4 files changed: 54 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Thu Aug 14 14:02:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 14 Aug 2025 14:02:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v5] In-Reply-To: <7ZSL2sR91qOFup-zauB0VKCoLYB9dHMn3GGwLmo-gEk=.e790e543-fb41-42cd-add2-1f5f4a141afb@github.com> References: <6gq4iIBw4RIqqPvmAf2MHnKrmYHwOdWdH1fz1bFaCGA=.57906956-460f-4a1d-9e3e-fbf91a7974e2@github.com> <7ZSL2sR91qOFup-zauB0VKCoLYB9dHMn3GGwLmo-gEk=.e790e543-fb41-42cd-add2-1f5f4a141afb@github.com> Message-ID: On Wed, 13 Aug 2025 08:40:25 GMT, Christian Hagedorn wrote: >> Manuel H?ssig has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8308094-timeout >> - Rename _timer >> - remove _timeout_armed >> - ASSERT >> - Merge branch 'master' into JDK-8308094-timeout >> - No acquire release semantics >> - Factor Linux specific timeout functionality out of share/ >> - Move timeout disarm above if >> - Merge branch 'master' into JDK-8308094-timeout >> - Fix SIGALRM test >> - ... and 1 more: https://git.openjdk.org/jdk/compare/b93dcf2a...8bb5eb7a > > Nice improvement! I left some small comments in the code but otherwise the change looks reasonable! > > Can we also add some tests for the new `CompileTaskTimeout` flag? Maybe we can add a positive test and negative test: > - Positive test: Could just be a hello world test with a reasonably large non-zero value for `CompileTaskTimeout`. > - Negative test: Maybe we can just set `CompileTaskTimeout=1` which will probably crash immediately for a hello world program. That could be run in a separate VM and then we can check the output. If we are able to also dump the compile task/method that is timing out, we might even be able to match on that when run with `CompileOnly` for a single method. But not sure if the latter is possible. > > What do you think? Thank you for looking at this, @chhagedorn. I added a simple test and addressed the rest of your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3188563311 From duke at openjdk.org Thu Aug 14 14:12:18 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 14:12:18 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v6] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Minor improvements and fixes per @kstefanj suggestions - use percent_of from globalDefinitions.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/143fcacb..ddab1f0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=04-05 Stats: 118 lines in 4 files changed: 60 ins; 57 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Thu Aug 14 14:12:21 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 14 Aug 2025 14:12:21 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 08:02:45 GMT, Stefan Johansson wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Albert > > Thanks for looking at this and improving the CPU tracking and making it easily accessible. > > Overall I think the change looks good, just a few comments/questions. Thanks for the review @kstefanj! I've pushed a patch reflecting your suggestions, but saved removal of log_warning until we have a consensus on a path forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3188595880 From asmehra at openjdk.org Thu Aug 14 14:13:29 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 14 Aug 2025 14:13:29 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Thu, 14 Aug 2025 07:36:13 GMT, Yudi Zheng wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 148: > >> 146: >> 147: enum Feature_Flag { >> 148: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = bit, > > It would be greatly appreciated if you could give the Graal devs a heads-up when changing CPU feature flags. JVMCI sees different CPU features with this change, and eventually leads to SIGILL by generating instruction not supported by the underlying CPU. @mur47x111 sorry for breaking JVMCI with this. I was not aware of such a dependency at all and I touched this code for the first time. For future work, how do I check if my change in hotspot has the potential to break JVMCI? And what is the best forum to inform about such changes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2276753999 From mhaessig at openjdk.org Thu Aug 14 14:57:36 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 14 Aug 2025 14:57:36 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Fix format string ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/9a43ef26..ee64b092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From sspitsyn at openjdk.org Thu Aug 14 15:01:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 14 Aug 2025 15:01:11 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 09:15:03 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1838: >> >>> 1836: { >>> 1837: ThreadInVMfromJava tiv(thread); >>> 1838: state = get_jvmti_thread_state(thread); >> >> The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else. > > Thank you, Patricio! Good catch and suggestion. This can be kind of intrusive, something like below (without changes from Leonid): @@ -1830,6 +1830,16 @@ void JvmtiExport::post_method_entry(JavaThread *thread, Method* method, frame cu void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) { HandleMark hm(thread); methodHandle mh(thread, method); + Handle result; + jvalue value; + oop oop_result; + BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); + + value.j = 0L; + if (is_reference_type(type)) { + result = Handle(thread, oop_result); + value.l = JNIHandles::make_local(thread, result()); + } JvmtiThreadState *state = get_jvmti_thread_state(thread); @@ -1841,21 +1851,15 @@ void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame cur // return a flag when a method terminates by throwing an exception // i.e. if an exception is thrown and it's not caught by the current method bool exception_exit = state->is_exception_detected() && !state->is_exception_caught(); - Handle result; - jvalue value; - value.j = 0L; if (state->is_enabled(JVMTI_EVENT_METHOD_EXIT)) { // if the method hasn't been popped because of an exception then we populate // the return_value parameter for the callback. At this point we only have // the address of a "raw result" and we just call into the interpreter to // convert this into a jvalue. - if (!exception_exit) { - oop oop_result; - BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); + if (exception_exit) { if (is_reference_type(type)) { - result = Handle(thread, oop_result); - value.l = JNIHandles::make_local(thread, result()); + value.j = 0L; } } } Not sure yet how to make it simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2276882958 From mablakatov at openjdk.org Thu Aug 14 15:41:36 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Thu, 14 Aug 2025 15:41:36 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v6] In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> Message-ID: > Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. > > The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. > > This has passed tier1-3 and jcstress testing on AArch64. Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d' - remove implementation-dependent logic from emit_shared_trampolines() - cleanup: update copyright headers - Make the value type of the dictionary a struct instead of Pair typedef - Remove share_rc_trampoline_for and share_sc_trampoline_for - Merge branch 'master' - Address review comments from @theRealAph and @eastig - use relocInfo::relocType instead of TrampolineCallKind - move rtype from keys to values; reduce the footprint of the patch - Lift the vm.opt.TieredCompilation == null requirement from the tests - Combine the two shared trampoline request hash tables - 8359359: AArch64: share trampolines between static calls to the same method Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee. The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls. ------------- Changes: https://git.openjdk.org/jdk/pull/25954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=05 Stats: 429 lines in 9 files changed: 307 ins; 110 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954 PR: https://git.openjdk.org/jdk/pull/25954 From fgao at openjdk.org Thu Aug 14 15:59:10 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 14 Aug 2025 15:59:10 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> Message-ID: On Fri, 8 Aug 2025 11:37:29 GMT, Andrew Haley wrote: >>> > I've done some modelling using llvm-mca and it looks like `adrp; add` is a win on recent Apple processors as well as on Arm processors, so go ahead with making this the default. >>> >>> Thanks for testing that ? really great to hear! I?ll update the patch with a constraint for AOT cache shortly. >> >> Correction: I'm afraid that the llvm-mca results are nonsense. It says that this sequence >> >> >> movk w0, #0x1234, lsl 16 >> movk w1, #0x1234, lsl 16 >> movk w2, #0x1234, lsl 16 >> movk w3, #0x1234, lsl 16 >> movk w4, #0x1234, lsl 16 >> movk w5, #0x1234, lsl 16 >> movk w6, #0x1234, lsl 16 >> movk w7, #0x1234, lsl 16 >> >> takes 2 clock cycles on Apple M1, but Dougall Johnson measured real hardware executing this at 1 clock cycle. >> >> I'm not going to believe any more without numbers we can trust. > >> I'm not going to believe any more without numbers we can trust. > > Sorry, it's 6 movz/movk per cycle, which I just confirmed by measuring it myself. Hi @theRealAph, I conducted some performance `C` tests across different platforms to compare `adrp + add` pairs with `movz + movk + movk` triples. The test loop looks like this: clock_t start, end; double cpu_time_used; long iteration = 200000000; start = clock(); for (long i = 0; i < iteration; i++) { test(); } end = clock(); cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC; printf("Test %s time: %f\n", name(NAME), cpu_time_used); `test()` Function Contents: `adrp + add` pattern (48 pairs using different registers `x0-18`): adrp x0, .LFB0 add x0, x0, #0xf00 adrp x1, .LFB0 add x1, x1, #0xf00 adrp x2, .LFB0 add x2, x2, #0xf00 ... `mov` triple pattern (48 sets using different registers `x0-18`): mov x0, #0x1218 movk x0, #0xc801, lsl #16 movk x0, #0xeee4, lsl #32 mov x1, #0x1218 movk x1, #0xc801, lsl #16 movk x1, #0xeee4, lsl #32 mov x2, #0x1218 movk x2, #0xc801, lsl #16 movk x2, #0xeee4, lsl #32 ... Here are results on different platforms: n1 : Test adrp time: 2.245888 Test movks time: 3.335474 v1 : Test adrp time: 1.953309 Test movks time: 2.870085 v2 : Test adrp time: 1.561889 Test movks time: 2.271725 m2 : Test adrp time: 0.965305 Test movks time: 1.264298 I also tested sequences reusing the same registers `x8`, and `adrp + add` still showed performance advantages across all platforms. Do you think these numbers are trustworthy? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3188968224 From lmesnik at openjdk.org Thu Aug 14 17:59:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 14 Aug 2025 17:59:13 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 00:01:29 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - added _ >> - wong phase > > src/hotspot/share/prims/jvmtiExport.cpp line 1838: > >> 1836: { >> 1837: ThreadInVMfromJava tiv(thread); >> 1838: state = get_jvmti_thread_state(thread); > > The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else. Thank you @pchilano and @sspitsyn for finding and explaining the issue. I need some more time to understand how to better correctly preserve the result oop in post_method_exit before we can starting read jvmti_state. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2277367830 From liach at openjdk.org Thu Aug 14 18:50:13 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 14 Aug 2025 18:50:13 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 06:22:15 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed bugs found in JCK testing src/hotspot/share/cds/cdsConfig.cpp line 940: > 938: > 939: bool CDSConfig::is_old_class_for_verifier(const InstanceKlass* ik) { > 940: return ik->major_version() < 50 /*JAVA_6_VERSION*/; Java 6 classes may have methods with no stack maps, which falls back to old verification. Does InstanceKlass have info on whether each method used the old verifier or StackMapTable? Attribute detection alone does not work because SMT may be omitted if the control flow is trivial. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2277456886 From duke at openjdk.org Thu Aug 14 18:55:13 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Thu, 14 Aug 2025 18:55:13 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: References: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> Message-ID: On Thu, 14 Aug 2025 08:19:00 GMT, Fei Yang wrote: > Not sure if I understand it correctly, but from your JMH numbers seems we are using more `ns` for each `op` with UseRVV? That's true - the LMUL change to `m2` is an attempt to improve perfromance for small sizes as much as possible. I've just measured large sizes and it's also not good: m2: ======================================================================================== -XX:-UseRVV -XX:+UseRVV ======================================================================================== Benchmark (size) Mode Cnt Score Error Score Error Units Int.differentSubrangeMatches 100 avgt 10 137.172 ? 0.054 98.497 ? 0.310 ns/op Int.differentSubrangeMatches 200 avgt 10 156.312 ? 0.281 140.852 ? 0.361 ns/op Int.differentSubrangeMatches 300 avgt 10 327.659 ? 0.317 191.959 ? 0.440 ns/op Int.differentSubrangeMatches 400 avgt 10 240.912 ? 0.429 230.264 ? 0.164 ns/op Int.differentSubrangeMatches 500 avgt 10 523.581 ? 0.292 286.112 ? 0.307 ns/op Int.differentSubrangeMatches 600 avgt 10 352.296 ? 0.480 322.362 ? 0.924 ns/op Int.differentSubrangeMatches 700 avgt 10 725.652 ? 0.555 382.037 ? 0.434 ns/op Int.differentSubrangeMatches 800 avgt 10 455.651 ? 1.003 412.241 ? 0.411 ns/op ---------------------------------------------------------------------------------------- Int.matches 100 avgt 10 143.116 ? 0.627 128.433 ? 0.057 ns/op Int.matches 200 avgt 10 227.868 ? 0.190 231.481 ? 0.343 ns/op Int.matches 300 avgt 10 336.983 ? 0.094 301.416 ? 0.279 ns/op Int.matches 400 avgt 10 440.492 ? 0.503 389.587 ? 0.752 ns/op Int.matches 500 avgt 10 524.292 ? 0.828 490.197 ? 1.283 ns/op Int.matches 600 avgt 10 627.717 ? 0.880 577.573 ? 0.764 ns/op Int.matches 700 avgt 10 730.503 ? 0.281 719.430 ? 0.278 ns/op Int.matches 800 avgt 10 831.331 ? 0.446 810.678 ? 0.482 ns/op ---------------------------------------------------------------------------------------- Int.mismatchEnd 100 avgt 10 133.878 ? 0.434 106.791 ? 0.056 ns/op Int.mismatchEnd 200 avgt 10 220.972 ? 1.055 223.622 ? 0.110 ns/op Int.mismatchEnd 300 avgt 10 326.363 ? 0.069 294.368 ? 0.076 ns/op Int.mismatchEnd 400 avgt 10 432.284 ? 0.311 380.235 ? 0.096 ns/op Int.mismatchEnd 500 avgt 10 512.964 ? 0.139 466.615 ? 0.135 ns/op Int.mismatchEnd 600 avgt 10 613.120 ? 0.291 568.137 ? 0.120 ns/op Int.mismatchEnd 700 avgt 10 716.861 ? 0.667 709.291 ? 0.571 ns/op Int.mismatchEnd 800 avgt 10 821.902 ? 0.564 740.929 ? 0.241 ns/op ---------------------------------------------------------------------------------------- Int.mismatchMid 100 avgt 10 84.289 ? 0.221 77.660 ? 0.018 ns/op Int.mismatchMid 200 avgt 10 142.339 ? 0.228 120.884 ? 0.037 ns/op Int.mismatchMid 300 avgt 10 170.238 ? 0.248 164.259 ? 0.457 ns/op Int.mismatchMid 400 avgt 10 221.964 ? 0.555 207.503 ? 0.126 ns/op Int.mismatchMid 500 avgt 10 275.343 ? 0.848 252.248 ? 0.395 ns/op Int.mismatchMid 600 avgt 10 322.031 ? 0.173 317.887 ? 0.314 ns/op Int.mismatchMid 700 avgt 10 371.653 ? 0.259 337.068 ? 0.069 ns/op Int.mismatchMid 800 avgt 10 419.094 ? 0.087 394.663 ? 0.231 ns/op ---------------------------------------------------------------------------------------- Int.mismatchStart 100 avgt 10 28.920 ? 0.179 34.449 ? 0.015 ns/op Int.mismatchStart 200 avgt 10 28.845 ? 0.051 35.706 ? 0.022 ns/op Int.mismatchStart 300 avgt 10 28.928 ? 0.051 34.444 ? 0.008 ns/op Int.mismatchStart 400 avgt 10 29.369 ? 0.127 35.698 ? 0.008 ns/op Int.mismatchStart 500 avgt 10 29.953 ? 0.595 34.488 ? 0.045 ns/op Int.mismatchStart 600 avgt 10 28.809 ? 0.008 34.459 ? 0.011 ns/op Int.mismatchStart 700 avgt 10 28.930 ? 0.124 35.702 ? 0.009 ns/op Int.mismatchStart 800 avgt 10 28.814 ? 0.017 35.697 ? 0.009 ns/op ======================================================================================== ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3189538950 From adinn at openjdk.org Thu Aug 14 19:15:48 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 14 Aug 2025 19:15:48 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero Message-ID: Fix two problems with Zero blob/stub entry initialization: 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. yhis was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. ------------- Commit messages: - avoid creating AdpaterBlobs on Zero where we cannto use them - Execute stubgen stub create functions even on Zero when no code expected Changes: https://git.openjdk.org/jdk/pull/26787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365558 Stats: 45 lines in 2 files changed: 30 ins; 8 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26787/head:pull/26787 PR: https://git.openjdk.org/jdk/pull/26787 From dnsimon at openjdk.org Thu Aug 14 19:33:15 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 14 Aug 2025 19:33:15 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > After suggestions from Erik and Andrey > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. Would you mind also running tier9 to avoid surprises there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422 From dlong at openjdk.org Thu Aug 14 20:02:16 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:02:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 147: > 145: > 146: void NativeMovConstReg::set_data(intptr_t x) { > 147: //MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Should be OK to remove? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277599424 From dlong at openjdk.org Thu Aug 14 20:12:18 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:12:18 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 80: > 78: // Used in the runtime linkage of calls; see class CompiledIC. > 79: void NativeCall::set_destination_mt_safe(address dest) { > 80: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Probably not needed. set_destination() should take care of this. src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 239: > 237: dest = instruction_address(); > 238: > 239: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Already covered by Patcher constructor? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277616127 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277621596 From dlong at openjdk.org Thu Aug 14 20:15:13 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:15:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 263: > 261: > 262: void NativeGeneralJump::set_jump_destination(address dest) { > 263: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Remove and let set_data() handle it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277631120 From dlong at openjdk.org Thu Aug 14 20:22:14 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:22:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 377: > 375: MacroAssembler a(&cbuf); > 376: > 377: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Harmless, but already handled by set_destination(). I'm not sure about emit_trampoline_stub(). src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp line 51: > 49: > 50: VtableStub* VtableStubs::create_vtable_stub(int vtable_index) { > 51: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Already covered by VtableStub ctor? src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp line 143: > 141: > 142: VtableStub* VtableStubs::create_itable_stub(int itable_index) { > 143: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); Already covered by VtableStub ctor? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277636787 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277641340 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2277641726 From jrose at openjdk.org Thu Aug 14 20:33:14 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 20:33:14 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Wed, 13 Aug 2025 14:20:30 GMT, Claes Redestad wrote: > ? to help the compiler do the right thing with more ease and perhaps slightly faster If the Java code is good enough, then the precondition method can simply be marked `@ForceInline`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189790415 From jrose at openjdk.org Thu Aug 14 20:38:14 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 20:38:14 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. Some more parts to the precondition intrinsic story, FTR: Apart from inlining, one of the goals of the intrinsic preconditions is to allow them to more reliably interact with elimination of range checks. The JVM knows its own intrinsic checks in the `aaload` bytecode (and its brothers), and it also knows its own intrinsic precondition method. Both kinds of checks are fodder for RCE (range check elimination) and specifically the iteration range splitting performed when a loop is factored into pre/main/post loops. The main part is statically proven to traverse an index range which is incapable of failing any of the checks (within the loop body). This RCE in turn unlocks power moves like vectorization. If the precondition check in question works OK for these use cases, it can be marked force-inline, but if there is also evidence that it would unlock more loop optimizations, then it should be made an intrinsic (or else built on top of another intrinsics, with force-inline). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189804162 From dlong at openjdk.org Thu Aug 14 20:40:17 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:40:17 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough I'm not convinced the ZGC regression is real. I see a 1% variance between runs even with the same binary and flags, so it looks like just noise. For this PR I'll stop here. If it turns out that ZGC or Shenandoah do have a small regression because of CAS, we can use direct stores as long as they are done inside a lock, which should be true already for disarm() but would need to be added for make_not_entrant(). @fisk , can I get you to review this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189805391 PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189809429 From dlong at openjdk.org Thu Aug 14 20:44:14 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 14 Aug 2025 20:44:14 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 19:42:31 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Our Graal "tier9" testing passed, so I'm optimistically asking for another round of reviews now, while the longer "tier10" keeps running. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3189817405 From iklam at openjdk.org Thu Aug 14 20:51:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Aug 2025 20:51:10 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: <7tWS1j21tqFe67Vz86fdjTKNvVfJt09pbNfr2awyy6E=.4fbd1e9c-b27b-4fc7-8b8c-ef9af8a4a6bc@github.com> On Thu, 14 Aug 2025 18:43:42 GMT, Chen Liang wrote: > Does InstanceKlass have info on whether each method used the old verifier or StackMapTable? The "fail over" verification happens on the entire class file. If a Java 6 class failed the new verification, it will be verified again with the old verifier. Currently, such classes will be excluded from the AOT cache: https://github.com/openjdk/jdk/blob/c5cbcac828e1c7aa845cf16e68f6306ae49e050c/src/hotspot/share/classfile/verifier.cpp#L231-L243 I will add a test case in this PR to make sure this case is covered. I also created a new RFE to include such classes in the AOT cache: https://bugs.openjdk.org/browse/JDK-8365575 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2277693229 From jrose at openjdk.org Thu Aug 14 21:25:15 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 21:25:15 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. Another comment on the precondition in question: It does not appear to be inside a loop, but rather a precursor to a bulk operation (which searches the sign bits of a byte array slice). It's hard to imagine the JIT doing a better job with that as an intrinsic, since it probably won't be RCE-ed within an enclosing hot loop. So, yes, force-inline it. Volkan found a pre-existing RFE about that precondition check, and I added a lengthy comment to it, FTR: https://bugs.openjdk.org/browse/JDK-8361837#comment-14809088 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3189908913 From jrose at openjdk.org Thu Aug 14 21:37:16 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 21:37:16 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 159: > 157: private static int encodeISOArray(char[] sa, int sp, > 158: byte[] da, int dp, int len) { > 159: if ((sp | dp | len) < 0 || I think this change is OK; I understand it removes uncertainty about inlining of the checking helper method. In general, though, I think we should be using the Preconditions methods, instead of hand-rolling checks from random-looking Java operators. (Sorry, but they will look random to the person reading this years later!) (I think Objects::rNN is overkill; I do believe that the implicit null checks are easy to reason about. I guess tastes vary here. O::rNN is marked force-inline, so that should not be a problem to throw it into the checking logic, as an explicit null check.) Anyway, I would like to a see a comment here, in the code, saying why the Preconditions methods are not used at this point. If there was an inlining problem, let's acknowledge it. It's OK to make String code be a special case (with hand-rolled checks, carefully tuned). Let's document how we did that. One point: I don't think we expect these bulk string operations to occur in a containing hot loop, so the intrinsic value of Precondition methods (to contribute to RCE optimizations) is not required. Still, on the whole, it is usually better to use a named method than a tricky Java operator expression ? much as we all love those! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277764353 From jrose at openjdk.org Thu Aug 14 21:46:16 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 21:46:16 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java line 56: > 54: * @summary Verify `StringCoding::countPositives` intrinsic Java wrapper checks > 55: * by enabling the ones in the compiler intrinsic using > 56: * `-XX:+VerifyIntrinsicChecks` Is this only a negative test for the optional extra range checks? That is to say, do we win if there are no additional throws, when all index inputs are valid (in range)? Or is there some corner of these tests (there are three files here) which intentionally instigates out-of-range errors, by passing out-of-range index inputs, and then makes sure that the expected exceptions occur? It would be good to put in a brief comment saying, "This test does not trigger out-of-range errors. The +VerifyIntrinsicChecks version of this test simply ensures that the assembly code will produce no spurious errors." But it would be nice, someday, to test lots of edge conditions which ARE out-of-range, and make sure (again) that the behavior is the same with and without the +VerifyIntrinsicChecks mode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277777054 From jrose at openjdk.org Thu Aug 14 21:49:17 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 21:49:17 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 90: > 88: } > 89: > 90: private static void violateIntrinsicMethodContract() { Ah, here is the positive test for the extra range checking in mode +VerifyIntrinsicChecks. In the other place where I put a comment, maybe point at this test (in the comment)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277781995 From jrose at openjdk.org Thu Aug 14 22:00:17 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 14 Aug 2025 22:00:17 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Tue, 12 Aug 2025 08:17:58 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove `@apiNote` in `encodeISOArray()` Javadoc > > Those who are touching to these methods should well be > aware of the details elaborated in the `@apiNote`, no > need to put it on a display. This is lovely work. I've left a few suggestions which you may wish to take action on. src/hotspot/share/opto/library_call.cpp line 946: > 944: Node* count, > 945: bool char_count, > 946: bool halt_on_oob) { Adding halt_on_oob is a pro move. It makes it very clear that something very bad is afoot. Now I see why A/B testing was harder to do in the jtreg tests, especially for the "throwing" case. Just a note for the future (no change requested): The InternalError exception is sometimes used for these kinds of "crash and burn" conditiosn. (See the code in java.lang.invoke.) Users can try to catch IE, but they are advised not to, and it will therefore crash the thread (at least), as an unhandled throw. The advantage of using IE is that a jtreg harness can catch it much more easily (as opposed to a hard VM halt). ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3122211152 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2277794171 From iklam at openjdk.org Fri Aug 15 00:20:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Aug 2025 00:20:30 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap Message-ID: This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. ------------- Commit messages: - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - more clean up - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Fixed arm build - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - clean up - java.net.URL class needs runtimeSetup - fixed build - ... and 5 more: https://git.openjdk.org/jdk/compare/25480f00...15746239 Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350550 Stats: 553 lines in 39 files changed: 441 ins; 13 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From dlong at openjdk.org Fri Aug 15 01:05:13 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 01:05:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/share/runtime/javaCalls.cpp line 319: > 317: > 318: void JavaCalls::call(JavaValue* result, const methodHandle& method, JavaCallArguments* args, TRAPS) { > 319: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, THREAD)); I think this is already covered by call_helper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2278027439 From dlong at openjdk.org Fri Aug 15 01:12:24 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 01:12:24 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/share/runtime/javaCalls.cpp line 330: > 328: > 329: JavaThread* thread = THREAD; > 330: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, THREAD)); JavaCallWrapper::JavaCallWrapper() is already calling enable_wx(WXExec), and JavaCallWrapper::~JavaCallWrapper() is calling enable_wx(WXWrite), so we have double coverage. Can we remove the calls from JavaCallWrapper and just keep this one, and maybe move it down closer to the StubRoutines::call_stub()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2278034043 From ksakata at openjdk.org Fri Aug 15 01:40:14 2025 From: ksakata at openjdk.org (Koichi Sakata) Date: Fri, 15 Aug 2025 01:40:14 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... Thank you for your question. I tried to identify the change that caused the crash by comparing 21.0.4 and 21.0.5, but I wasn't able to pinpoint it with my initial check. I'll take another look and let you know if I find the specific commit or change that triggered the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26770#issuecomment-3190370319 From mhaessig at openjdk.org Fri Aug 15 06:41:15 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 15 Aug 2025 06:41:15 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: References: Message-ID: <4_y_xyPtpT-qA6cHEOkNnMATmZzIDEcSx7omfEIiCZc=.f40168dc-ec95-4eac-8823-a734f8b1ec1a@github.com> On Wed, 13 Aug 2025 19:42:31 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Marked as reviewed by mhaessig (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26121#pullrequestreview-3123083765 From stuefe at openjdk.org Fri Aug 15 06:43:13 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 15 Aug 2025 06:43:13 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v2] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 05:43:01 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - Update metaspace.hpp > - fix rebase error > - fix mac build > - rebase, fixes Ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3190773236 From sjohanss at openjdk.org Fri Aug 15 07:00:12 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 15 Aug 2025 07:00:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: Message-ID: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> On Thu, 14 Aug 2025 13:07:07 GMT, Jonas Norlinder wrote: >>> ... it might happen from time to time without it being a very big deal? >> >> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. > > I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways? > My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278420082 From chagedorn at openjdk.org Fri Aug 15 08:02:14 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 15 Aug 2025 08:02:14 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 14:57:36 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Fix format string Thanks a lot for adding a test and printing the method name! A few more comments but otherwise, it looks good now! src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 44: > 42: CompileTask* task = CompilerThread::current()->task(); > 43: assert(false, "compile task %d (%s) timed out after " INTPTR_FORMAT " ms", > 44: task->compile_id(), task->method()->name_and_sig_as_C_string(), CompileTaskTimeout); Normally, you would probably need a `ResourceMark` for getting the method name. However, I'm not sure if you can do that as well here inside the signal handler. Maybe someone else can comment on that. test/hotspot/jtreg/compiler/arguments/TestCompileTaskTimeout.java line 29: > 27: * @test TestCompileTaskTimeout > 28: * @bug 8308094 > 29: * @requires vm.compiler2.enabled & vm.debug & vm.flagless & os.name == "Linux" Does it only work with C2 compile tasks? test/hotspot/jtreg/compiler/arguments/TestCompileTaskTimeout.java line 40: > 38: > 39: public static void main(String[] args) throws Throwable { > 40: ProcessTools.executeTestJava("-Xcomp", "-XX:CompileTaskTimeout=1", "-version") Nit: I think for newer JDK versions after JDK 8, we should use `--version`. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3123183236 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2278487336 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2278479526 PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2278490157 From ayang at openjdk.org Fri Aug 15 08:08:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 08:08:13 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> Message-ID: On Fri, 15 Aug 2025 06:57:04 GMT, Stefan Johansson wrote: > I don't think it should be a warning on the OS API though. Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it. > ... could be added to CPUTimeThreadClosure::do_thread(...) There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278499043 From sjohanss at openjdk.org Fri Aug 15 08:27:12 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 15 Aug 2025 08:27:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> Message-ID: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> On Fri, 15 Aug 2025 08:05:06 GMT, Albert Mingkun Yang wrote: >>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere. >> >> Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think? > >> I don't think it should be a warning on the OS API though. > > Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it. > >> ... could be added to CPUTimeThreadClosure::do_thread(...) > > There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT? I don't have super strong opinion here, but to be able to add some message in `log_cpu_time` we would need to add logic to the `CPUTimeThreadClosure` to know if something went wrong or am I missing what you are suggesting? And that message would not know what thread we failed to measure, but the closure have that information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278524140 From mhaessig at openjdk.org Fri Aug 15 08:30:12 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 15 Aug 2025 08:30:12 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: Message-ID: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> On Fri, 15 Aug 2025 07:55:55 GMT, Christian Hagedorn wrote: >> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix format string > > src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 44: > >> 42: CompileTask* task = CompilerThread::current()->task(); >> 43: assert(false, "compile task %d (%s) timed out after " INTPTR_FORMAT " ms", >> 44: task->compile_id(), task->method()->name_and_sig_as_C_string(), CompileTaskTimeout); > > Normally, you would probably need a `ResourceMark` for getting the method name. However, I'm not sure if you can do that as well here inside the signal handler. Maybe someone else can comment on that. Does this really matter when we are doing it right before crashing the VM? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2278528285 From vyazici at openjdk.org Fri Aug 15 08:39:20 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 15 Aug 2025 08:39:20 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v16] In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > ... Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions - Document why `Preconditions` is not used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25998/files - new: https://git.openjdk.org/jdk/pull/25998/files/d5aabf0c..2ba4ba6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=14-15 Stats: 19 lines in 5 files changed: 15 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998 PR: https://git.openjdk.org/jdk/pull/25998 From vyazici at openjdk.org Fri Aug 15 08:39:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 15 Aug 2025 08:39:24 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v15] In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Thu, 14 Aug 2025 21:55:48 GMT, John R Rose wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove `@apiNote` in `encodeISOArray()` Javadoc >> >> Those who are touching to these methods should well be >> aware of the details elaborated in the `@apiNote`, no >> need to put it on a display. > > src/hotspot/share/opto/library_call.cpp line 946: > >> 944: Node* count, >> 945: bool char_count, >> 946: bool halt_on_oob) { > > Adding halt_on_oob is a pro move. It makes it very clear that something very bad is afoot. > > Now I see why A/B testing was harder to do in the jtreg tests, especially for the "throwing" case. > > Just a note for the future (no change requested): The InternalError exception is sometimes used for these kinds of "crash and burn" conditiosn. (See the code in java.lang.invoke.) Users can try to catch IE, but they are advised not to, and it will therefore crash the thread (at least), as an unhandled throw. The advantage of using IE is that a jtreg harness can catch it much more easily (as opposed to a hard VM halt). Thanks for the remark. I will share this with @dafedafe and @TobiHartmann. > src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 159: > >> 157: private static int encodeISOArray(char[] sa, int sp, >> 158: byte[] da, int dp, int len) { >> 159: if ((sp | dp | len) < 0 || > > I think this change is OK; I understand it removes uncertainty about inlining of the checking helper method. > > In general, though, I think we should be using the Preconditions methods, instead of hand-rolling checks from random-looking Java operators. (Sorry, but they will look random to the person reading this years later!) > > (I think Objects::rNN is overkill; I do believe that the implicit null checks are easy to reason about. I guess tastes vary here. O::rNN is marked force-inline, so that should not be a problem to throw it into the checking logic, as an explicit null check.) > > Anyway, I would like to a see a comment here, in the code, saying why the Preconditions methods are not used at this point. If there was an inlining problem, let's acknowledge it. It's OK to make String code be a special case (with hand-rolled checks, carefully tuned). Let's document how we did that. > > One point: I don't think we expect these bulk string operations to occur in a containing hot loop, so the intrinsic value of Precondition methods (to contribute to RCE optimizations) is not required. Still, on the whole, it is usually better to use a named method than a tricky Java operator expression ? much as we all love those! > > P.S. For regular code (not the very hottest hand-optimized string methods) I do prefer to put the checking logic in a separate method. This is (again) a matter of taste. The point is to make the method that does the work be as compact as possible, preferably below about 35 bytecodes (which, sadly, is favored by our inlining policy ATM). If the method which does the work is 10% work-doing bytecodes and 90% condition-checking and exception-formatting and exception-throwing code, then the JIT will get a bad view of it, and will not inline as generously. In fact, I often prefer to make the checks method small also, and save all the exception reporting junk for a THIRD method, which is never called, and does not need to be inlined at all. So, for me, the sweet spot is one small method to do the work, another small method to do the checks (perhaps force-inline, if it is medium sized), and a third method to throw the exception, which is as horrible as it needs to be. Very valid point. In 62350347, documented why `Preconditions` is not used. > test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 90: > >> 88: } >> 89: >> 90: private static void violateIntrinsicMethodContract() { > > Ah, here is the positive test for the extra range checking in mode +VerifyIntrinsicChecks. > In the other place where I put a comment, maybe point at this test (in the comment)? Yes, and no. Yes, this test verifies mode `+VerifyIntrinsicChecks` employed by _a_ VM intrinsic that triggers a VM halt on constraint violation ? but only that. No, it doesn't _exhaustively_ verify extra range checks of `StringCoding::encodeAsciiArray` in mode `+VerifyIntrinsicChecks`. Since `SC:eAA` is just used as a vehicle to reach to a VM halt triggered by `halt_on_oob = true`, I prefer to _not_ refer to this test as the positive test for the extra range checking in mode `+VerifyIntrinsicChecks` of `TestEncodeIntrinsics`, which tests `StringCoding::encodeAsciiArray`. > test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java line 56: > >> 54: * @summary Verify `StringCoding::countPositives` intrinsic Java wrapper checks >> 55: * by enabling the ones in the compiler intrinsic using >> 56: * `-XX:+VerifyIntrinsicChecks` > > Is this only a negative test for the optional extra range checks? > > That is to say, do we win if there are no additional throws, when all index inputs are valid (in range)? > > Or is there some corner of these tests (there are three files here) which intentionally instigates out-of-range errors, by passing out-of-range index inputs, and then makes sure that the expected exceptions occur? > > It would be good to put in a brief comment saying, "This test does not trigger out-of-range errors. The +VerifyIntrinsicChecks version of this test simply ensures that the assembly code will produce no spurious errors." > > But it would be nice, someday, to test lots of edge conditions which ARE out-of-range, and make sure (again) that the behavior is the same with and without the +VerifyIntrinsicChecks mode. Your assessment is correct. In 2ba4ba6f, I've added `@comment` blocks as requested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278536177 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278534999 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278535750 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2278535192 From mhaessig at openjdk.org Fri Aug 15 08:41:02 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 15 Aug 2025 08:41:02 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v9] In-Reply-To: References: Message-ID: <9hYCcBeA2l_eP6Jc5wzNYMa1HSHUZJ6xUbU9IeNYvb4=.86647940-df00-4231-b3d5-70c1484bc587@github.com> > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Address Christian's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/ee64b092..40bc28ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=07-08 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Fri Aug 15 08:41:02 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 15 Aug 2025 08:41:02 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 07:50:14 GMT, Christian Hagedorn wrote: >> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix format string > > test/hotspot/jtreg/compiler/arguments/TestCompileTaskTimeout.java line 29: > >> 27: * @test TestCompileTaskTimeout >> 28: * @bug 8308094 >> 29: * @requires vm.compiler2.enabled & vm.debug & vm.flagless & os.name == "Linux" > > Does it only work with C2 compile tasks? Good catch. It is compiler agnostic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2278539477 From ayang at openjdk.org Fri Aug 15 08:45:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 08:45:12 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v5] In-Reply-To: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> References: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com> <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com> Message-ID: On Fri, 15 Aug 2025 08:24:38 GMT, Stefan Johansson wrote: > ... am I missing what you are suggesting? No. I think we are on the same page; I was more focusing on where the msg/warning will be, since this thread started with "Do we really want add a warning here?" > And that message would not know what thread we failed to measure, but the closure have that information. True; need to collect these info so that the printed msg/warning shows which thread(s) encountered a failure, if any. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278547920 From yzheng at openjdk.org Fri Aug 15 08:56:19 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Fri, 15 Aug 2025 08:56:19 GMT Subject: RFR: 8364128: Improve gathering of cpu feature names using stringStream [v5] In-Reply-To: References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com> Message-ID: On Thu, 14 Aug 2025 14:10:37 GMT, Ashutosh Mehra wrote: >> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 148: >> >>> 146: >>> 147: enum Feature_Flag { >>> 148: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = bit, >> >> It would be greatly appreciated if you could give the Graal devs a heads-up when changing CPU feature flags. JVMCI sees different CPU features with this change, and eventually leads to SIGILL by generating instruction not supported by the underlying CPU. > > @mur47x111 sorry for breaking JVMCI with this. I was not aware of such a dependency at all and I touched this code for the first time. For future work, how do I check if my change in hotspot has the potential to break JVMCI? And what is the best forum to inform about such changes? I will add a JVMCI test to assert this. You can inform us via `/label add graal` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2278563087 From mhaessig at openjdk.org Fri Aug 15 09:42:11 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 15 Aug 2025 09:42:11 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v10] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: missed a dash ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/40bc28ac..80ddb0ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From duke at openjdk.org Fri Aug 15 09:48:13 2025 From: duke at openjdk.org (erifan) Date: Fri, 15 Aug 2025 09:48:13 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v7] In-Reply-To: References: Message-ID: <_mLYFBM0CoUb9fZDL1bPJKArnOWmf_XVz-oN9prPjTQ=.4e8a9f02-205a-4f5f-ab60-920f10452585@github.com> On Wed, 13 Aug 2025 03:20:02 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Review comments resolution src/hotspot/share/opto/callGenerator.hpp line 1: > 1: /* 2024 -> 2025 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2278705851 From ayang at openjdk.org Fri Aug 15 10:14:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Aug 2025 10:14:08 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v2] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/0a67ca44..5df3735a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=00-01 Stats: 10715 lines in 306 files changed: 4992 ins; 4431 del; 1292 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From mablakatov at openjdk.org Fri Aug 15 10:50:13 2025 From: mablakatov at openjdk.org (Mikhail Ablakatov) Date: Fri, 15 Aug 2025 10:50:13 GMT Subject: RFR: 8359359: AArch64: share trampolines between static calls to the same method [v4] In-Reply-To: References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com> <7UNfMDlrrnlIXWOt72vfVh2MuucJCgeVo3sPcZ_cG2U=.24099dd8-8142-47ac-8189-d85f41f82b58@github.com> Message-ID: On Tue, 12 Aug 2025 22:25:02 GMT, Evgeny Astigeevich wrote: >> Mikhail Ablakatov has updated the pull request incrementally with three additional commits since the last revision: >> >> - cleanup: update copyright headers >> - Make the value type of the dictionary a struct instead of Pair typedef >> - Remove share_rc_trampoline_for and share_sc_trampoline_for > > src/hotspot/cpu/aarch64/codeBuffer_aarch64.cpp line 66: > >> 64: if (rtype == relocInfo::static_call_type) { >> 65: dest = SharedRuntime::get_resolve_static_call_stub(); >> 66: } > > You are pulling details of implementation, use of `SharedRuntime::get_resolve_static_call_stub` for unlinked static calls. There is no need for this. > It was: create a trampoline to the destination and relocation infos for all places in code which will share it. This is simple. It does not rely on any information about call sites. > > Now it is: we are creating a trampoline for an unlinked static call, it must have `get_resolve_static_call_stub` as a destination. Why should we have this? `Address` will always contain a correct destination set by a compiler. So we do double job, we throw away a target set by a compiler. Hi @eastig , I hope you find this implementation more appropriate, please check https://github.com/openjdk/jdk/pull/25954/commits/d03d8384570b22141f81f06249a44387b89c8303 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2278783009 From adinn at openjdk.org Fri Aug 15 11:02:25 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 11:02:25 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v2] In-Reply-To: References: Message-ID: > Fix two problems with Zero blob/stub entry initialization: > 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. > 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. yhis was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - set zero stubgen blob sizes to zero - restore error traps for zero adapter handle c2i entries - Merge branch 'master' into JDK-8365558 - avoid creating AdpaterBlobs on Zero where we cannto use them - Execute stubgen stub create functions even on Zero when no code expected ------------- Changes: https://git.openjdk.org/jdk/pull/26787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26787&range=01 Stats: 50 lines in 4 files changed: 30 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26787/head:pull/26787 PR: https://git.openjdk.org/jdk/pull/26787 From kvn at openjdk.org Fri Aug 15 11:02:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 15 Aug 2025 11:02:26 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v2] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 11:00:01 GMT, Andrew Dinn wrote: >> Fix two problems with Zero blob/stub entry initialization: >> 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. >> 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. yhis was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. > > Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - set zero stubgen blob sizes to zero > - restore error traps for zero adapter handle c2i entries > - Merge branch 'master' into JDK-8365558 > - avoid creating AdpaterBlobs on Zero where we cannto use them > - Execute stubgen stub create functions even on Zero when no code expected src/hotspot/share/runtime/sharedRuntime.cpp line 2806: > 2804: // on Zero the blob may be null > 2805: handler->print_adapter_on(tty); > 2806: if (adapter_blob == nullptr) { Should we move `handler->print_adapter_on(tty);` too after check? src/hotspot/share/runtime/stubRoutines.cpp line 198: > 196: ls.print_cr("%s\t not generated", buffer_name); > 197: return nullptr; > 198: } Wrong placement of `return nullptr;` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2277537337 PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2277539209 From adinn at openjdk.org Fri Aug 15 11:02:26 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 11:02:26 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v2] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 19:26:32 GMT, Vladimir Kozlov wrote: >> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - set zero stubgen blob sizes to zero >> - restore error traps for zero adapter handle c2i entries >> - Merge branch 'master' into JDK-8365558 >> - avoid creating AdpaterBlobs on Zero where we cannto use them >> - Execute stubgen stub create functions even on Zero when no code expected > > src/hotspot/share/runtime/sharedRuntime.cpp line 2806: > >> 2804: // on Zero the blob may be null >> 2805: handler->print_adapter_on(tty); >> 2806: if (adapter_blob == nullptr) { > > Should we move `handler->print_adapter_on(tty);` too after check? We still have a handler entry even if we don't have a blob. So I left this in to display the handler entry addresses i.e. C functions not blob entries. > src/hotspot/share/runtime/stubRoutines.cpp line 198: > >> 196: ls.print_cr("%s\t not generated", buffer_name); >> 197: return nullptr; >> 198: } > > Wrong placement of `return nullptr;` This is for the case where the blob size is declared as zero in stubDeclarations.hpp. That means we don't need a blob. So, in that case I think we need to do assert that no code was generated, skip the blob creation and return nullptr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2278791917 PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2278794805 From stefank at openjdk.org Fri Aug 15 11:07:24 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 15 Aug 2025 11:07:24 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v27] In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 09:48:28 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Fixed whitespace error I looked over the patch and listed a few more small requests. Other than that I think this PR looks fine from my POV. There are a few follow-up cleanup and fixes we should do, but I don't think those need to be handled in this PR. What do other Reviewers think? Is this getting ready to be integrated soon? src/hotspot/os/windows/os_windows.cpp line 870: > 868: } else { > 869: DWORD errcode = ::GetLastError(); > 870: log_debug(os)("available_memory() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); I think this should be an assert. Or is there a reason why that would be bad? src/hotspot/os/windows/os_windows.cpp line 884: > 882: } else { > 883: DWORD errcode = ::GetLastError(); > 884: log_debug(os)("total_swap_space() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); assert? src/hotspot/os/windows/os_windows.cpp line 898: > 896: } else { > 897: DWORD errcode = ::GetLastError(); > 898: log_debug(os)("free_swap_space() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); assert? src/hotspot/os/windows/os_windows.cpp line 4168: > 4166: // also returns dwAvailPhys (free physical memory bytes), dwTotalVirtual, dwAvailVirtual, > 4167: // dwMemoryLoad (% of memory in use) > 4168: BOOL res = GlobalMemoryStatusEx(&ms); Unused local variable? Should there be an assert here? src/hotspot/share/gc/z/zLargePages.cpp line 34: > 32: pd_initialize(); > 33: > 34: size_t memory = os::physical_memory(); ZGC coding style for locals: Suggestion: const size_t memory = os::physical_memory(); src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 417: > 415: return os::Linux::physical_memory(); > 416: #else > 417: return static_cast(os::physical_memory()); The two paths are inconsistent. This casts the return but the lines above doesn't cast the return value of `os::Linux::physical_memory();`. src/hotspot/share/utilities/globalDefinitions.hpp line 1366: > 1364: > 1365: // Dummy placeholder for use of [[nodiscard]] > 1366: #define ATTRIBUTE_NODISCARD Should this be placed near the other listed ATTRIBUTES in this file? ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3123593306 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278787309 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278787627 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278787491 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278788547 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278791660 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278794078 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2278799119 From stefank at openjdk.org Fri Aug 15 11:28:13 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 15 Aug 2025 11:28:13 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: <8JM-3SzrHRHRxpJ6Q6p36Xcf3_hAhdwQ9lGbLt6mJfU=.f4491bfb-96cc-4249-8572-3e09455e91b5@github.com> On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. I think it is time to proceed with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3191297228 From lkorinth at openjdk.org Fri Aug 15 11:43:33 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 15 Aug 2025 11:43:33 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From duke at openjdk.org Fri Aug 15 11:46:12 2025 From: duke at openjdk.org (Ruben) Date: Fri, 15 Aug 2025 11:46:12 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments @TheRealMDoerr, @RealFYang, @offamitkumar, Could you run tier1-tier3 tests on your platforms for this patch please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3191323914 From kbarrett at openjdk.org Fri Aug 15 11:56:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 15 Aug 2025 11:56:12 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: <8JM-3SzrHRHRxpJ6Q6p36Xcf3_hAhdwQ9lGbLt6mJfU=.f4491bfb-96cc-4249-8572-3e09455e91b5@github.com> References: <8JM-3SzrHRHRxpJ6Q6p36Xcf3_hAhdwQ9lGbLt6mJfU=.f4491bfb-96cc-4249-8572-3e09455e91b5@github.com> Message-ID: On Fri, 15 Aug 2025 11:25:11 GMT, Stefan Karlsson wrote: > I think it is time to proceed with this change. Agreed. I've been working on the associated style guide updates. I'm going to leave this open for now in case anyone wants to make any late comments here, and will withdraw this PR and replace with the real change soonish, I hope. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3191338437 From lkorinth at openjdk.org Fri Aug 15 11:59:12 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 15 Aug 2025 11:59:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD Added three new `/timeout=480` after the last run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090 From asemenov at openjdk.org Fri Aug 15 12:04:56 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 15 Aug 2025 12:04:56 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() Message-ID: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. ------------- Commit messages: - The same issue is present in src/hotspot/share/runtime/continuationFreezeThaw.cpp FreezeBase::finalize_freeze() - The same issue is present in src/hotspot/share/jvmci/jvmciEnv.cpp JVMCICompileState::JVMCICompileState() - The same issue is present in src/hotspot/share/c1/c1_LinearScan.cpp Interval::split() - The same issue is present in src/hotspot/share/nmt/mallocSiteTable.cpp MallocSiteTable::malloc_site() - The same issue is present in src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp JfrThreadSampler::set_period() - The same issue is present in src/hotspot/share/opto/vectorIntrinsics.cpp LibraryCallKit::inline_vector_gather_scatter() - 8365604 Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() Changes: https://git.openjdk.org/jdk/pull/26798/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26798&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365604 Stats: 12 lines in 7 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26798.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26798/head:pull/26798 PR: https://git.openjdk.org/jdk/pull/26798 From stuefe at openjdk.org Fri Aug 15 12:26:11 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 15 Aug 2025 12:26:11 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. Would this give us size_t literal suffixes? Something like "0uz"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3191384236 From duke at openjdk.org Fri Aug 15 13:38:16 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 15 Aug 2025 13:38:16 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: <_mDI_WpB9sqgKfdByZVen_cmEklkavJHh8hEQ_6OwZE=.7593f277-3d0f-42bb-bf08-a1456adaf53e@github.com> On Thu, 14 Aug 2025 09:27:24 GMT, Magnus Ihse Bursie wrote: > If I recall correctly the original approach was even simpler: I counted the number of #includes in the C++ source files, not in the dependency files of a particular build. Crude but effective, and left out discussions about differences between platforms and feature configurations. And then I had to do some adjustments for Windows where my approach of excluding inline files did not hold and caused a regression. That was also the initial approach in this PR, I got the suggestion from the first comments I got here. > But then again, this is basically an optimization problem (even if it is not about running code in the JVM, but about optimizing build speed) so there is no way around the mantra of measure, measure and measure again. Yeah I see, I'll give it another shot next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3191518492 From kbarrett at openjdk.org Fri Aug 15 13:51:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 15 Aug 2025 13:51:11 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 12:22:46 GMT, Thomas Stuefe wrote: > Would this give us size_t literal suffixes? Something like "0uz"? That's C++23. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3191545560 From jsjolen at openjdk.org Fri Aug 15 14:01:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 15 Aug 2025 14:01:11 GMT Subject: RFR: 8365245: Move size reducing operations to GrowableArrayWithAllocator In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 13:06:01 GMT, Kim Barrett wrote: > Please review this change to GrowableArray to move size reducing operations > from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. > See JBS for rationale for this move. > > This is mostly just a simple code motion change, with the moved functions > being updated to account for different name lookup rules now that they are in > a class with a class template base class. For the most part this refactoring > didn't require any client code changes. All but one use of one moved function > was with a GrowableArrayWithAllocator-derived class, so not affected by moving > the functions. The one exception was a test of ZArraySlice that was modified > to no longer use GA::pop(). > > Testing: mach5 tier1. As I've understood, the need for moving len-reducing operations to the GAWA class comes from the (future) need to be able to destruct elements when they go out of range. In other words, when an element is popped in the future it should be destructed and freed by the allocator. This PR is a stepping stone to that kind of change. Considering that, I think that it's correct to move these methods to GAWA and so I'm approving this PR. Thanks! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26726#pullrequestreview-3123924640 From syan at openjdk.org Fri Aug 15 14:08:12 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 15 Aug 2025 14:08:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD make/RunTests.gmk line 940: > 938: JTREG_AUTO_PROBLEM_LISTS := > 939: # Please reach consensus before changing this. It was not easy changing it to a `1`. > 940: JTREG_AUTO_TIMEOUT_FACTOR := 1 Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261 From shade at openjdk.org Fri Aug 15 14:38:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Aug 2025 14:38:00 GMT Subject: RFR: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier Message-ID: I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. Additional testing: - [x] Shenandoah + CDS reproducer crashes reliably - [x] Linux AArch64 server fastdebug, `all` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/26797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365594 Stats: 14 lines in 2 files changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26797/head:pull/26797 PR: https://git.openjdk.org/jdk/pull/26797 From stefank at openjdk.org Fri Aug 15 14:49:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 15 Aug 2025 14:49:11 GMT Subject: RFR: 8365245: Move size reducing operations to GrowableArrayWithAllocator In-Reply-To: References: Message-ID: On Mon, 11 Aug 2025 13:06:01 GMT, Kim Barrett wrote: > Please review this change to GrowableArray to move size reducing operations > from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. > See JBS for rationale for this move. > > This is mostly just a simple code motion change, with the moved functions > being updated to account for different name lookup rules now that they are in > a class with a class template base class. For the most part this refactoring > didn't require any client code changes. All but one use of one moved function > was with a GrowableArrayWithAllocator-derived class, so not affected by moving > the functions. The one exception was a test of ZArraySlice that was modified > to no longer use GA::pop(). > > Testing: mach5 tier1. Looks good to me. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26726#pullrequestreview-3124036828 From kvn at openjdk.org Fri Aug 15 15:02:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 15 Aug 2025 15:02:14 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v2] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 10:55:21 GMT, Andrew Dinn wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 2806: >> >>> 2804: // on Zero the blob may be null >>> 2805: handler->print_adapter_on(tty); >>> 2806: if (adapter_blob == nullptr) { >> >> Should we move `handler->print_adapter_on(tty);` too after check? > > We still have a handler entry even if we don't have a blob. So I left this in to display the handler entry addresses i.e. C functions not blob entries. Okay. I see that it prints handlers's addresses and fingerprint. >> src/hotspot/share/runtime/stubRoutines.cpp line 198: >> >>> 196: ls.print_cr("%s\t not generated", buffer_name); >>> 197: return nullptr; >>> 198: } >> >> Wrong placement of `return nullptr;` > > This is for the case where the blob size is declared as zero in stubDeclarations.hpp. That means we don't need a blob. So, in that case I think we need to do assert that no code was generated, skip the blob creation and return nullptr. I mean, currently `return` is under `if (lt.is_enabled())` condition. It should be outside it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2279146670 PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2279149076 From adinn at openjdk.org Fri Aug 15 15:21:26 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 15:21:26 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: > Fix two problems with Zero blob/stub entry initialization: > 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. > 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. this was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: relocate return to correct scope ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26787/files - new: https://git.openjdk.org/jdk/pull/26787/files/9a0f0cf0..f33f292d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26787&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26787&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26787/head:pull/26787 PR: https://git.openjdk.org/jdk/pull/26787 From adinn at openjdk.org Fri Aug 15 15:21:26 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 15:21:26 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 14:59:11 GMT, Vladimir Kozlov wrote: >> This is for the case where the blob size is declared as zero in stubDeclarations.hpp. That means we don't need a blob. So, in that case I think we need to do assert that no code was generated, skip the blob creation and return nullptr. > > I mean, currently `return` is under `if (lt.is_enabled())` condition. It should be outside it. Ah, yes! Thanks for the correction. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26787#discussion_r2279202393 From asmehra at openjdk.org Fri Aug 15 15:53:20 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 15 Aug 2025 15:53:20 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 15:21:26 GMT, Andrew Dinn wrote: >> Fix two problems with Zero blob/stub entry initialization: >> 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. >> 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. this was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > relocate return to correct scope lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/26787#pullrequestreview-3124348334 From never at openjdk.org Fri Aug 15 16:52:16 2025 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 15 Aug 2025 16:52:16 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 19:42:31 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Marked as reviewed by never (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26121#pullrequestreview-3124530874 From aph at openjdk.org Fri Aug 15 16:53:20 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 15 Aug 2025 16:53:20 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 20:07:34 GMT, Dean Long wrote: > Probably not needed. set_destination() should take care of this. I guess so, given that we just updated the stub before changing the call to point to the stub. But `set_destination_mt_safe` is a public method, shouldn't it do the right thing here? Maybe I could just assert we're in `WXWrite` mode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2279479135 From aph at openjdk.org Fri Aug 15 17:13:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 15 Aug 2025 17:13:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 20:16:11 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> > > src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 377: > >> 375: MacroAssembler a(&cbuf); >> 376: >> 377: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); > > Harmless, but already handled by set_destination(). I'm not sure about emit_trampoline_stub(). I'm not sure about emit_trampoline_stub() either, but I'll leave that one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2279518950 From kvn at openjdk.org Fri Aug 15 18:08:12 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 15 Aug 2025 18:08:12 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: <-x0bN5qS2Mk8_9lsjTBjcV9OYfsSynUhAO2tSj6p_vc=.1669ac5b-2d49-445f-b6ad-a9e892652d7d@github.com> On Fri, 15 Aug 2025 15:21:26 GMT, Andrew Dinn wrote: >> Fix two problems with Zero blob/stub entry initialization: >> 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. >> 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. this was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > relocate return to correct scope Looks good now @adinn let me test it before you push it. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26787#pullrequestreview-3124727502 PR Comment: https://git.openjdk.org/jdk/pull/26787#issuecomment-3192332997 From coleenp at openjdk.org Fri Aug 15 18:20:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Aug 2025 18:20:11 GMT Subject: RFR: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 10:43:55 GMT, Aleksey Shipilev wrote: > I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. > > We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. > > Additional testing: > - [x] Shenandoah + CDS reproducer crashes reliably > - [x] Linux AArch64 server fastdebug, `all` Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26797#pullrequestreview-3124761877 From dlong at openjdk.org Fri Aug 15 18:51:12 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 18:51:12 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: <4_y_xyPtpT-qA6cHEOkNnMATmZzIDEcSx7omfEIiCZc=.f40168dc-ec95-4eac-8823-a734f8b1ec1a@github.com> References: <4_y_xyPtpT-qA6cHEOkNnMATmZzIDEcSx7omfEIiCZc=.f40168dc-ec95-4eac-8823-a734f8b1ec1a@github.com> Message-ID: On Fri, 15 Aug 2025 06:38:58 GMT, Manuel H?ssig wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup > > Marked as reviewed by mhaessig (Committer). Thanks @mhaessig and @tkrodriguez for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3192430004 From dlong at openjdk.org Fri Aug 15 18:51:13 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 18:51:13 GMT Subject: RFR: 8278874: tighten VerifyStack constraints [v12] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 19:42:31 GMT, Dean Long wrote: >> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup tier10 Graal results look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3192430262 From dlong at openjdk.org Fri Aug 15 18:56:18 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 18:56:18 GMT Subject: Integrated: 8278874: tighten VerifyStack constraints In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 20:28:34 GMT, Dean Long wrote: > The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes. To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode. The old code didn't know how to determine exactly what state we were in, so it checked both. This PR cleans that up, so we only have to compute the oopmap once. It also removes old SPARC support. This pull request has now been integrated. Changeset: 39a36529 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/39a365296882b0df49398cd7ac36e801a9aa1c35 Stats: 244 lines in 4 files changed: 113 ins; 68 del; 63 mod 8278874: tighten VerifyStack constraints Co-authored-by: Tom Rodriguez Reviewed-by: mhaessig, never ------------- PR: https://git.openjdk.org/jdk/pull/26121 From dlong at openjdk.org Fri Aug 15 19:44:18 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 19:44:18 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Fri, 15 Aug 2025 16:50:26 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 80: >> >>> 78: // Used in the runtime linkage of calls; see class CompiledIC. >>> 79: void NativeCall::set_destination_mt_safe(address dest) { >>> 80: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); >> >> Probably not needed. set_destination() should take care of this. > >> Probably not needed. set_destination() should take care of this. > > I guess so, given that we just updated the stub before changing the call to point to the stub. But `set_destination_mt_safe` is a public method, shouldn't it do the right thing here? > Maybe I could just assert we're in `WXWrite` mode? In other places we call set_destination() directly, so it acts like a public entry point, and then this function looks a little like a wrapper. But having an extra call here is harmless and helps to document what we are doing, so leaving it fine too. If having redundant calls to thread_wx_enable_write() was expensive then it might be worth it to optimize their placement, but I think thread_wx_enable_write() is cheap enough that trying to over-optimize can quickly turn into bikeshedding. An assert would be OK, but then it brings up the question of whether we should use it in other places. And the signal handler safety net makes asserts less useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2279757324 From kvn at openjdk.org Fri Aug 15 21:35:10 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 15 Aug 2025 21:35:10 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 15:21:26 GMT, Andrew Dinn wrote: >> Fix two problems with Zero blob/stub entry initialization: >> 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. >> 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. this was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > relocate return to correct scope My testing passed. Good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26787#issuecomment-3192813956 From adinn at openjdk.org Fri Aug 15 22:13:11 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 22:13:11 GMT Subject: RFR: 8365558: Fix stub entry init and blob creation on Zero [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 21:32:07 GMT, Vladimir Kozlov wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> relocate return to correct scope > > My testing passed. Good. @vnkozlov @ashu-mehra Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26787#issuecomment-3192875708 From adinn at openjdk.org Fri Aug 15 22:16:17 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 15 Aug 2025 22:16:17 GMT Subject: Integrated: 8365558: Fix stub entry init and blob creation on Zero In-Reply-To: References: Message-ID: <5Z9Ss9Rw6AczqonNcDpt68HbXWrA3BDkPK30ZD9zI-o=.e44fd003-4239-45cd-9692-af3439f2caac@github.com> On Thu, 14 Aug 2025 19:07:32 GMT, Andrew Dinn wrote: > Fix two problems with Zero blob/stub entry initialization: > 1. Stop Zero allocating AdapterBlobs for the default set of i2c2i adapters even though it cannot ever use them. > 2. Allow Zero to execute its stubgen init functions even though it is not generating code into a code buffer (i.e when blob size is declared as zero). This still allows it initialize entries to point to C functions. n.b. this was broken when [JDK-8359373](https://bugs.openjdk.org/browse/JDK-8359373) introduced the preuniverse Stubgen stub group. This pull request has now been integrated. Changeset: b023fea0 Author: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/b023fea06216d5196592ff5239dc592aa8e34a02 Stats: 50 lines in 4 files changed: 30 ins; 8 del; 12 mod 8365558: Fix stub entry init and blob creation on Zero Reviewed-by: asmehra, kvn ------------- PR: https://git.openjdk.org/jdk/pull/26787 From dlong at openjdk.org Fri Aug 15 23:58:31 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 15 Aug 2025 23:58:31 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <5m-kowi6UhJtFdlKycGvc9vQ4SyjvsIToSROYPAO2vI=.c620c11b-ac93-41f4-be1c-3771aa39600d@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <5m-kowi6UhJtFdlKycGvc9vQ4SyjvsIToSROYPAO2vI=.c620c11b-ac93-41f4-be1c-3771aa39600d@github.com> Message-ID: <98JSRMRpGhaqZE8uWkPcfpmV7XDrfeKgtl3kiuMXvH4=.1b240fc3-dcc5-4938-b9ad-4dc08cac4fd5@github.com> On Tue, 12 Aug 2025 09:22:57 GMT, Andrew Dinn wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Bernhard Urban-Forster > > src/hotspot/share/code/nmethod.cpp line 2394: > >> 2392: >> 2393: bool nmethod::is_unloading() { >> 2394: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); > > This is very opaque. Why is the write enable placed here rather than lower down where we drop past the return true and return false cases and potentially start monkeying around with state updates? > > Currently, it looks as if the fact that a caller has tested the state may imply that said caller might write to the nmethod even when we determine the state via the first two checks. Is that really true? If so then an explanation as to why would be highly appropriate. Yes, we should be able to move it down to right before the cmpxchg. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2280039748 From dlong at openjdk.org Sat Aug 16 00:02:14 2025 From: dlong at openjdk.org (Dean Long) Date: Sat, 16 Aug 2025 00:02:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 184: > 182: // Enable WXWrite: the function is called directly from nmethod_entry_barrier > 183: // stub. > 184: MACOS_AARCH64_ONLY(ThreadWXEnable wx(DefaultWXWriteMode, Thread::current())); In 8361376 I have moved this down into BarrierSetNMethod::nmethod_entry_barrier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2280041660 From dlong at openjdk.org Sat Aug 16 00:10:12 2025 From: dlong at openjdk.org (Dean Long) Date: Sat, 16 Aug 2025 00:10:12 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 09:50:47 GMT, Andrew Dinn wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Bernhard Urban-Forster > > src/hotspot/share/runtime/threads.cpp line 599: > >> 597: } >> 598: >> 599: MACOS_AARCH64_ONLY(os::current_thread_enable_wx(WXWrite)); > > I think for clarity this call should really precede the call to init_globals() a few lines up. > > That function calls, amongst other things, codeCache_init() then VM_Version_init() and the latter may need to write into the code cache for some architectures. There is already a call at line 465, so this one is redundant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2280046606 From fyang at openjdk.org Sat Aug 16 01:36:20 2025 From: fyang at openjdk.org (Fei Yang) Date: Sat, 16 Aug 2025 01:36:20 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments @ruben-arm : Thanks for the ping. Changes LGTM. Tier1-3 test good on linux-riscv64. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3125493777 From stuefe at openjdk.org Sat Aug 16 04:21:09 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 16 Aug 2025 04:21:09 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR Message-ID: This provides the following new metrics: - `ProcessSize` event (new, periodic) - vsize (for analyzing address-space fragmentation issues) - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat) - peak RSS - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing) - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size) - `LibcStatistics` (new, periodic) - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading) - retained malloc size (super-important for the same reason) - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`) - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims) - RSS before and RSS after - RSS recovered by this trim - whether it was an automatic or manual trim - duration - `JavaThreadStatistic` - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.) - nonJava thread counter (new field) (needed to interprete the os thread counter) Notes: - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it. - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue. I provided implementations, as far as possible, to Linux, MacOS and Windows. Testing: - ran the new tests manually and as part of GHAs ------------- Commit messages: - copyrights - Windows - MacOS tests - fix mac - wip - mac implementation - typo - Add nonjava thread count; add test for thread statistics - tests - Add test to workflow - ... and 11 more: https://git.openjdk.org/jdk/compare/dbae90c9...39e282ae Changes: https://git.openjdk.org/jdk/pull/26756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365306 Stats: 778 lines in 28 files changed: 643 ins; 27 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/26756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26756/head:pull/26756 PR: https://git.openjdk.org/jdk/pull/26756 From stuefe at openjdk.org Sat Aug 16 05:06:27 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 16 Aug 2025 05:06:27 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v3] In-Reply-To: References: Message-ID: > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe 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 branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - merge master - copyrights - fix big-endian problem on AIX - Update klass.cpp - Update metaspace.hpp - Update metaspace.hpp - Update metaspace.hpp - fix rebase error - fix mac build - ... and 1 more: https://git.openjdk.org/jdk/compare/57210af9...d9696c76 ------------- Changes: https://git.openjdk.org/jdk/pull/25891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=02 Stats: 485 lines in 26 files changed: 401 ins; 27 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From stuefe at openjdk.org Sat Aug 16 05:06:28 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 16 Aug 2025 05:06:28 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v2] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 05:43:01 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - Update metaspace.hpp > - fix rebase error > - fix mac build > - rebase, fixes @shipilev would you care to review this? You originally did ask for this feature. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3193391561 From stuefe at openjdk.org Sat Aug 16 07:00:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 16 Aug 2025 07:00:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 08:22:55 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: > 247: // If we got a SIGBUS because we tried to write into the code > 248: // cache, try enabling WXWrite mode. > 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { Only the hotspot code should write into the code cache, right? A more secure alternative would be then to use `os::address_is_in_vm()`. That compares against the text segment of the libjvm. Prevents accidental misdiagnosis of writes from anywhere (including possibly deliberate ones). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2280270826 From jsjolen at openjdk.org Sat Aug 16 08:57:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 16 Aug 2025 08:57:14 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v3] In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 05:06:27 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe 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 branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - Update metaspace.hpp > - fix rebase error > - fix mac build > - ... and 1 more: https://git.openjdk.org/jdk/compare/57210af9...d9696c76 Hi Thomas, A lot of us have been out on vacation and are revving up again. At least I have got this in my sights. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3193509511 From aph at openjdk.org Sat Aug 16 09:10:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 09:10:17 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 412: > 410: [p0144r0](http://wg21.link/p0144r0) > 411: [p0217r3](http://wg21.link/p0217r3) > 412: It might well be worth allowing limited used of Structured Bindings. The ability to return a status from an incomplete function is something we've lacked: std::tuple incomplete_function(double x) { if (x >= 0) return std::tuple(sqrt(x), true); return std::tuple(x, false); } const auto[root, failure] = incomplete_function(d); if (failure) {... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280326634 From aph at openjdk.org Sat Aug 16 09:20:11 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 09:20:11 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 440: > 438: use of the library function `std::as_const`. But explicit capture parameters > 439: are recommended against in HotSpot. `FORBIDDEN_ROI`. > 440: How did we get from "recommended against" to `FORBIDDEN_ROI`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280329522 From aph at openjdk.org Sat Aug 16 09:37:12 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 09:37:12 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 546: > 544: mechanisms for its needs. Rewriting in terms of this new library doesn't seem > 545: like a good use of resources. Having a mix of the existing usage and uses of > 546: this new library would just be confusing. Strong agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280334784 From aph at openjdk.org Sat Aug 16 09:47:11 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 09:47:11 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 740: > 738: ##### 35.1.2. Keyword `register` > 739: > 740: We don't use the `register` keyword in the OpenJDK anymore? It's essential in some uses of GCC extended asm. See `atomic_linux_aarch64.hpp` for a good example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280337095 From kbarrett at openjdk.org Sat Aug 16 11:37:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 16 Aug 2025 11:37:12 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 09:07:17 GMT, Andrew Haley wrote: >> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can >> be more easily structured and captured than bare email. Once discussion >> settles down I'll turn the results into HotSpot Style Guide changes. I don't >> intend to integrate any version of this document to the OpenJDK repository. > > doc/cpp17-features.md line 412: > >> 410: [p0144r0](http://wg21.link/p0144r0) >> 411: [p0217r3](http://wg21.link/p0217r3) >> 412: > > It might well be worth allowing limited used of Structured Bindings. The ability to return a status from an incomplete function is something we've lacked: > > > std::tuple incomplete_function(double x) { > if (x >= 0) > return std::tuple(sqrt(x), true); > return std::tuple(x, false); > } > > const auto[root, failure] = incomplete_function(d); > if (failure) {... I've had variations of this conversation a number of times with various HotSpot folks. The upshot has always been that the preferred approach is that a function returning multiple values should return a named class/class intended for that purpose, with named and typed members/accessors. (Or probably even more often, a value and out parameters. Though I personally am not a big fan of those, esp. out reference parameters.) Names and types are more meaningful than offsets and implicit types. There are folks who strongly dislike that some of the standard library functions return `std::pair` because `first` and `second` members don't carry any useful information. For the specific case of "value | error-value" I'd personally prefer we pursued something in the direction of boost.leaf, boost.outcome, or std::expected. (I think all of these can be significantly trimmed down if one only wants to support a fixed restricted type of error-value, like an error code. I think that's even the recommended style for boost.outcome?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280388864 From kbarrett at openjdk.org Sat Aug 16 11:48:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 16 Aug 2025 11:48:13 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: <6Z-OcCjKxCPgU5xWCt8dYyD3tZ8E4ZsbTSUrrIvGLd4=.bea5d62e-4e1c-49d9-a143-d319e635a3ad@github.com> On Sat, 16 Aug 2025 09:17:28 GMT, Andrew Haley wrote: >> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can >> be more easily structured and captured than bare email. Once discussion >> settles down I'll turn the results into HotSpot Style Guide changes. I don't >> intend to integrate any version of this document to the OpenJDK repository. > > doc/cpp17-features.md line 440: > >> 438: use of the library function `std::as_const`. But explicit capture parameters >> 439: are recommended against in HotSpot. `FORBIDDEN_ROI`. >> 440: > > How did we get from "recommended against" to `FORBIDDEN_ROI`? I used the wrong feature here. Explicit capture parameters are (I think fairly strongly) recommended against. But capture initializers are explicitly forbidden, and using `std::as_const` in this way involves the latter. This functionality might be worth having for other reasons. However, the implementation of `std::as_const` looks sufficiently simple that adding an equivalent to (say) globalDefinitions.hpp might be appropriate, rather than dragging in all of `` (with all that would entail) for that one little function. (We already do that for `declval`, for example.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280391522 From kbarrett at openjdk.org Sat Aug 16 11:58:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 16 Aug 2025 11:58:10 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 09:44:22 GMT, Andrew Haley wrote: >> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can >> be more easily structured and captured than bare email. Once discussion >> settles down I'll turn the results into HotSpot Style Guide changes. I don't >> intend to integrate any version of this document to the OpenJDK repository. > > doc/cpp17-features.md line 740: > >> 738: ##### 35.1.2. Keyword `register` >> 739: >> 740: We don't use the `register` keyword in the OpenJDK anymore? > > It's essential in some uses of GCC extended asm. See `atomic_linux_aarch64.hpp` for a good example. `register` is not used as a storage class specifier in the JDK. That use for gcc extended asm is a gcc extension, with a different meaning and syntax. (It has some similarities in appearance, but is really pretty different.) C++17 still retains `register` as a reserved word, so one still can't start using it for other purposes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280393882 From kbarrett at openjdk.org Sat Aug 16 12:06:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 16 Aug 2025 12:06:13 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 11:34:27 GMT, Kim Barrett wrote: >> doc/cpp17-features.md line 412: >> >>> 410: [p0144r0](http://wg21.link/p0144r0) >>> 411: [p0217r3](http://wg21.link/p0217r3) >>> 412: >> >> It might well be worth allowing limited used of Structured Bindings. The ability to return a status from an incomplete function is something we've lacked: >> >> >> std::tuple incomplete_function(double x) { >> if (x >= 0) >> return std::tuple(sqrt(x), true); >> return std::tuple(x, false); >> } >> >> const auto[root, failure] = incomplete_function(d); >> if (failure) {... > > I've had variations of this conversation a number of times with various > HotSpot folks. The upshot has always been that the preferred approach is that > a function returning multiple values should return a named class/class > intended for that purpose, with named and typed members/accessors. (Or > probably even more often, a value and out parameters. Though I personally am > not a big fan of those, esp. out reference parameters.) Names and types are > more meaningful than offsets and implicit types. There are folks who strongly > dislike that some of the standard library functions return `std::pair` because > `first` and `second` members don't carry any useful information. > > For the specific case of "value | error-value" I'd personally prefer we > pursued something in the direction of boost.leaf, boost.outcome, or > std::expected. (I think all of these can be significantly trimmed down if one > only wants to support a fixed restricted type of error-value, like an error > code. I think that's even the recommended style for boost.outcome?) You are, of course, free to argue the contrary, and that we should allow the use of structured bindings (or any other categorization in this list or elsewhere in the style guide). If you find there is sufficient support, we can change things. (I personally don't have a strong opinion either way about structured bindings. I put it in the forbidden column because I know there are some folks who would be strongly opposed. I've not had anyone express to me a strongly favorable opinion, but that doesn't mean they aren't out there.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280395866 From ysuenaga at openjdk.org Sat Aug 16 14:19:16 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 16 Aug 2025 14:19:16 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU Message-ID: `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss CPU Model and flags from /proc/cpuinfo: model name : Intel(R) Core(TM) Ultra 5 225U flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. ------------- Commit messages: - 8365633: Incorrect info is reported on hybrid CPU Changes: https://git.openjdk.org/jdk/pull/26808/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365633 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26808/head:pull/26808 PR: https://git.openjdk.org/jdk/pull/26808 From aph at openjdk.org Sat Aug 16 15:26:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 15:26:17 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 12:03:50 GMT, Kim Barrett wrote: >> I've had variations of this conversation a number of times with various >> HotSpot folks. The upshot has always been that the preferred approach is that >> a function returning multiple values should return a named class/class >> intended for that purpose, with named and typed members/accessors. (Or >> probably even more often, a value and out parameters. Though I personally am >> not a big fan of those, esp. out reference parameters.) Names and types are >> more meaningful than offsets and implicit types. There are folks who strongly >> dislike that some of the standard library functions return `std::pair` because >> `first` and `second` members don't carry any useful information. >> >> For the specific case of "value | error-value" I'd personally prefer we >> pursued something in the direction of boost.leaf, boost.outcome, or >> std::expected. (I think all of these can be significantly trimmed down if one >> only wants to support a fixed restricted type of error-value, like an error >> code. I think that's even the recommended style for boost.outcome?) > > You are, of course, free to argue the contrary, and that we should allow the > use of structured bindings (or any other categorization in this list or > elsewhere in the style guide). If you find there is sufficient support, we can > change things. (I personally don't have a strong opinion either way about > structured bindings. I put it in the forbidden column because I know there are > some folks who would be strongly opposed. I've not had anyone express to me a > strongly favorable opinion, but that doesn't mean they aren't out there.) > I've had variations of this conversation a number of times with various HotSpot folks. The upshot has always been that the preferred approach is that a function returning multiple values should return a named class/class intended for that purpose, with named and typed members/accessors. (Or probably even more often, a value and out parameters. Mmm, agree, but that's a lot of ceremony for such a simple thing; and to avoid that ceremony people may designate a sentinel value as meaning "fail". > Though I personally am not a big fan of those, esp. out reference parameters.) Names and types are more meaningful than offsets and implicit types. There are folks who strongly dislike that some of the standard library functions return `std::pair` because `first` and `second` members don't carry any useful information. Fair. > For the specific case of "value | error-value" I'd personally prefer we pursued something in the direction of boost.leaf, boost.outcome, or std::expected. (I think all of these can be significantly trimmed down if one only wants to support a fixed restricted type of error-value, like an error code. I think that's even the recommended style for boost.outcome?) Sure. Boost.leaf looks nice, but I tend to prefer a language's standard way of doing things. But if there's a lightweight generally-applicable idiom we can use, I'm happy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280468513 From aph at openjdk.org Sat Aug 16 15:26:18 2025 From: aph at openjdk.org (Andrew Haley) Date: Sat, 16 Aug 2025 15:26:18 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 11:55:24 GMT, Kim Barrett wrote: >> doc/cpp17-features.md line 740: >> >>> 738: ##### 35.1.2. Keyword `register` >>> 739: >>> 740: We don't use the `register` keyword in the OpenJDK anymore? >> >> It's essential in some uses of GCC extended asm. See `atomic_linux_aarch64.hpp` for a good example. > > `register` is not used as a storage class specifier in the JDK. That use for > gcc extended asm is a gcc extension, with a different meaning and syntax. (It > has some similarities in appearance, but is really pretty different.) C++17 > still retains `register` as a reserved word, so one still can't start using it > for other purposes. OK, as long as it's clear that `register asm` is allowed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280468716 From kbarrett at openjdk.org Sat Aug 16 23:47:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 16 Aug 2025 23:47:10 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 13:48:20 GMT, Kim Barrett wrote: > > Would this give us size_t literal suffixes? Something like "0uz"? > > That's C++23. On the other hand, I don't know of anything that prevents us from defining "_zu" as user-defined literal syntax while we wait for C++23. (Dropping the underscore puts us in reserved syntax land, and likely requires suppressing warnings at least.) And I'm certainly tired of casting literals to size_t. The style guide currently says "User-defined literals should not be added casually, but only through a proposal to add a specific UDL." So propose that syntax, implemented by adding something like the following in globalDefinitions.hpp: constexpr operator ""_zu(unsigned long long int x) { // Probably only relevant for 32bit platforms. assert(x <= std::numeric_limits::max(), "invalid size_t literal"); return static_cast(x); } The C++23 literal syntax supports different cases and different orders for "u" and "z". Probably don't bother with that for ours. We should be able to provide a "_z" suffix to support ssize_t literals, but I'm failing to figure out the details of that today. (It' pretty late in my day, so I'm assuming it's possible and I'm just too sleepy to figure it out.) It's less important anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3193969292 From azafari at openjdk.org Sun Aug 17 06:56:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 17 Aug 2025 06:56:02 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp Message-ID: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. Tests: mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} ------------- Commit messages: - 8365163: [ubsan] left-shift issue in globalDefinitions.hpp Changes: https://git.openjdk.org/jdk/pull/26809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365163 Stats: 37 lines in 1 file changed: 22 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From stuefe at openjdk.org Sun Aug 17 07:53:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 17 Aug 2025 07:53:16 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe wrote: > This provides the following new metrics: > - `ProcessSize` event (new, periodic) > - vsize (for analyzing address-space fragmentation issues) > - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat) > - peak RSS > - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing) > - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size) > - `LibcStatistics` (new, periodic) > - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading) > - retained malloc size (super-important for the same reason) > - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`) > - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims) > - RSS before and RSS after > - RSS recovered by this trim > - whether it was an automatic or manual trim > - duration > - `JavaThreadStatistic` > - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.) > - nonJava thread counter (new field) (needed to interprete the os thread counter) > > Notes: > - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it. > > - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue. > > I provided implementations, as far as possible, to Linux, MacOS and Windows. > > Testing: > - ran the new tests manually and as part of GHAs label /hotspot-jfr ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3194206528 From aph at openjdk.org Sun Aug 17 08:27:05 2025 From: aph at openjdk.org (Andrew Haley) Date: Sun, 17 Aug 2025 08:27:05 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Tmp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/b82d1500..ed6b5023 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Sun Aug 17 08:45:11 2025 From: aph at openjdk.org (Andrew Haley) Date: Sun, 17 Aug 2025 08:45:11 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: <_V9WS-34rEFeSXcQmB1MPQCvHGzYJIjEcl3BFFCB1hE=.4168bee1-7452-4266-b40e-4e7a28888ab7@github.com> On Sun, 17 Aug 2025 06:49:47 GMT, Afshin Zafari wrote: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} src/hotspot/share/utilities/globalDefinitions.hpp line 1079: > 1077: return result; > 1078: } > 1079: This still has an overflowing left shift, and it's hard for the reader to follow. I'd do something like this: inline void set_low (jlong* value, jint low ) { union { jlong value_s; julong value_u; }; value_s = *value; value_u = (value_u & ~(julong)0xffffffff) | (julong)low; *value = value_s; } inline void set_high(jlong* value, jint high) { union { jlong value_s; julong value_u; }; value_s = *value; value_u = (value_u & (julong)0xfffffffful) | ((julong)high << 32); *value = value_s; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2280787149 From ysuenaga at openjdk.org Sun Aug 17 09:09:44 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 17 Aug 2025 09:09:44 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: > `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: > > > CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss > CPU Model and flags from /proc/cpuinfo: > model name : Intel(R) Core(TM) Ultra 5 225U > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd > > > It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". > https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html > > According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 > In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Add HYBRID to CPUFeature in JVMCI ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26808/files - new: https://git.openjdk.org/jdk/pull/26808/files/15828727..234a67b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26808/head:pull/26808 PR: https://git.openjdk.org/jdk/pull/26808 From kbarrett at openjdk.org Sun Aug 17 12:44:09 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 17 Aug 2025 12:44:09 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Sun, 17 Aug 2025 06:49:47 GMT, Afshin Zafari wrote: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3126326235 From kbarrett at openjdk.org Sun Aug 17 12:44:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 17 Aug 2025 12:44:11 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: <_V9WS-34rEFeSXcQmB1MPQCvHGzYJIjEcl3BFFCB1hE=.4168bee1-7452-4266-b40e-4e7a28888ab7@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> <_V9WS-34rEFeSXcQmB1MPQCvHGzYJIjEcl3BFFCB1hE=.4168bee1-7452-4266-b40e-4e7a28888ab7@github.com> Message-ID: On Sun, 17 Aug 2025 08:42:53 GMT, Andrew Haley wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > src/hotspot/share/utilities/globalDefinitions.hpp line 1079: > >> 1077: return result; >> 1078: } >> 1079: > > This still has an overflowing left shift, and it's hard for the reader to follow. > > I'd do something like this: > > > inline void set_low (jlong* value, jint low ) { > union { > jlong value_s; > julong value_u; > }; > value_s = *value; > value_u = (value_u & ~(julong)0xffffffff) | (julong)low; > *value = value_s; > } > > inline void set_high(jlong* value, jint high) { > union { > jlong value_s; > julong value_u; > }; > value_s = *value; > value_u = (value_u & (julong)0xfffffffful) | ((julong)high << 32); > *value = value_s; > } First, we do not care about left shift of negative value on its own (JDK-8240259). Indicating this issue has anything to do with that is just confusing matters. What we care about is signed integer overflow, which is UB. And there is indeed such overflow in this code. Having the JBS issue and the PR description be more direct about that would have avoided confusion on my part. (I'm somewhat surprised none of our compilers just breaks this obvious overflow. Or maybe they do and we've not noticed, though that seems unlikely.) As @theRealAph points out, the proposed change still contains overflows. For example 1061: *value &= (jlong)0xffffffff << 32; But this can be vastly simplified to just inline jlong jlong_from(jint h, jint l) { // First cast jint values to juint, so cast to julong will zero-extend. julong high = (julong)(juint)h << 32; julong low = (julong)(juint)l; return (jlong)(high | low); } and delete the now unused set_high and set_low functions. (There are set_high and set_low functions in sharedRuntimeMath.hpp, but they deal with double rather than jlong.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2280864836 From kbarrett at openjdk.org Sun Aug 17 12:57:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 17 Aug 2025 12:57:11 GMT Subject: RFR: 8365245: Move size reducing operations to GrowableArrayWithAllocator In-Reply-To: References: Message-ID: <7yztdDp6KQTmn3feq9f4WktYBwZ6EE7LKM-5PXg0tEk=.168c4b25-b23e-4c1c-bd4e-1673f36396a3@github.com> On Fri, 15 Aug 2025 13:58:57 GMT, Johan Sj?len wrote: >> Please review this change to GrowableArray to move size reducing operations >> from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. >> See JBS for rationale for this move. >> >> This is mostly just a simple code motion change, with the moved functions >> being updated to account for different name lookup rules now that they are in >> a class with a class template base class. For the most part this refactoring >> didn't require any client code changes. All but one use of one moved function >> was with a GrowableArrayWithAllocator-derived class, so not affected by moving >> the functions. The one exception was a test of ZArraySlice that was modified >> to no longer use GA::pop(). >> >> Testing: mach5 tier1. > > As I've understood, the need for moving len-reducing operations to the GAWA class comes from the (future) need to be able to destruct elements when they go out of range. > > In other words, when an element is popped in the future it should be destructed and freed by the allocator. This PR is a stepping stone to that kind of change. > > Considering that, I think that it's correct to move these methods to GAWA and so I'm approving this PR. > > Thanks! Thanks for reviews @jdksjolen and @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/26726#issuecomment-3194369302 From kbarrett at openjdk.org Sun Aug 17 13:00:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 17 Aug 2025 13:00:16 GMT Subject: Integrated: 8365245: Move size reducing operations to GrowableArrayWithAllocator In-Reply-To: References: Message-ID: <3fwaaawT0AguQDG90fxbomxfU7gDO7nEdcubBTuO0so=.77a84137-fabf-4e52-92a7-cf2946608b70@github.com> On Mon, 11 Aug 2025 13:06:01 GMT, Kim Barrett wrote: > Please review this change to GrowableArray to move size reducing operations > from GrowableArrayBase and GrowableArrayView to GrowableArrayWithAllocator. > See JBS for rationale for this move. > > This is mostly just a simple code motion change, with the moved functions > being updated to account for different name lookup rules now that they are in > a class with a class template base class. For the most part this refactoring > didn't require any client code changes. All but one use of one moved function > was with a GrowableArrayWithAllocator-derived class, so not affected by moving > the functions. The one exception was a test of ZArraySlice that was modified > to no longer use GA::pop(). > > Testing: mach5 tier1. This pull request has now been integrated. Changeset: bd65d483 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/bd65d483df4742bb7ce79b613f10f70a45117f84 Stats: 134 lines in 2 files changed: 69 ins; 64 del; 1 mod 8365245: Move size reducing operations to GrowableArrayWithAllocator Reviewed-by: jsjolen, stefank ------------- PR: https://git.openjdk.org/jdk/pull/26726 From tanksherman27 at gmail.com Sun Aug 17 18:43:39 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Mon, 18 Aug 2025 02:43:39 +0800 Subject: Simplifying the poisoning mechanism used in HotSpot Message-ID: Hi all, Currently, I'm working on refining the poisoning mechanism used in HotSpot for forbidding calls to certain methods. The current system works, but it is a little unwieldy, unfortunately. I recall many issues being involved in its creation, from requiring headers to be included in the exact right order to not cause clang to explode during compilation, to complex workarounds and much code being needed to dodge compiler warnings. Arguably the biggest downside of this system is the fact that you need to select the exact correct macro to use for forbidding any methods in the codebase (There are several), and to select correctly you need to check the system headers, and choosing the wrong one will cause errors that aren't obvious on how to fix to surface, which could potentially be confusing. An older approach I tried before the current system was set up was defining a method with an identical signature in an inline namespace called forbidden, and then deleting that method or adding the deprecated attribute. The main problems with that approach is that there is no way to force C++ to choose the inline namespace over the Standard Library counterpart. This causes an ambiguity error rather than the desired "You are not allowed to use this method" error, but more importantly you couldn't control it, meaning there was no way to permit forbidden methods. The only way you can force C++ to definitively use the one in the namespace is by hooking each call with a function macro. With a simple function macro redirection, you could reroute calls to, say, malloc, into a permission manager namespace. In that namespace would be another different malloc, as described above. This definition would be annotated to deliberately cause compile failures if called. This yields the desired effect of not allowing any forbidden methods into the codebase, but does come with one drawback, namely that any declarations (Not just calls!) of a method with the same name in any of our code (Think of the methods in the os class for instance) will be overwritten as well. There's just 1 way to bypass this: Save the macro to a macro stack (All our compilers support this), undefine the macro redirection, declare or define the method in our own code, then pop the redirection off the macro stack to reactivate the poisoning. The macro deactivation could be stuffed into a header for convenience, if needed, and then the header could be included at sites where it's needed. A small system with this underlying principle is already used in awt.dll for Windows to forbid calls to malloc, calloc and free, and other codebases do use similar methods to forbid calls to certain methods. Question is, does this somewhat more compact system solve more problems than it creates? It does eliminate several of the drawbacks of the current system, but comes with problems of its own, as mentioned above. I'd like to get feedback on this before deciding if this should be scrapped or improved upon further. I'm aware I'm not the best with words, so if anyone is confused as to what I'm talking about, the latest prototype I have is here, so you can more easily visualize what I mean: https://godbolt.org/z/bGohMx4fc Thanks for your time and have a great day/week ahead! best regards, Julian From tanksherman27 at gmail.com Sun Aug 17 18:53:45 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Mon, 18 Aug 2025 02:53:45 +0800 Subject: Simplifying the poisoning mechanism used in HotSpot In-Reply-To: References: Message-ID: Argh, some extra code I put in there isn't showing up, here's the new link: https://godbolt.org/z/jPbWcbn7E On Mon, Aug 18, 2025 at 2:43?AM Julian Waters wrote: > > Hi all, > > Currently, I'm working on refining the poisoning mechanism used in > HotSpot for forbidding calls to certain methods. The current system > works, but it is a little unwieldy, unfortunately. I recall many > issues being involved in its creation, from requiring headers to be > included in the exact right order to not cause clang to explode during > compilation, to complex workarounds and much code being needed to > dodge compiler warnings. Arguably the biggest downside of this system > is the fact that you need to select the exact correct macro to use for > forbidding any methods in the codebase (There are several), and to > select correctly you need to check the system headers, and choosing > the wrong one will cause errors that aren't obvious on how to fix to > surface, which could potentially be confusing. > > An older approach I tried before the current system was set up was > defining a method with an identical signature in an inline namespace > called forbidden, and then deleting that method or adding the > deprecated attribute. The main problems with that approach is that > there is no way to force C++ to choose the inline namespace over the > Standard Library counterpart. This causes an ambiguity error rather > than the desired "You are not allowed to use this method" error, but > more importantly you couldn't control it, meaning there was no way to > permit forbidden methods. The only way you can force C++ to > definitively use the one in the namespace is by hooking each call with > a function macro. > > With a simple function macro redirection, you could reroute calls to, > say, malloc, into a permission manager namespace. In that namespace > would be another different malloc, as described above. This definition > would be annotated to deliberately cause compile failures if called. > This yields the desired effect of not allowing any forbidden methods > into the codebase, but does come with one drawback, namely that any > declarations (Not just calls!) of a method with the same name in any > of our code (Think of the methods in the os class for instance) will > be overwritten as well. There's just 1 way to bypass this: Save the > macro to a macro stack (All our compilers support this), undefine the > macro redirection, declare or define the method in our own code, then > pop the redirection off the macro stack to reactivate the poisoning. > The macro deactivation could be stuffed into a header for convenience, > if needed, and then the header could be included at sites where it's > needed. A small system with this underlying principle is already used > in awt.dll for Windows to forbid calls to malloc, calloc and free, and > other codebases do use similar methods to forbid calls to certain > methods. > > Question is, does this somewhat more compact system solve more > problems than it creates? It does eliminate several of the drawbacks > of the current system, but comes with problems of its own, as > mentioned above. I'd like to get feedback on this before deciding if > this should be scrapped or improved upon further. > > I'm aware I'm not the best with words, so if anyone is confused as to > what I'm talking about, the latest prototype I have is here, so you > can more easily visualize what I mean: https://godbolt.org/z/bGohMx4fc > > Thanks for your time and have a great day/week ahead! > > best regards, > Julian From dholmes at openjdk.org Sun Aug 17 21:39:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 17 Aug 2025 21:39:13 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 12 Aug 2025 12:07:53 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Added atomic loads to getters Our convention for lock-free code is that we should use `Atomic::load` and `Atomic::store` for all accesses to the shared variable. - this serves as clear documentation of the lock-free nature of the code. The use, or not, of `volatile` on the declaration of the shared variable is not a convention we have firmly established or documented. I am in the camp that the `volatile` should not be present on the declaration as we have internalised/encapsulated the `volatile` within the `Atomic` functions. @albertnetymk suggestion to use explicit `release` between the store and the `pthread_kill` does also address the visibility concern unlike the earlier `release_store` suggestion which puts the `release` in the wrong place. On further reflection my suggestion about the `fence` should also make the `fence` explicit between the store and the `pthread_kill` rather than being inside the setter method (which again by our own conventions should be renamed to have `fence` in the name if we did that). Arguably, as stated much much earlier, we don't need any explicit memory ordering here in practice as the signal implementation must provide its own ordering guarantees to actually function - and there is no way a compiler would ever re-order the store with the `pthread_kill` call! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3194666749 From dholmes at openjdk.org Sun Aug 17 21:47:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 17 Aug 2025 21:47:13 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 12 Aug 2025 12:07:53 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Added atomic loads to getters src/hotspot/share/utilities/vmError.cpp line 1345: > 1343: // updates except the 1st one. Those can hypothetically happen > 1344: // if more than one thread times out. > 1345: // The default memory ordering guarantees visibility to other threads. The use of `replace_if_null` is a good alternative here. The comment is a bit wordy. I would suggest a simpler: // Only preserve the first thread to time-out this way. The atomic operation ensures // visibility to the target thread. and of course the same comment needs to be in `set_safepoint_timed_out_thread` (or else use a comment block before the two functions to describe both their operations at once). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2281031302 From kim.barrett at oracle.com Mon Aug 18 01:48:50 2025 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 17 Aug 2025 21:48:50 -0400 Subject: Simplifying the poisoning mechanism used in HotSpot In-Reply-To: References: Message-ID: <34818422-3d61-49c3-adb7-1a57c1a803da@oracle.com> On 8/17/25 2:53 PM, Julian Waters wrote: > With a simple function macro redirection, you could reroute calls to, say, > malloc, [...] does come with one drawback, namely that any declarations (Not > just calls!) of a method with the same name in any of our code [...] will be > overwritten as well. The need to undef the `malloc` macro in order to call `os::malloc` is the classic problem of macros being unscoped. There are going to be lots of that sort of thing. And not just for function calls and declarations. For example, the `exit` function () is poisoned, and there are variables with that name (it's a common label name in macroAssembler code, for example). I think this is a deal breaker for any such approach. > Arguably the biggest downside of this system is the fact that you need to > select the exact correct macro to use for forbidding any methods in the > codebase (There are several) I don't see a way to avoid that with a redeclaration-based poisoning mechanism. And all of the other mechanisms I looked at had much worse problems. I know of two issues with the current mechanism, both involving clang. One has already been fixed, with the fix probably in clang 21. So someday we should be able to remove our workaround for that one. And it's just a warning suppression in an appropriate place. See FORBIDDEN_FUNCTION_IGNORE_CLANG_FORTIFY_WARNING. The other is that clang does something that is at least not useful, and is arguably just wrong, in the interaction between its compiler-specific noreturn attribute and the standard noreturn attribute. This is what leads to the annoying workarounds discussed in the opening of this thread. Unfortunately, some of the clang developers weren't convinced. See discussion in the bug referenced in the comment for FORBIDDEN_FUNCTION_NORETURN_ATTRIBUTE. Our clang workarounds could be removed if clang were changed as suggested (making it like MSVC and gcc in the relevant behavior). I don't know if that's ever going to happen. :( Maybe someone with more influence in that community than I have could take up the cause here. From kim.barrett at oracle.com Mon Aug 18 01:55:27 2025 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 17 Aug 2025 21:55:27 -0400 Subject: Simplifying the poisoning mechanism used in HotSpot In-Reply-To: References: Message-ID: On 8/17/25 2:43 PM, Julian Waters wrote: > [...] you couldn't control it, meaning there was no way to > permit forbidden methods. My recollection is that the problem is not that there's no way to permit forbidden functions where needed in our code, it's that there's no way to turn off the forbidding for third party code (such as the gtest framework). If all HotSpot code were in a namespace, we could easily poison via non-usable declarations within that namespace, without affecting third party code in other namespaces (including the global namespace). (And also without affecting our ability to escape out where needed.) But that's not a thing. From kbarrett at openjdk.org Mon Aug 18 04:10:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 18 Aug 2025 04:10:13 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 128: > 126: [n4147](http://wg21.link/n4147) > 127: [n4424](http://wg21.link/n4424) > 128: [p0386r2](http://wg21.link/p0386r2) After looking at inline variables more carefully as part of writing it up for the style guide, I'm inclined to move inline variables to the undecided or forbidden category. They seem to be a solution to a problem I think we don't really have. Basically, they let you provide the full definition for a non-local variable in a header file, rather than declaring it in the header and defining it in an associated .cpp file. The motivating use-case is a component or library that is header only, to simplify client use by avoiding build issues. But that's just not a thing we care about for HotSpot code. So what WE get from an inline variable is having a complete declaration and definition in one place, rather than separating the declaration from the definition (so probably saving a little bit of code), at the cost of putting the initialization expression in the header (which might require pulling other stuff into the header), and maybe making the compiler work a little harder. The benefit of that seems minimal at best. The one part of it that seems slightly useful is that a constexpr variable is implicitly inline, so doesn't need a definition without an initializer in a .cpp file if the variable is ODR-used. Indeed, that's now treated as a duplicate defintion and deprecated usage. But we haven't had any warnings, so guessing we don't actually have any of those. We can take advantage of this for future usage. Any other opinions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2281251684 From chagedorn at openjdk.org Mon Aug 18 06:16:26 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 18 Aug 2025 06:16:26 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v10] In-Reply-To: References: Message-ID: <4JJUFVogUIc2r8Pe_MjaRJlDgSStO7WwYY3iM2Eyjvk=.7c1cfa49-982c-4f4f-b77f-660f09f49714@github.com> On Fri, 15 Aug 2025 09:42:11 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > missed a dash Looks good, thanks! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3126909638 From chagedorn at openjdk.org Mon Aug 18 06:16:28 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 18 Aug 2025 06:16:28 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> References: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> Message-ID: On Fri, 15 Aug 2025 08:27:50 GMT, Manuel H?ssig wrote: >> src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 44: >> >>> 42: CompileTask* task = CompilerThread::current()->task(); >>> 43: assert(false, "compile task %d (%s) timed out after " INTPTR_FORMAT " ms", >>> 44: task->compile_id(), task->method()->name_and_sig_as_C_string(), CompileTaskTimeout); >> >> Normally, you would probably need a `ResourceMark` for getting the method name. However, I'm not sure if you can do that as well here inside the signal handler. Maybe someone else can comment on that. > > Does this really matter when we are doing it right before crashing the VM? I'm not entirely sure but I guess it's fine since it's in the same thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2281386549 From bmaillard at openjdk.org Mon Aug 18 07:07:00 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 18 Aug 2025 07:07:00 GMT Subject: RFR: 8360389: Support printing from C2 compiled code Message-ID: This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. ## Usage Suppose we have this piece of Java code, that simply computes an arithmetic operation, and that we compile `square` with C2. class Square { static int square(int a) { return a * a; } public static void main(String[] args) { square(9); } } We would like to inspect the node that contains the value returned in this method. We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. ```c++ void Compile::return_values(JVMState* jvms) { GraphKit kit(jvms); Node* ret = new ReturnNode(TypeFunc::Parms, kit.control(), kit.i_o(), kit.reset_memory(), kit.frameptr(), kit.returnadr()); // Add zero or 1 return values int ret_size = tf()->range()->cnt() - TypeFunc::Parms; Node* return_value; if (ret_size > 0) { kit.inc_sp(-ret_size); // pop the return value(s) kit.sync_jvms(); return_value = kit.argument(0); ret->add_req(return_value); // <-------------------- Simply insert this C->make_debug_print_new("return:", initial_gvn(), return_value); } // bind it to root root()->add_req(ret); record_for_igvn(ret); initial_gvn()->transform(ret); } We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` and we get the following output: return: int 81 This case is of course trivial, but more useful examples are shown later. ## Implementation ## Implementation The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. The first argument to the runtime printing method is the printing message, a static string encoded as a `ConP` node in the graph. The remaining arguments are the actual nodes being printed. A key part is wiring the new call into the existing control-flow graph: - A call node needs a control input and also at least one control usage (otherwise it will be removed). - We wish the debug print call to be as "close as possible" in the CFG to the nodes being printed, by attaching it at the most appropriate control point. - To do this, we: - Follow the data dependencies of each argument node until reaching control-flow nodes, collecting these as candidates. - Pick the candidate that is reachable from all other candidates in the CFG (i.e., all other candidates are predecessors of the one we pick). - We then rewire the control users of the selected candidate node to use the new call node as their control input. This ensures the call node has a control usage and is not deleted as dead code. image ## More examples Here are other examples that showcase uses of this debug feature at various stages in the compilation pipeline. Some of them are inspired by issues I worked on recently. ### Identity optimization #### Modified C2 code In `ConvD2LNode::Identity`: ```c++ Node* ConvD2LNode::Identity(PhaseGVN* phase) { // Remove ConvD2L->ConvL2D->ConvD2L sequences. if(in(1)->Opcode() == Op_ConvL2D && in(1)->in(1)->Opcode() == Op_ConvD2L) { Node* identity = in(1)->in(1); phase->C->make_debug_print_new("value: ", phase, identity, phase->C->top()); return identity; } return this; } #### Java program class TestSimpleD2L { int instanceCount; void test(long d) { int i = 1; int j = 1; while (++i < 37) { d = i; for (; 8 > j; ++j) { instanceCount = (int) d; d = instanceCount; } } } void main(String[] strArr) { for (int i = 0; i < 50_000; ++i) { test(1); } } } java -XX:CompileCommand=quiet -XX:CompileCommand="compileonly,TestSimpleD2L::test" -XX:-TieredCompilation -Xbatch -Xcomp TestSimpleD2L.java ### Selecting nodes by ID between two optimization phases #### Modified C2 code In `Compile::Optimize` ```c++ // Set loop opts counter if((_loop_opts_cnt > 0) && (has_loops() || has_split_ifs())) { { TracePhase tp(_t_idealLoop); PhaseIdealLoop::optimize(igvn, LoopOptsDefault); _loop_opts_cnt--; if (major_progress()) print_method(PHASE_PHASEIDEALLOOP1, 2); if (failing()) return; } // <----------------- START Node* parm0 = C->root()->find(98); Node* parm1 = C->root()->find(108); C->make_debug_print_new("hello there: ", &igvn, parm0, parm1); // <----------------- END #### Java program public class Loop { static int foo(int x) { return x % 17; } static int test(int iterations) { int x = 1; int y = iterations + 20; for (int i = 0; i < iterations; i++) { x += foo(x); // to print result of foo: id = 98 // to print x + foo(x): id = 108 } return x + y; } public static void main(String[] args) { int res = test(100); System.out.println(res); } } java -XX:CompileCommand=quiet -XX:CompileCommand="compileonly,Loop::test" -XX:-TieredCompilation -Xcomp -Xbatch -XX:-Inline Loop.java ### Ideal optimization #### Modified C2 code In `ModINode::Ideal`: ```c++ // Check for useless control input // Check for excluding mod-zero case if (in(0) && (ti->_hi < 0 || ti->_lo > 0)) { set_req(0, nullptr); // Yank control input phase->C->make_debug_print_new("ModI: ", phase, this); return this; } #### Java program public class TestModControlFoldedAfterCCP { static void test() { int i22, i24 = -1191, i28; int iArr1[] = new int[1]; for (int i = 1;i < 100; i++) { for (int j = 4; j > i; j--) { i22 = i24; // divisor is either -1191 or -13957 iArr1[0] = 5 % i22; } for (i28 = i; i28 < 2; ++i28) { i24 = -13957; } } } public static void main(String[] args) { test(); } } java -XX:CompileCommand=quiet -XX:CompileCommand="compileonly,TestModControlFoldedAfterCCP::test" -XX:-TieredCompilation -Xcomp -Xbatch -XX:-Inline TestModControlFoldedAfterCCP.java ## Testing - [x] [GitHub Actions](https://github.com/benoitmaillard/jdk/actions?query=branch%3AJDK-8360389) - [x] tier1-3, plus some internal testing Thank you for reviewing! ------------- Commit messages: - Fix style and add comments - Use format consistent with fieldDescriptor::print_on_for - Fix bad format specifier - Clean up includes - Use platform-dependent macros for printing primitives types - Remove old versions and rename new one - Add null check when finding control candidates - Remove unnecessary additions to worklist - Fix bug caused by bad rewiring with nodes that have several control inputs - Remove --i in DUIterator use - ... and 31 more: https://git.openjdk.org/jdk/compare/c70258ca...d7641ea7 Changes: https://git.openjdk.org/jdk/pull/26475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360389 Stats: 290 lines in 6 files changed: 290 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From thartmann at openjdk.org Mon Aug 18 07:07:00 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 18 Aug 2025 07:07:00 GMT Subject: RFR: 8360389: Support printing from C2 compiled code In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 09:39:00 GMT, Beno?t Maillard wrote: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print_new("return:", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static ... Great work Beno?t! This will be very useful for debugging. With the current changes, we only support adding printing during parsing, i.e. when `GraphKit` is available. I think it would be great if we could add printing after parsing, for example only once a specific IGVN or loop optimization happened. Do you think that's feasible? src/hotspot/share/opto/graphKit.hpp line 784: > 782: address call_addr = CAST_FROM_FN_PTR(address, SharedRuntime::debug_print); > 783: > 784: Node* str_node = new ConPNode(TypeRawPtr::make(((address) str))); Don't you need a `transform` here? src/hotspot/share/opto/runtime.cpp line 1787: > 1785: switch (parm->bottom_type()->basic_type()) { > 1786: case T_BOOLEAN: > 1787: fields[(*argp)++] = TypeInt::BOOL; I think you can use `Type::get_const_basic_type(parm->bottom_type()->basic_type())` here and special case `T_DOUBLE` / `T_LONG`. src/hotspot/share/opto/runtime.cpp line 1813: > 1811: break; > 1812: case T_OBJECT: > 1813: fields[(*argp)++] = TypePtr::NOTNULL; I think passing null should be okay as well, right? I would use `TypeInstPtr::BOTTOM` here, which will be taking care of by `Type::get_const_basic_type`. ------------- PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3060479577 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234764495 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234762106 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234763252 From bmaillard at openjdk.org Mon Aug 18 07:07:00 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 18 Aug 2025 07:07:00 GMT Subject: RFR: 8360389: Support printing from C2 compiled code In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 05:44:02 GMT, Tobias Hartmann wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print_new("return:", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile tim... > > src/hotspot/share/opto/runtime.cpp line 1787: > >> 1785: switch (parm->bottom_type()->basic_type()) { >> 1786: case T_BOOLEAN: >> 1787: fields[(*argp)++] = TypeInt::BOOL; > > I think you can use `Type::get_const_basic_type(parm->bottom_type()->basic_type())` here and special case `T_DOUBLE` / `T_LONG`. I was actually looking for something like this but must have missed it! Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2238784716 From dholmes at openjdk.org Mon Aug 18 07:08:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Aug 2025 07:08:11 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add HYBRID to CPUFeature in JVMCI These hybrid CPUs are a nightmare to understand/describe/use. How does "logical cpus" map to what we return from `active_processor_count`? i.e. what does the DCmd show after your change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3195387030 From jsjolen at openjdk.org Mon Aug 18 07:20:15 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Aug 2025 07:20:15 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 04:07:34 GMT, Kim Barrett wrote: >> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can >> be more easily structured and captured than bare email. Once discussion >> settles down I'll turn the results into HotSpot Style Guide changes. I don't >> intend to integrate any version of this document to the OpenJDK repository. > > doc/cpp17-features.md line 128: > >> 126: [n4147](http://wg21.link/n4147) >> 127: [n4424](http://wg21.link/n4424) >> 128: [p0386r2](http://wg21.link/p0386r2) > > After looking at inline variables more carefully as part of writing it up for > the style guide, I'm inclined to move inline variables to the undecided or > forbidden category. They seem to be a solution to a problem I think we don't > really have. > > Basically, they let you provide the full definition for a non-local variable > in a header file, rather than declaring it in the header and defining it in > an associated .cpp file. The motivating use-case is a component or library > that is header only, to simplify client use by avoiding build issues. But > that's just not a thing we care about for HotSpot code. > > So what WE get from an inline variable is having a complete declaration and > definition in one place, rather than separating the declaration from the > definition (so probably saving a little bit of code), at the cost of putting > the initialization expression in the header (which might require pulling other > stuff into the header), and maybe making the compiler work a little harder. > > The benefit of that seems minimal at best. > > The one part of it that seems slightly useful is that a constexpr variable is > implicitly inline, so doesn't need a definition without an initializer in a > .cpp file if the variable is ODR-used. Indeed, that's now treated as a > duplicate defintion and deprecated usage. But we haven't had any warnings, so > guessing we don't actually have any of those. We can take advantage of this > for future usage. > > Any other opinions? It's a bit of ceremony to do the header + source file edits for static variables, but maybe it's one worth living with to not have to explain to people what an inline variable is. I think that they'll be accepting of `static constexpr` variables being defined inline, as there's no inline keyword involved and constexpr is already special anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2281504382 From tanksherman27 at gmail.com Mon Aug 18 07:21:58 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Mon, 18 Aug 2025 15:21:58 +0800 Subject: Simplifying the poisoning mechanism used in HotSpot In-Reply-To: References: Message-ID: Argh, there's no one good way to poison in C++ after all. I guess the language wasn't really designed for that. I explored other ways, such as symbol checking the compiled code for forbidden symbols like we do with operator new, but that couldn't work as there's no way to attach metadata to a method to permit using it where needed. Templates aren't even seen by the compiler, and a C++ static analyzer I tried to write specifically for HotSpot was scrapped after I realized I would have to pass the exact defines in the command line passed to the compiler to the static analyzer, as well as match each and every compiler's intrinsic defines as well, an impossible task. I did notice googletest makes heavy use of namespaces however. I'm not sure if there are any other 3rd party libraries in use (The previous mail seems to imply other libraries are used for HotSpot besides googletest) or if we will add any more, but injecting a using declaration into the googletest namespace (Done without editing the third party code) does bypass the inline namespace and compiles without issue. Under the assumption that googletest will be the only third party code HotSpot will ever use, this might be a viable way to solve the permitting problem, but the old issue of the error being an ambiguity one instead of a proper "This method is forbidden" warning unfortunately still applies. best regards, Julian On Mon, Aug 18, 2025 at 9:55?AM Kim Barrett wrote: > > On 8/17/25 2:43 PM, Julian Waters wrote: > > [...] you couldn't control it, meaning there was no way to > > permit forbidden methods. > > My recollection is that the problem is not that there's no way to permit > forbidden functions where needed in our code, it's that there's no way to turn > off the forbidding for third party code (such as the gtest framework). > > If all HotSpot code were in a namespace, we could easily poison via non-usable > declarations within that namespace, without affecting third party code in > other namespaces (including the global namespace). (And also without affecting > our ability to escape out where needed.) But that's not a thing. > From mhaessig at openjdk.org Mon Aug 18 08:00:19 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 18 Aug 2025 08:00:19 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> Message-ID: On Mon, 18 Aug 2025 06:13:36 GMT, Christian Hagedorn wrote: >> Does this really matter when we are doing it right before crashing the VM? > > I'm not entirely sure but I guess it's fine since it's in the same thread. Maybe @dean-long can shed some light on this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2281593869 From shade at openjdk.org Mon Aug 18 08:18:13 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Aug 2025 08:18:13 GMT Subject: RFR: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier In-Reply-To: References: Message-ID: <3n5Ch6m3PL3zCM0S3ZS-g0TCH8EL6-SiQbJjAZe4bHc=.9a0ee0b8-fa35-470f-966a-27b891db6214@github.com> On Fri, 15 Aug 2025 18:18:02 GMT, Coleen Phillimore wrote: >> I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. >> >> We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. >> >> Additional testing: >> - [x] Shenandoah + CDS reproducer crashes reliably >> - [x] Linux AArch64 server fastdebug, `all` > > Looks good. Thank you, @coleenp! I think I need another Review to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26797#issuecomment-3195607006 From ysuenaga at openjdk.org Mon Aug 18 08:19:13 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 18 Aug 2025 08:19:13 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: <0XqOqgNQeltWkfd-6Q6n-BkITEqjS3r2CnaGUOrIds4=.84521e88-a03c-43da-8ef0-8c0522829361@github.com> On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add HYBRID to CPUFeature in JVMCI You can get following output from DCmd after this change: CPU: total 14 (initial active 14) (14 threads) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid `-Xlog:os=trace` reports `active_processor_count` is 14 - it is correct on my laptop (Core Ultra), and matches the result of DCmd. [0.021s][trace][os] active_processor_count: using static path - configured processors: 14 [0.022s][trace][os] active_processor_count: sched_getaffinity processor count: 14 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3195610671 From vyazici at openjdk.org Mon Aug 18 08:24:20 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 18 Aug 2025 08:24:20 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v16] In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> Message-ID: On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: > > - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions > - Document why `Preconditions` is not used [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842), addressed by this PR, is the first step in a series of similar improvements under the [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) umbrella issue. I wanted to get this one in perfect shape to serve as a guide for the subsequent PRs, hence the meticulous effort. Thanks so much to everyone helped with reviewing this work. ? ? I've verified that `tier1,tier2,tier3,tier4,tier5,hs-comp-stress,hs-precheckin-comp` passes for 2ba4ba6f455 on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3195628634 From duke at openjdk.org Mon Aug 18 08:38:34 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 18 Aug 2025 08:38:34 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor Message-ID: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. This change fixes a build failure I'm getting with clang20: [`memset(this, 0, sizeof(*this))`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/resolvedMethodEntry.cpp#L43) is not acceptable unless the class is trivially copyable (`-Wtrivial-copy`). Testing: - [x] tier1 fast-debug - [x] tier2 fast-debug ------------- Commit messages: - use copy ctor Changes: https://git.openjdk.org/jdk/pull/26818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365661 Stats: 45 lines in 2 files changed: 0 ins; 45 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26818/head:pull/26818 PR: https://git.openjdk.org/jdk/pull/26818 From aph at openjdk.org Mon Aug 18 08:50:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 18 Aug 2025 08:50:16 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 07:17:09 GMT, Johan Sj?len wrote: >> doc/cpp17-features.md line 128: >> >>> 126: [n4147](http://wg21.link/n4147) >>> 127: [n4424](http://wg21.link/n4424) >>> 128: [p0386r2](http://wg21.link/p0386r2) >> >> After looking at inline variables more carefully as part of writing it up for >> the style guide, I'm inclined to move inline variables to the undecided or >> forbidden category. They seem to be a solution to a problem I think we don't >> really have. >> >> Basically, they let you provide the full definition for a non-local variable >> in a header file, rather than declaring it in the header and defining it in >> an associated .cpp file. The motivating use-case is a component or library >> that is header only, to simplify client use by avoiding build issues. But >> that's just not a thing we care about for HotSpot code. >> >> So what WE get from an inline variable is having a complete declaration and >> definition in one place, rather than separating the declaration from the >> definition (so probably saving a little bit of code), at the cost of putting >> the initialization expression in the header (which might require pulling other >> stuff into the header), and maybe making the compiler work a little harder. >> >> The benefit of that seems minimal at best. >> >> The one part of it that seems slightly useful is that a constexpr variable is >> implicitly inline, so doesn't need a definition without an initializer in a >> .cpp file if the variable is ODR-used. Indeed, that's now treated as a >> duplicate defintion and deprecated usage. But we haven't had any warnings, so >> guessing we don't actually have any of those. We can take advantage of this >> for future usage. >> >> Any other opinions? > > It's a bit of ceremony to do the header + source file edits for static variables, but maybe it's one worth living with to not have to explain to people what an inline variable is. I think that they'll be accepting of `static constexpr` variables being defined inline, as there's no inline keyword involved and constexpr is already special anyway. > Any other opinions? The benefit is minimal, but the cost is pretty low, and people will get used to it soon enough. Also, you'd have to explain to HotSpot newcomers why this feature is bad, but it isn't really bad. If it'd always been like that, no one would be at all bothered by it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2281720573 From lkorinth at openjdk.org Mon Aug 18 09:10:13 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 09:10:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD > > make/RunTests.gmk line 940: > >> 938: JTREG_AUTO_PROBLEM_LISTS := >> 939: # Please reach consensus before changing this. It was not easy changing it to a `1`. >> 940: JTREG_AUTO_TIMEOUT_FACTOR := 1 > > Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5() It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281781536 From lkorinth at openjdk.org Mon Aug 18 09:18:12 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 09:18:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth wrote: >> make/RunTests.gmk line 940: >> >>> 938: JTREG_AUTO_PROBLEM_LISTS := >>> 939: # Please reach consensus before changing this. It was not easy changing it to a `1`. >>> 940: JTREG_AUTO_TIMEOUT_FACTOR := 1 >> >> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5() > > It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP. It is also something that can be changed later, in a follow up fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281802454 From mhaessig at openjdk.org Mon Aug 18 09:25:15 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 18 Aug 2025 09:25:15 GMT Subject: RFR: 8360389: Support printing from C2 compiled code In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 09:39:00 GMT, Beno?t Maillard wrote: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print_new("return:", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static ... Thank you for working on this, @benoitmaillard! This will prove really useful. I think your logic is sound, but I have some issues with the printing. src/hotspot/share/opto/compile.cpp line 5483: > 5481: } > 5482: > 5483: #endif Suggestion: #endif // !PRODUCT Nit: This makes it a bit easier to follow the ifdefs. src/hotspot/share/runtime/sharedRuntime.cpp line 268: > 266: } > 267: > 268: // Runtime methods for printf-style debug nodes (same printing format as fieldDescriptor::print_on_for) All of these methods should probably use `print_cr()` instead of the manual `\n` to provide consistent output on Windows. src/hotspot/share/runtime/sharedRuntime.cpp line 292: > 290: tty->print_raw("long "); > 291: tty->print_jlong(x); > 292: tty->print_cr(""); Suggestion: tty->print_cr("long " JLONG_FORMAT, x); This is a bit more concise. src/hotspot/share/runtime/sharedRuntime.cpp line 305: > 303: void SharedRuntime::debug_print_value(oopDesc* x) { > 304: x->print(); > 305: } Can you elaborate why you need an empty print? ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3127402275 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281768619 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281725334 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281721578 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281726992 From jsjolen at openjdk.org Mon Aug 18 09:33:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Aug 2025 09:33:14 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v3] In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 05:06:27 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe 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 branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - Update metaspace.hpp > - fix rebase error > - fix mac build > - ... and 1 more: https://git.openjdk.org/jdk/compare/57210af9...d9696c76 src/hotspot/share/memory/metaspace.cpp line 1051: > 1049: } > 1050: > 1051: bool Metaspace::metadata_is_live(const Metadata* md, FailureHint* hint) { Why can't `FailureHint` have an arm called 'no_failure' and just skip it as an out-parameter, having the failure be the return value? src/hotspot/share/memory/metaspace.hpp line 162: > 160: unknown = 0, > 161: // outside class space/metaspace > 162: outside, // 1 I don't see why we need to write the value of each enum arm, can't our IDEs figure that out for us if necessary :-)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2281422124 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2281427915 From lkorinth at openjdk.org Mon Aug 18 09:36:13 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 09:36:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2] In-Reply-To: References: Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com> On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon wrote: > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > Would you mind also running tier9 to avoid surprises there. I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195900610 From lkorinth at openjdk.org Mon Aug 18 09:43:14 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 09:43:14 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@github.com> On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD If there are no mayor objections, I will update the copyrights before I leave work today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195923727 From duke at openjdk.org Mon Aug 18 09:46:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 18 Aug 2025 09:46:17 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor In-Reply-To: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: On Mon, 18 Aug 2025 08:30:27 GMT, Francesco Andreuzzi wrote: > We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. > > This change fixes a build failure I'm getting with clang20: [`memset(this, 0, sizeof(*this))`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/resolvedMethodEntry.cpp#L43) is not acceptable unless the class is trivially copyable (`-Wtrivial-copy`). > > Testing: > - [x] tier1 fast-debug > - [x] tier2 fast-debug Test failure seems unrelated: https://github.com/fandreuz/jdk/actions/runs/17035211708/job/48288257455#step:10:1581 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3195934929 From ysuenaga at openjdk.org Mon Aug 18 10:09:21 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 18 Aug 2025 10:09:21 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU Message-ID: `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result: CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c CPU Model and flags from /proc/cpuinfo: model name : AMD Ryzen 3 3300X 4-Core Processor flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor") According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core. After this change, we can see correct number of cores as following on 3300X: CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c CPU Model and flags from /proc/cpuinfo: model name : AMD Ryzen 3 3300X 4-Core Processor ------------- Commit messages: - 8365673: Incorrect number of cores are reported on Ryzen CPU Changes: https://git.openjdk.org/jdk/pull/26819/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365673 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26819.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26819/head:pull/26819 PR: https://git.openjdk.org/jdk/pull/26819 From dfuchs at openjdk.org Mon Aug 18 11:38:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Aug 2025 11:38:14 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com> On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests: java/net/httpclient/CancelledResponse.java java/net/httpclient/whitebox/FlowTestDriver.java The first test failing more frequently. Could you please add /timeout=480 to these two tests as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196281299 From rriggs at openjdk.org Mon Aug 18 13:15:11 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Aug 2025 13:15:11 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196793327 From duke at openjdk.org Mon Aug 18 13:40:21 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:40:21 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v7] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Implement optional error handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/ddab1f0b..8fe49703 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=05-06 Stats: 38 lines in 6 files changed: 29 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 18 13:40:22 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:40:22 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v6] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 14:12:18 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Minor improvements and fixes per @kstefanj suggestions > - use percent_of from globalDefinitions.hpp As per our offline discussion I implemented an optional error handling mechanism to allow users of this framework decide if they care or not. If errors are found we print something like this in the end: [0.569s][info][cpu] === CPU time Statistics ============================================================= [0.569s][info][cpu] WARNING: CPU time sampling reported errors, numbers may be unreliable [0.569s][info][cpu] CPUs [0.569s][info][cpu] s % utilized [0.569s][info][cpu] Process [0.569s][info][cpu] Total 2.2719 100.00 4.0 [0.569s][info][cpu] VM Thread 0.0031 0.14 0.0 [0.569s][info][cpu] Garbage Collection 0.0146 0.64 0.0 [0.569s][info][cpu] GC Threads 0.0141 0.62 0.0 [0.569s][info][cpu] VM Thread 0.0006 0.03 0.0 [0.569s][info][cpu] ===================================================================================== ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3196939663 From duke at openjdk.org Mon Aug 18 13:56:03 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 13:56:03 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v8] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Minor - Minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/8fe49703..9aa28717 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=06-07 Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Mon Aug 18 14:02:48 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 18 Aug 2025 14:02:48 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v9] In-Reply-To: References: Message-ID: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/9aa28717..afbff568 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=07-08 Stats: 36 lines in 2 files changed: 2 ins; 1 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From lkorinth at openjdk.org Mon Aug 18 14:34:12 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 14:34:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs wrote: > Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved. Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197186029 From ayang at openjdk.org Mon Aug 18 14:49:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 18 Aug 2025 14:49:17 GMT Subject: RFR: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier In-Reply-To: References: Message-ID: <8T4cSETVHlwt5qArPqdq_cFX58UG0e5Y2o8Sq0smeH8=.fce336a4-a01e-4521-a810-6e8134675e25@github.com> On Fri, 15 Aug 2025 10:43:55 GMT, Aleksey Shipilev wrote: > I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. > > We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. > > Additional testing: > - [x] Shenandoah + CDS reproducer crashes reliably > - [x] Linux AArch64 server fastdebug, `all` Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26797#pullrequestreview-3128698951 From lmesnik at openjdk.org Mon Aug 18 15:01:12 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Aug 2025 15:01:12 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD Thank you for fixing this! I think the changes are good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3128749995 From liach at openjdk.org Mon Aug 18 15:49:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 18 Aug 2025 15:49:18 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v16] In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> Message-ID: <0IvasB1atRajkt5C286w66VPeNSPBvh1LNzZMIeKv0s=.a6e6f723-27fa-458d-94ae-58b20b57fee2@github.com> On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: > > - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions > - Document why `Preconditions` is not used Looks good in principle; didn't check in the details for compiler code, which I don't necessarily understand. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3128936303 From aph at openjdk.org Mon Aug 18 15:52:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 18 Aug 2025 15:52:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Sat, 16 Aug 2025 06:25:43 GMT, Thomas Stuefe wrote: > Only the hotspot code should write into the code cache, right? A more secure alternative would be then to use `os::address_is_in_vm()`. That compares against the text segment of the libjvm. Prevents accidental misdiagnosis of writes from anywhere (including possibly deliberate ones). True, but is `dladdr(3)` safe to call from a sighandler on BSD? I don't know, but I wouldn't have thought so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2282795996 From shade at openjdk.org Mon Aug 18 15:54:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Aug 2025 15:54:19 GMT Subject: RFR: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 10:43:55 GMT, Aleksey Shipilev wrote: > I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. > > We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. > > Additional testing: > - [x] Shenandoah + CDS reproducer crashes reliably > - [x] Linux AArch64 server fastdebug, `all` Thanks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26797#issuecomment-3197475866 From shade at openjdk.org Mon Aug 18 15:54:20 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Aug 2025 15:54:20 GMT Subject: Integrated: 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 10:43:55 GMT, Aleksey Shipilev wrote: > I am chasing a Shenandoah + CDS bootstrapping problem, where Shenandoah tries to insert the filler at the time when Universe is not yet initialized. It currently fails rather cryptically on attempt to store `null` class. We could really use an assert on accessing various `Klass` definitions in Universe. > > We already do this for `TypeArrayKlass-es`, so this change would cover `fillerArrayKlass` and `objectArrayKlass`. > > Additional testing: > - [x] Shenandoah + CDS reproducer crashes reliably > - [x] Linux AArch64 server fastdebug, `all` This pull request has now been integrated. Changeset: c9ecedd2 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c9ecedd2260c7f0114227aafc7f7f85e7c4c07c5 Stats: 14 lines in 2 files changed: 9 ins; 1 del; 4 mod 8365594: Strengthen Universe klasses asserts to catch bootstrapping errors earlier Reviewed-by: coleenp, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26797 From lkorinth at openjdk.org Mon Aug 18 16:34:21 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 16:34:21 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: References: Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: after suggestion from Daniel ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Mon Aug 18 16:34:22 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 18 Aug 2025 16:34:22 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com> References: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com> Message-ID: On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs wrote: > Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests: > > ``` > java/net/httpclient/CancelledResponse.java > java/net/httpclient/whitebox/FlowTestDriver.java > ``` > > The first test failing more frequently. Could you please add /timeout=480 to these two tests as well? Fixed! Thanks for helping! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197614389 From rriggs at openjdk.org Mon Aug 18 16:38:19 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Aug 2025 16:38:19 GMT Subject: RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v16] In-Reply-To: <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> <2SarqVru4CEEYCp4XaQyfFY74pP6O9C6-vLYK0XbpPc=.d60a5c39-1388-438b-91b1-f55c6aae9fae@github.com> Message-ID: On Fri, 15 Aug 2025 08:39:20 GMT, Volkan Yazici wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: > > - Document tests using `-XX:+VerifyIntrinsicChecks` don't check out-of-range conditions > - Document why `Preconditions` is not used looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3129121186 From aph at openjdk.org Mon Aug 18 16:44:19 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 18 Aug 2025 16:44:19 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Thu, 14 Aug 2025 09:30:29 GMT, Dean Long wrote: > This code is only needed if we forgot a call to os::thread_wx_enable_write(), right? Yes. > Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are. Now, that is a very interesting question. If we do that, then we're potentially into the "whack-a-mole" scenario David Holmes expressed disquiet about, although not in production scenarios. If we don't, then we might miss something and the consequence would be some unnecessary overhead, particularly at startup, and we might not notice. So which do we prefer? > Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag? Good point, I should do something about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2282921913 From dfuchs at openjdk.org Mon Aug 18 16:46:13 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Aug 2025 16:46:13 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > after suggestion from Daniel Thanks! Changes to JNDI / net / httpclient LGTM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197675337 From aph at openjdk.org Mon Aug 18 18:41:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 18 Aug 2025 18:41:55 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> Message-ID: On Thu, 14 Aug 2025 15:55:24 GMT, Fei Gao wrote: > Do you think these numbers are trustworthy? Yes, but it's a microarchitecture-dependent optimization, and it's just a single case. I'm seeing virtually identical times on Apple M1 between these: #define ACTION1 \ "movz x0, #1234; " \ "movk x0, #1234, lsl #16; " \ "movk x0, #1234, lsl #32; " \ "movz x2, #1234; " \ "movk x2, #1234, lsl #16; " \ "movk x2, #1234, lsl #32; " \ "add x1, x2, x0; " \ #define ACTION2 \ "adrp x0, . + 20480 * 4096; " \ "add x0, x0, #48; " \ "adrp x2, . + 20480 * 4096; " \ "add x2, x2, #48; " \ "add x1, x2, x0; " \ 96,642,308 cycles:u # 2.858 GHz 702,095,662 instructions:u # 7.26 insn per cycle 103,939,352 cycles:u # 2.930 GHz 502,095,644 instructions:u # 4.83 insn per cycle All of this stuff is pretty marginal. I can at least accept that `adrp; addp` is shorter therefore better,. But I do not look forward to a blizzard of such changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3189854914 From dlong at openjdk.org Mon Aug 18 21:43:47 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 18 Aug 2025 21:43:47 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> Message-ID: On Mon, 18 Aug 2025 07:57:43 GMT, Manuel H?ssig wrote: >> I'm not entirely sure but I guess it's fine since it's in the same thread. > > Maybe @dean-long can shed some light on this? I'm not an expert on resource areas, but using them in a signal handler seems questionable to me. See also JDK-8349578. I don't even think malloc allocations are safe in a signal handler. But since we are crashing, it probably doesn't matter. In this case, I would either add the ResourceMark (too avoid a "missing ResourceMark" assert), or use an alternative method for printing the name and signature. Note that the hs_err log file should contain the name of the method being compiled, so having it here in this assert is useful but not critical. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2283559577 From dlong at openjdk.org Tue Aug 19 00:15:42 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Aug 2025 00:15:42 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Mon, 18 Aug 2025 15:49:15 GMT, Andrew Haley wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: >> >>> 247: // If we got a SIGBUS because we tried to write into the code >>> 248: // cache, try enabling WXWrite mode. >>> 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { >> >> Only the hotspot code should write into the code cache, right? A more secure alternative would be then to use `os::address_is_in_vm()`. That compares against the text segment of the libjvm. Prevents accidental misdiagnosis of writes from anywhere (including possibly deliberate ones). > >> Only the hotspot code should write into the code cache, right? A more secure alternative would be then to use `os::address_is_in_vm()`. That compares against the text segment of the libjvm. Prevents accidental misdiagnosis of writes from anywhere (including possibly deliberate ones). > > True, but is `dladdr(3)` safe to call from a sighandler on BSD? I don't know, but I wouldn't have thought so. To make it safe to call from a signal handler, we could take a snapshot of the boundaries during startup, something like what os::get_loaded_modules_info() does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2283746055 From dholmes at openjdk.org Tue Aug 19 00:19:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 00:19:13 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown Message-ID: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. Testing: - tiers 1-3 sanity Thanks ------------- Commit messages: - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown Changes: https://git.openjdk.org/jdk/pull/26832/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364735 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26832.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26832/head:pull/26832 PR: https://git.openjdk.org/jdk/pull/26832 From dlong at openjdk.org Tue Aug 19 00:33:43 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Aug 2025 00:33:43 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Mon, 18 Aug 2025 16:41:23 GMT, Andrew Haley wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249: >> >>> 247: // If we got a SIGBUS because we tried to write into the code >>> 248: // cache, try enabling WXWrite mode. >>> 249: if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) { >> >> This code is only needed if we forgot a call to os::thread_wx_enable_write(), right? Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are. >> Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag? > >> This code is only needed if we forgot a call to os::thread_wx_enable_write(), right? > Yes. > >> Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are. > > Now, that is a very interesting question. If we do that, then we're potentially into the "whack-a-mole" scenario David Holmes expressed disquiet about, although not in production scenarios. If we don't, then we might miss something and the consequence would be some unnecessary overhead, particularly at startup, and we might not notice. > > So which do we prefer? > >> Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag? > > Good point, I should do something about that. If we are adding missing calls then we will eventually find them all, so the process should converge. What "whack-a-mole" means to me is repeated code changes that don't converge, which seem more likely to happen if we try to over-optimize and remove calls. I think we have a clearer idea of the "correct" placement now, so hopefully that is less likely to happen. I'm in favor in finding missing calls if that means we avoid the signal handler, but let's get feedback from @dholmes-ora as well. It might be good to document somewhere the rule saying exactly when when os::thread_wx_enable_write() is required (or desired) now, because it wasn't obvious to me at first. That rule for "required" would be something like "if this could be the first write into the code cache". For simplicity it is easier to do it for all writes, but it is tempting to try to optimize and omit it if we know that there other writes must happen first. I think that's when we get near "whack-a-mole" territory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2283762280 From syan at openjdk.org Tue Aug 19 03:34:47 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 19 Aug 2025 03:34:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth wrote: >> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP. > > It is also something that can be changed later, in a follow up fix. Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example. If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2283972732 From vyazici at openjdk.org Tue Aug 19 05:09:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 19 Aug 2025 05:09:52 GMT Subject: Integrated: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: <1re-TiUs1k4Z0hUrkWLaVZhmvPDKGtLwP0O8kuxNw8w=.5c557f62-fc34-4e06-b520-6d8aa55e6aa2@github.com> On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > ... This pull request has now been integrated. Changeset: 655dc516 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b Stats: 434 lines in 23 files changed: 326 ins; 20 del; 88 mod 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics Reviewed-by: rriggs, liach, dfenacci, thartmann, redestad, jrose ------------- PR: https://git.openjdk.org/jdk/pull/25998 From dholmes at openjdk.org Tue Aug 19 05:25:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 05:25:40 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan wrote: >> It is also something that can be changed later, in a follow up fix. > > Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example. > If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable. > It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284090715 From stuefe at openjdk.org Tue Aug 19 05:34:44 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Aug 2025 05:34:44 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: <8p7nn5ImdqZ4Wj-Ca5zw6TqyGD_Xmj0GREl7dkhQCHM=.04538a99-7043-4811-b39c-5b1913523e1c@github.com> On Tue, 19 Aug 2025 00:12:34 GMT, Dean Long wrote: >>> Only the hotspot code should write into the code cache, right? A more secure alternative would be then to use `os::address_is_in_vm()`. That compares against the text segment of the libjvm. Prevents accidental misdiagnosis of writes from anywhere (including possibly deliberate ones). >> >> True, but is `dladdr(3)` safe to call from a sighandler on BSD? I don't know, but I wouldn't have thought so. > > To make it safe to call from a signal handler, we could take a snapshot of the boundaries during startup, something like what os::get_loaded_modules_info() does. Yes, we should do that. As you say, we do this on Windows already. The only slight problem is that dladdr does not give me the end of the last mappings belonging to libjvm.so, only the base address. We also have multiple mappings. I only ever saw them being loaded adjacent to each other, but am not sure if that is guaranteed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284101581 From dholmes at openjdk.org Tue Aug 19 05:49:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 05:49:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > after suggestion from Daniel By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199288818 From lmesnik at openjdk.org Tue Aug 19 05:54:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Aug 2025 05:54:13 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - The oop preservation and exception handling has been fixed. - Test added. - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 - added _ - wong phase - fixed name - simplified after feedback - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/255c0ba8..d9d21af6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=03-04 Stats: 14918 lines in 409 files changed: 8347 ins; 4914 del; 1657 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Tue Aug 19 06:01:42 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Aug 2025 06:01:42 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 17:56:49 GMT, Leonid Mesnik wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1838: >> >>> 1836: { >>> 1837: ThreadInVMfromJava tiv(thread); >>> 1838: state = get_jvmti_thread_state(thread); >> >> The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else. > > Thank you @pchilano and @sspitsyn for finding and explaining the issue. > I need some more time to understand how to better correctly preserve the result oop in post_method_exit before we can starting read jvmti_state. I reviewed the logic and it seems, that `exception_exit` is not needed here. The 'post_method_exit' is called only when method exits normally. The `notice_unwind_due_to_exception`happens if method exit because of exception. I added a regression test that demonstrate the problem. The upcall method is not handled correctly before this fix. Also, it means that result should be always valid and it is always needed to handle result. There is no way to avoid safepoints in this method even MethodExit is not enabled. However, JNIHandle is needed for events only and shouldn't be created until events are enabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2284151989 From dholmes at openjdk.org Tue Aug 19 06:07:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 06:07:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes wrote: >> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example. >> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable. > > DELETED - I confused the timeout with the timeout-factor. New comment below. No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284161138 From stuefe at openjdk.org Tue Aug 19 06:07:48 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Aug 2025 06:07:48 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v3] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 06:34:25 GMT, Johan Sj?len wrote: >> Thomas Stuefe 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 branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use >> - merge master >> - copyrights >> - fix big-endian problem on AIX >> - Update klass.cpp >> - Update metaspace.hpp >> - Update metaspace.hpp >> - Update metaspace.hpp >> - fix rebase error >> - fix mac build >> - ... and 1 more: https://git.openjdk.org/jdk/compare/57210af9...d9696c76 > > src/hotspot/share/memory/metaspace.cpp line 1051: > >> 1049: } >> 1050: >> 1051: bool Metaspace::metadata_is_live(const Metadata* md, FailureHint* hint) { > > Why can't `FailureHint` have an arm called 'no_failure' and just skip it as an out-parameter, having the failure be the return value? Hmm, I played around with that, but it is more awkward to use. - The hint parameter is optional. So if you are not interested in it, you can just call "klass_is_live(k, true)". - With return code and hint squashed into one, it becomes more awkward to combine this call with another and still catch the hint, see shenandoaAssert. Something like if (klass != nullptr && !Metaspace::klass_is_live(klass, false, &hint)) { print hint } becomes if (klass != nullptr && ((Metaspace::FailureHint h = Metaspace::klass_is_live(klass, false)) != Metaspace::FailureHint::none ) { print hint } or forces you to split the expression into multiple lines. > src/hotspot/share/memory/metaspace.hpp line 162: > >> 160: unknown = 0, >> 161: // outside class space/metaspace >> 162: outside, // 1 > > I don't see why we need to write the value of each enum arm, can't our IDEs figure that out for us if necessary :-)? Okay, removed. Originally I had "speaking" hint codes to aid debugging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2284154343 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2284156735 From stuefe at openjdk.org Tue Aug 19 06:07:41 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Aug 2025 06:07:41 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v4] In-Reply-To: References: Message-ID: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Johan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25891/files - new: https://git.openjdk.org/jdk/pull/25891/files/d9696c76..5d99cad6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From syan at openjdk.org Tue Aug 19 06:40:45 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 19 Aug 2025 06:40:45 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes wrote: >> DELETED - I confused the timeout with the timeout-factor. New comment below. > > No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). > > However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma. But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed. The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284273170 From dholmes at openjdk.org Tue Aug 19 06:42:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 06:42:40 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> Message-ID: On Tue, 12 Aug 2025 12:47:46 GMT, Andrew Haley wrote: >> No, it's not explicitly stated in the [guidelines](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md) but it is adopted 'almost everywhere' in the code base. Likewise with reference parameter declarations the '&' attaches to the type. > > Ah, I see. I mistakenly thought the snippet above was a suggestion you were making... I would have have bet (and lost) on this convention being in the guidelines! I even checked the old guidelines. :( Yes we prefer (and actively switch over to) binding the `*` with the type name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284279358 From egahlin at openjdk.org Tue Aug 19 06:45:39 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Aug 2025 06:45:39 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe wrote: > This provides the following new metrics: > - `ProcessSize` event (new, periodic) > - vsize (for analyzing address-space fragmentation issues) > - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat) > - peak RSS > - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing) > - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size) > - `LibcStatistics` (new, periodic) > - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading) > - retained malloc size (super-important for the same reason) > - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`) > - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims) > - RSS before and RSS after > - RSS recovered by this trim > - whether it was an automatic or manual trim > - duration > - `JavaThreadStatistic` > - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.) > - nonJava thread counter (new field) (needed to interprete the os thread counter) > > Notes: > - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it. > > - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue. > > I provided implementations, as far as possible, to Linux, MacOS and Windows. > > Testing: > - ran the new tests manually and as part of GHAs What is the problem with adding RSS metrics to the existing ResidentSetSize event? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3199438538 From dholmes at openjdk.org Tue Aug 19 06:47:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 06:47:39 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Tue, 19 Aug 2025 00:31:10 GMT, Dean Long wrote: >>> This code is only needed if we forgot a call to os::thread_wx_enable_write(), right? >> Yes. >> >>> Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are. >> >> Now, that is a very interesting question. If we do that, then we're potentially into the "whack-a-mole" scenario David Holmes expressed disquiet about, although not in production scenarios. If we don't, then we might miss something and the consequence would be some unnecessary overhead, particularly at startup, and we might not notice. >> >> So which do we prefer? >> >>> Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag? >> >> Good point, I should do something about that. > > If we are adding missing calls then we will eventually find them all, so the process should converge. What "whack-a-mole" means to me is repeated code changes that don't converge, which seem more likely to happen if we try to over-optimize and remove calls. I think we have a clearer idea of the "correct" placement now, so hopefully that is less likely to happen. I'm in favor in finding missing calls if that means we avoid the signal handler, but let's get feedback from @dholmes-ora as well. > It might be good to document somewhere the rule saying exactly when when os::thread_wx_enable_write() is required (or desired) now, because it wasn't obvious to me at first. That rule for "required" would be something like "if this could be the first write into the code cache". For simplicity it is easier to do it for all writes, but it is tempting to try to optimize and omit it if we know that there other writes must happen first. I think that's when we get near "whack-a-mole" territory. I think an assert so we gradually eradicate these fallback cases is a good idea. Just hope the stacktrace shows us where we should have placed the call. But as Dean points out, we need a way to test the fallback ... maybe a gtest? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284288529 From bmaillard at openjdk.org Tue Aug 19 06:56:29 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 19 Aug 2025 06:56:29 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v2] In-Reply-To: References: Message-ID: <8QGzcK3Q85MMfP5JeuUVH4LXx6AkVDD7kO4eeMXfh2s=.328d1bd6-79fc-471f-a45d-b1e7f9aae5db@github.com> > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print_new("return:", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static ... Beno?t Maillard has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/opto/compile.cpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/runtime/sharedRuntime.cpp Co-authored-by: Manuel H?ssig ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/d7641ea7..85ff572e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From bmaillard at openjdk.org Tue Aug 19 06:56:30 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 19 Aug 2025 06:56:30 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v2] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 09:03:29 GMT, Manuel H?ssig wrote: >> Beno?t Maillard has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/hotspot/share/opto/compile.cpp >> >> Co-authored-by: Manuel H?ssig >> - Update src/hotspot/share/runtime/sharedRuntime.cpp >> >> Co-authored-by: Manuel H?ssig > > src/hotspot/share/opto/compile.cpp line 5483: > >> 5481: } >> 5482: >> 5483: #endif > > Suggestion: > > #endif // !PRODUCT > > Nit: This makes it a bit easier to follow the ifdefs. Good catch > src/hotspot/share/runtime/sharedRuntime.cpp line 305: > >> 303: void SharedRuntime::debug_print_value(oopDesc* x) { >> 304: x->print(); >> 305: } > > Can you elaborate why you need an empty print? This is not an empty print, this is `oopDesc::print` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2284300915 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2284299340 From stuefe at openjdk.org Tue Aug 19 07:01:40 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Aug 2025 07:01:40 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 06:43:01 GMT, Erik Gahlin wrote: > What is the problem with adding RSS metrics to the existing ResidentSetSize event? You mean adding the vsize, swap etc fields to ResidentSetSize? I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) I also thought about splitting them up and add one event per value, following the "ResidentSetSize" pattern. So, one event for "VirtualSize", one for "Swap" etc. Apart from not liking the fine granularity, having these fields grouped in one event has multiple advantages. Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3199479458 From bmaillard at openjdk.org Tue Aug 19 07:06:55 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 19 Aug 2025 07:06:55 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: References: Message-ID: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print_new("return:", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static ... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Use print_cr instead of \n ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/85ff572e..e855caec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From duke at openjdk.org Tue Aug 19 07:34:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 19 Aug 2025 07:34:30 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v9] In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. > > Trivial change. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8364819: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26656/files - new: https://git.openjdk.org/jdk/pull/26656/files/b833bf5d..ee4ceadb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26656&range=07-08 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26656/head:pull/26656 PR: https://git.openjdk.org/jdk/pull/26656 From duke at openjdk.org Tue Aug 19 07:34:33 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 19 Aug 2025 07:34:33 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Sun, 17 Aug 2025 21:43:39 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Added atomic loads to getters > > src/hotspot/share/utilities/vmError.cpp line 1345: > >> 1343: // updates except the 1st one. Those can hypothetically happen >> 1344: // if more than one thread times out. >> 1345: // The default memory ordering guarantees visibility to other threads. > > The use of `replace_if_null` is a good alternative here. The comment is a bit wordy. I would suggest a simpler: > > // Only preserve the first thread to time-out this way. The atomic operation ensures > // visibility to the target thread. > > and of course the same comment needs to be in `set_safepoint_timed_out_thread` (or else use a comment block before the two functions to describe both their operations at once). Thanks, I changed the comments as suggested in both methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2284381890 From dholmes at openjdk.org Tue Aug 19 07:42:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 07:42:39 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Sun, 17 Aug 2025 08:27:05 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Tmp I'm not sure I'm really understanding the rules here. Is it the case that the old code would switch between write and exec in a more block structured pattern - changing when needed and then restoring. But the new approach only changes when needed and never restores? If so then I worry that the need to change mode at any given point is a function of the code path to that point, rather than being an obvious property of the code itself. The "healing" allows this to work, but I'm not sure how you would ever explain the placement rules to anyone. ?? For example, I find the placement within the `Assembler` constructor extremely obscure but presumably the code that creates the `Assembler` instance then proceeds to use that instance to write into the code cache? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 352: > 350: > 351: #define JRT_END \ > 352: } Please restore this to match `JRT_BLOCK_END`. The newline here is not needed. src/hotspot/share/runtime/javaThread.hpp line 173: > 171: int64_t _monitor_owner_id; > 172: > 173: public: Please restore the indent of one for the access specifier. src/hotspot/share/utilities/macros.hpp line 560: > 558: #define MACOS_AARCH64_ONLY(x) MACOS_ONLY(AARCH64_ONLY(x)) > 559: #if defined(__APPLE__) && defined(AARCH64) > 560: #define MACOS_W_XOR_X 1 This is just an alias for `MACOS_AARCH64_ONLY` - do we really need it? Especially when, in shared code, we lose the fact that it is AARCH64 only. ------------- PR Review: https://git.openjdk.org/jdk/pull/26562#pullrequestreview-3131068199 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284384450 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284389919 PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2284377891 From duke at openjdk.org Tue Aug 19 07:45:38 2025 From: duke at openjdk.org (duke) Date: Tue, 19 Aug 2025 07:45:38 GMT Subject: RFR: 8359114: [s390x] Add z17 detection code [v4] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 13:10:36 GMT, Manjunath S Matti. wrote: >> Add support to detect the new generation of Z machine (z17). > > Manjunath S Matti. has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Update full name > - Correct the comments for the bits covered in DW[2] and DW[3]. > - Add support to detect the new generation of Z machine (z17). @mmatti-sw Your change (at version 5c31caeaa406663ab26076fba705653ea09ed794) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25718#issuecomment-3199603854 From amitkumar at openjdk.org Tue Aug 19 07:59:45 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Aug 2025 07:59:45 GMT Subject: RFR: 8359114: [s390x] Add z17 detection code [v4] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 13:10:36 GMT, Manjunath S Matti. wrote: >> Add support to detect the new generation of Z machine (z17). > > Manjunath S Matti. has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Update full name > - Correct the comments for the bits covered in DW[2] and DW[3]. > - Add support to detect the new generation of Z machine (z17). s390 and ppc failure are due to infrastructure. MacOS failure (timeout) isn't related to this change. TEST RESULT: Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-26.jdk/Contents/Home/bin/java' timed out (timeout set to 1200000ms, elapsed time including timeout handling was 1305366ms). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25718#issuecomment-3199652197 From duke at openjdk.org Tue Aug 19 07:59:46 2025 From: duke at openjdk.org (Manjunath S Matti.) Date: Tue, 19 Aug 2025 07:59:46 GMT Subject: Integrated: 8359114: [s390x] Add z17 detection code In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 10:48:48 GMT, Manjunath S Matti. wrote: > Add support to detect the new generation of Z machine (z17). This pull request has now been integrated. Changeset: 812434c4 Author: Manjunath Matti Committer: Amit Kumar URL: https://git.openjdk.org/jdk/commit/812434c42072ce4cfc91117a3187df7930500a86 Stats: 21 lines in 2 files changed: 12 ins; 0 del; 9 mod 8359114: [s390x] Add z17 detection code Reviewed-by: amitkumar, aph ------------- PR: https://git.openjdk.org/jdk/pull/25718 From epeter at openjdk.org Tue Aug 19 08:14:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 19 Aug 2025 08:14:46 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3] In-Reply-To: References: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com> Message-ID: <4yjOry6dcewq69ugsBK19mG7ss77qZq6JQtuoiR3XYM=.4dd258c9-67a0-4183-bbc6-cbd3c4addd84@github.com> On Mon, 4 Aug 2025 19:47:32 GMT, Mohamed Issa wrote: >> This seems to be failing in the CI on the build of: linux-x64-debug-nopch >> >> [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'? >> [2025-08-04T19:02:29,373Z] 293 | StubCodeMark mark(this, stub_id); >> [2025-08-04T19:02:29,373Z] | ^~~~~~~ >> [2025-08-04T19:02:29,373Z] | StubId >> [2025-08-04T19:02:29,373Z] > >> This seems to be failing in the CI on the build of: linux-x64-debug-nopch >> >> ``` >> [2025-08-04T19:02:29,373Z] /......../workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp:293:27: error: 'stub_id' was not declared in this scope; did you mean 'StubId'? >> [2025-08-04T19:02:29,373Z] 293 | StubCodeMark mark(this, stub_id); >> [2025-08-04T19:02:29,373Z] | ^~~~~~~ >> [2025-08-04T19:02:29,373Z] | StubId >> [2025-08-04T19:02:29,373Z] >> ``` > > Thanks for notification. It looks like an incorrect type declaration. I'll submit a fix. @missa-prime I was on vacation for a few weeks. Feel free to ping others when I don't respond ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3199712429 From sjohanss at openjdk.org Tue Aug 19 08:19:42 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 19 Aug 2025 08:19:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v9] In-Reply-To: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> References: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com> Message-ID: On Mon, 18 Aug 2025 14:02:48 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Just some minor things that you can fix before integrating. Otherwise I think this looks good. src/hotspot/share/gc/shared/collectedHeap.cpp line 59: > 57: #include "runtime/threadSMR.hpp" > 58: #include "runtime/vmThread.hpp" > 59: #include "services/cpuTimeUsage.hpp" Can be removed now. src/hotspot/share/gc/shared/collectedHeap.hpp line 434: > 432: void print_relative_to_gc(GCWhen::Type when) const; > 433: > 434: void log_cpu_time() const; This has moved to `Universe` and can be removed. ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3131175838 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284454451 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284450710 From aph at openjdk.org Tue Aug 19 08:21:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 08:21:55 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 19 Aug 2025 07:39:57 GMT, David Holmes wrote: > I'm not sure I'm really understanding the rules here. Is it the case that the old code would switch between write and exec in a more block structured pattern - changing when needed The old code doesn't change when needed but at every VM transition whether needed or not. But only 1% of VM transitions need to change. > and then restoring. But the new approach only changes when needed and never restores? More or less, yes. (Although obviously we have to reset the mode when returning from VM mode.) > If so then I worry that the need to change mode at any given point is a function of the code path to that point, rather than being an obvious property of the code itself. We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? > The "healing" allows this to work, To be clear: healing never happens in testing. > but I'm not sure how you would ever explain the placement rules to anyone. ?? For example, I find the placement within the `Assembler` constructor extremely obscure but presumably the code that creates the `Assembler` instance then proceeds to use that instance to write into the code cache? Yes, exactly. We create Assembler instances whenever we need to generate code, and we don't share those instances, so the constructor is sweet spot to change mode. We don't keep Assembler instances hanging around. We could argue that this is temporal coupling, a code smell, but WX mode is a temporal property, so to a large extent that can't be helped.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3199733982 From duke at openjdk.org Tue Aug 19 08:25:14 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 19 Aug 2025 08:25:14 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v27] In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 10:51:12 GMT, Stefan Karlsson wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Fixed whitespace error > > src/hotspot/os/windows/os_windows.cpp line 870: > >> 868: } else { >> 869: DWORD errcode = ::GetLastError(); >> 870: log_debug(os)("available_memory() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); > > I think this should be an assert. Or is there a reason why that would be bad? No, there is no reason, let's catch this asap. > src/hotspot/os/windows/os_windows.cpp line 884: > >> 882: } else { >> 883: DWORD errcode = ::GetLastError(); >> 884: log_debug(os)("total_swap_space() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); > > assert? Addressed. > src/hotspot/os/windows/os_windows.cpp line 898: > >> 896: } else { >> 897: DWORD errcode = ::GetLastError(); >> 898: log_debug(os)("free_swap_space() failed to GlobalMemoryStatusEx: GetLastError->%lu.", errcode); > > assert? Addressed. > src/hotspot/os/windows/os_windows.cpp line 4168: > >> 4166: // also returns dwAvailPhys (free physical memory bytes), dwTotalVirtual, dwAvailVirtual, >> 4167: // dwMemoryLoad (% of memory in use) >> 4168: BOOL res = GlobalMemoryStatusEx(&ms); > > Unused local variable? Should there be an assert here? As per discussion above `GlobalMemoryStatusEx` seems to never fail. Let's be consistent and add the assert here as well. > src/hotspot/share/gc/z/zLargePages.cpp line 34: > >> 32: pd_initialize(); >> 33: >> 34: size_t memory = os::physical_memory(); > > ZGC coding style for locals: > Suggestion: > > const size_t memory = os::physical_memory(); Addressed. > src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 417: > >> 415: return os::Linux::physical_memory(); >> 416: #else >> 417: return static_cast(os::physical_memory()); > > The two paths are inconsistent. This casts the return but the lines above doesn't cast the return value of `os::Linux::physical_memory();`. Addressed. > src/hotspot/share/utilities/globalDefinitions.hpp line 1366: > >> 1364: >> 1365: // Dummy placeholder for use of [[nodiscard]] >> 1366: #define ATTRIBUTE_NODISCARD > > Should this be placed near the other listed ATTRIBUTES in this file? Okay, moved it up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284508387 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284508133 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284508241 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284507883 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284507573 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284507410 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2284507033 From duke at openjdk.org Tue Aug 19 08:25:13 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 19 Aug 2025 08:25:13 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v28] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/f62ed1d3..a1f14803 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=26-27 Stats: 17 lines in 4 files changed: 7 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From mli at openjdk.org Tue Aug 19 08:29:13 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Aug 2025 08:29:13 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 Message-ID: Hi, Can you help to review this patch? Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) Thanks! ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/26838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365206 Stats: 230 lines in 6 files changed: 203 ins; 21 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From duke at openjdk.org Tue Aug 19 08:42:15 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 08:42:15 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove unused ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/afbff568..79a3323a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From lkorinth at openjdk.org Tue Aug 19 09:02:36 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 19 Aug 2025 09:02:36 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes wrote: > By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though. Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199869795 From kbarrett at openjdk.org Tue Aug 19 09:03:37 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Aug 2025 09:03:37 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 19 Aug 2025 00:11:38 GMT, David Holmes wrote: > `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. > > Testing: > - tiers 1-3 sanity > > Thanks src/hotspot/share/utilities/ostream.cpp line 1001: > 999: xtty = nullptr; > 1000: OrderAccess::fence(); // force visibility to concurrently executing threads > 1001: delete ds; There are lots of places in the VM that don't even try to clean up on VM exit. I think we even talk about non-cleanup on exit in the style guide. So why are we doing this cleanup, in such a potentially sensitive/fragile area? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26832#discussion_r2284607261 From lkorinth at openjdk.org Tue Aug 19 09:19:45 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 19 Aug 2025 09:19:45 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> References: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> Message-ID: On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan wrote: >> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). >> >> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma. > > But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed. > > The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1 I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284650722 From amitkumar at openjdk.org Tue Aug 19 09:25:39 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Aug 2025 09:25:39 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 15 Aug 2025 11:43:10 GMT, Ruben wrote: >> Ruben has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > @TheRealMDoerr, @RealFYang, @offamitkumar, > Could you run tier1-tier3 tests on your platforms for this patch please? @ruben-arm I don't see any test failure on s390x in tier1. Code change looks good to me. CC: @RealLucy ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3199951122 From fgao at openjdk.org Tue Aug 19 10:44:12 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 19 Aug 2025 10:44:12 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD [v2] In-Reply-To: References: Message-ID: > If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. Fei Gao 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: - Disable reachability-based optimization during AOT code dumping - Merge branch 'master' into replace-mov-with-adrp - 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26653/files - new: https://git.openjdk.org/jdk/pull/26653/files/3ca70c87..3540e45d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26653&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26653&range=00-01 Stats: 15535 lines in 447 files changed: 8407 ins; 5296 del; 1832 mod Patch: https://git.openjdk.org/jdk/pull/26653.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26653/head:pull/26653 PR: https://git.openjdk.org/jdk/pull/26653 From fgao at openjdk.org Tue Aug 19 10:50:40 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 19 Aug 2025 10:50:40 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> Message-ID: On Thu, 14 Aug 2025 20:58:12 GMT, Andrew Haley wrote: > All of this stuff is pretty marginal. I can at least accept that `adrp; addp` is shorter therefore better,. > > But I do not look forward to a blizzard of such changes. @theRealAph That does make sense. Thanks for running the experimental tests ? much appreciated! I've disabled this reachability-based optimization during AOT code dumping in the new commit as suggested by @adinn . Could you please take a look? Thanks again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3200228046 From ayang at openjdk.org Tue Aug 19 10:56:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 10:56:44 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v9] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 19 Aug 2025 07:34:30 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments > Arguably, as stated much much earlier, we don't need any explicit memory ordering here in practice as the signal implementation must provide its own ordering guarantees to actually function - and there is no way a compiler would ever re-order the store with the pthread_kill call! I see. I think I misunderstood the problem a bit. Hopefully, I get it this time -- the non-inline function-call should prevent compiler-reordering and the system-call inside `pthread_kill` should prevent CPU-reordering. The only thing needed here is to ensure the store-to-the-shared-var becomes visible on other CPUs, e.g. not hidden inside store-buffer. Conceptually, `pthread_kill` performs a "store" as well, so the invariant is that the two stores should be ordered. x64 uses FIFO on store-buffer, so everything is fine. OTOH, aarch64 needs some amending to enforce FIFO for visibility of these two stores. `Atomic::replace_if_null` should be enough to provide the ordering. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3131772906 From ayang at openjdk.org Tue Aug 19 11:35:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 11:35:39 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused src/hotspot/share/gc/shared/collectedHeap.cpp line 625: > 623: ClassLoaderDataGraph::print_on(&ls_trace); > 624: } > 625: } I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap. src/hotspot/share/services/cpuTimeUsage.cpp line 43: > 41: public: > 42: virtual void do_thread(Thread* thread) { > 43: jlong cpu_time = os::thread_cpu_time(thread); I guess a wrapper for `thread_cpu_time` can be created to group error-handling logic together, for all uses in this file. jlong thread_cpu_time_or_zero(thread) { jlong cpu_time = os::.. if (cpu_time == -1) { // mark-error return 0; } return cpu_time; } src/hotspot/share/services/cpuTimeUsage.hpp line 47: > 45: static jlong gc_threads(); > 46: static jlong vm_thread(); > 47: static jlong stringdedup(); I feel the API surface contains some redundancy. For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284933253 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284962585 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284952784 From mdoerr at openjdk.org Tue Aug 19 11:45:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 19 Aug 2025 11:45:38 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Tier 1 has passed on linux ppc64le. Nice cleanup! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3131937874 From mdoerr at openjdk.org Tue Aug 19 12:27:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 19 Aug 2025 12:27:38 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Tue, 5 Aug 2025 14:53:30 GMT, Richard Reingruber wrote: > Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). > > Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. > > Details: > > It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). > > There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. > > It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. LGTM. Thanks for the fix! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26643#pullrequestreview-3132093177 From aph at openjdk.org Tue Aug 19 13:17:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 13:17:41 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 10:44:12 GMT, Fei Gao wrote: >> If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. >> >> In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: >> >> 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. >> 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. >> >> The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. > > Fei Gao 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: > > - Disable reachability-based optimization during AOT code dumping > - Merge branch 'master' into replace-mov-with-adrp > - 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD > > If the relocation or target address is guaranteed to reside within > the CodeCache, we can safely replace a `movz + movk + movk` > sequence with a more compact and efficient `adrp + add` > instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this > replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within > the CodeCache and the necessary patching logic is provided in > `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) > and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` > and `is_adrp_reachable()` to ensure this optimization is applied > safely and selectively. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2272: > 2270: > 2271: #ifdef ASSERT > 2272: bool MacroAssembler::unqualified_type(relocInfo::relocType rtype) { Suggestion: bool MacroAssembler::is_unqualified_type(relocInfo::relocType rtype) { src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2302: > 2300: add(r, r, offset); > 2301: } else { > 2302: #ifdef ASSERT You don't need this #ifdef ASSERT src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5799: > 5797: } > 5798: > 5799: bool MacroAssembler::is_adrp_reachable(const address target) { assert here that code cache is 4k-aligned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26653#discussion_r2285243434 PR Review Comment: https://git.openjdk.org/jdk/pull/26653#discussion_r2285230901 PR Review Comment: https://git.openjdk.org/jdk/pull/26653#discussion_r2285238274 From aph at openjdk.org Tue Aug 19 13:22:46 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 13:22:46 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 10:44:12 GMT, Fei Gao wrote: >> If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. >> >> In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: >> >> 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. >> 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. >> >> The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. > > Fei Gao 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: > > - Disable reachability-based optimization during AOT code dumping > - Merge branch 'master' into replace-mov-with-adrp > - 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD > > If the relocation or target address is guaranteed to reside within > the CodeCache, we can safely replace a `movz + movk + movk` > sequence with a more compact and efficient `adrp + add` > instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this > replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within > the CodeCache and the necessary patching logic is provided in > `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) > and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` > and `is_adrp_reachable()` to ensure this optimization is applied > safely and selectively. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1511: > 1509: address read_polling_page(Register r, relocInfo::relocType rtype); > 1510: void get_polling_page(Register dest, relocInfo::relocType rtype); > 1511: static bool should_relocate_to_codecache(relocInfo::relocType rtype); Suggestion: static bool must_relocate_to_codecache(relocInfo::relocType rtype); I think this is true for every "should_" in this patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26653#discussion_r2285255870 From aph at openjdk.org Tue Aug 19 13:25:45 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 13:25:45 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 10:44:12 GMT, Fei Gao wrote: >> If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. >> >> In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: >> >> 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. >> 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. >> >> The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. > > Fei Gao 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: > > - Disable reachability-based optimization during AOT code dumping > - Merge branch 'master' into replace-mov-with-adrp > - 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD > > If the relocation or target address is guaranteed to reside within > the CodeCache, we can safely replace a `movz + movk + movk` > sequence with a more compact and efficient `adrp + add` > instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this > replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within > the CodeCache and the necessary patching logic is provided in > `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) > and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` > and `is_adrp_reachable()` to ensure this optimization is applied > safely and selectively. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2271: > 2269: } > 2270: > 2271: #ifdef ASSERT This method needs a comment explaining what it means. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26653#discussion_r2285263696 From duke at openjdk.org Tue Aug 19 13:42:19 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 13:42:19 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: - Address review comments Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd - Refine code generation for mem2reg_volatile The patch is contributed by @theRealAph. Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26748/files - new: https://git.openjdk.org/jdk/pull/26748/files/287c566b..8fa2c1c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26748&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26748&range=00-01 Stats: 58 lines in 4 files changed: 15 ins; 31 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26748/head:pull/26748 PR: https://git.openjdk.org/jdk/pull/26748 From duke at openjdk.org Tue Aug 19 13:44:40 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 13:44:40 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads In-Reply-To: References: Message-ID: <2eK7OB-jaAIGOn6L9KvQzDgtFQJgVMRMWynlA79W52Q=.7d89d3d1-f49b-416f-95ca-d03b843f9e0c@github.com> On Tue, 12 Aug 2025 14:59:40 GMT, Samuel Chee wrote: > Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. > > This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. > However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. > > The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > This excludes floats and doubles, as they do not have equivalent load-acquire instructions. Have just addressed everything, am currently running jcstress to double check it's still all good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3200819394 From cnorrbin at openjdk.org Tue Aug 19 13:53:39 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 19 Aug 2025 13:53:39 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v4] In-Reply-To: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> References: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> Message-ID: On Tue, 19 Aug 2025 06:07:41 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Johan Looks good overall! I only had a couple of minor questions and comments, noted inline. :-) src/hotspot/share/gc/shared/collectedHeap.cpp line 281: > 279: } > 280: > 281: k =mark.klass_without_asserts(); Nit: missing space after `=` src/hotspot/share/oops/metadata.hpp line 49: > 47: static constexpr uint32_t common_prefix_mask = BUILD_32(0xFFFF, 0); > 48: static constexpr uint32_t instance_klass_token = BUILD_32(0x3E7A, 0x100); > 49: static constexpr uint32_t array_klass_token = BUILD_32(0x3E7A, 0x101); Nit / question: Any particular reason we're building the tokens with `BUILD_32(high, low)` instead of writing out the full literal (e.g. `0x3E7A0100`)? Is it mainly for readability or are there other considerations? ------------- PR Review: https://git.openjdk.org/jdk/pull/25891#pullrequestreview-3132360216 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2285283890 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2285300666 From aph at openjdk.org Tue Aug 19 13:56:46 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 13:56:46 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 13:42:19 GMT, Samuel Chee wrote: >> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. >> >> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. >> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. >> >> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > > Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd > - Refine code generation for mem2reg_volatile > > The patch is contributed by @theRealAph. > > Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1410: > 1408: // be atomic - which includes unaligned ones - use the generic DMB + LD sequence, as LDAR might > 1409: // fault for unaligned accesses. > 1410: if (AlwaysAtomicAccesses) { I'm not sure this makes sense. Misaligned accesses can't ever be atomic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2285353492 From aturbanov at openjdk.org Tue Aug 19 14:22:40 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 19 Aug 2025 14:22:40 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:22:59 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! test/hotspot/jtreg/compiler/intrinsics/float16/Binary16ConversionNaN_2.java line 144: > 142: > 143: private static float testRoundTrip(float f) { > 144: short s = Float.floatToFloat16(f); Suggestion: short s = Float.floatToFloat16(f); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2285438166 From aph at openjdk.org Tue Aug 19 14:26:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 14:26:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v5] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Reviewer comments - Reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/ed6b5023..dbf67369 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=03-04 Stats: 49 lines in 11 files changed: 30 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From duke at openjdk.org Tue Aug 19 14:30:48 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 14:30:48 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 11:18:48 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused > > src/hotspot/share/gc/shared/collectedHeap.cpp line 625: > >> 623: ClassLoaderDataGraph::print_on(&ls_trace); >> 624: } >> 625: } > > I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap. The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks. > this calls back to Universe It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue. > CLDG printing is not necessarily tired to heap That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285459470 From mhaessig at openjdk.org Tue Aug 19 14:36:05 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 19 Aug 2025 14:36:05 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v11] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with two additional commits since the last revision: - Print timeout properly - Use static buffer for method name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/80ddb0ad..9926971f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=09-10 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Tue Aug 19 14:36:05 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 19 Aug 2025 14:36:05 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v8] In-Reply-To: References: <6-poNTHw7LVDOcv91ZprJQFTb0nAJbAtxxMwp8vtPTg=.0a80771c-c23d-4f99-ab2e-c6392798d328@github.com> Message-ID: On Mon, 18 Aug 2025 21:41:11 GMT, Dean Long wrote: >> Maybe @dean-long can shed some light on this? > > I'm not an expert on resource areas, but using them in a signal handler seems questionable to me. See also JDK-8349578. I don't even think malloc allocations are safe in a signal handler. But since we are crashing, it probably doesn't matter. In this case, I would either add the ResourceMark (too avoid a "missing ResourceMark" assert), or use an alternative method for printing the name and signature. Note that the hs_err log file should contain the name of the method being compiled, so having it here in this assert is useful but not critical. I just realized that `name_and_sig_as_C_string()` can also take a buffer and size as argument and will use that with a static buffer instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2285474664 From aph at openjdk.org Tue Aug 19 14:37:43 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Aug 2025 14:37:43 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: <8p7nn5ImdqZ4Wj-Ca5zw6TqyGD_Xmj0GREl7dkhQCHM=.04538a99-7043-4811-b39c-5b1913523e1c@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> <8p7nn5ImdqZ4Wj-Ca5zw6TqyGD_Xmj0GREl7dkhQCHM=.04538a99-7043-4811-b39c-5b1913523e1c@github.com> Message-ID: On Tue, 19 Aug 2025 05:31:52 GMT, Thomas Stuefe wrote: > Yes, we should do that. As you say, we do this on Windows already. Where is that Windows code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2285481024 From duke at openjdk.org Tue Aug 19 14:41:39 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 14:41:39 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 13:54:07 GMT, Andrew Haley wrote: >> Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address review comments >> >> Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd >> - Refine code generation for mem2reg_volatile >> >> The patch is contributed by @theRealAph. >> >> Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 > > src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1410: > >> 1408: // be atomic - which includes unaligned ones - use the generic DMB + LD sequence, as LDAR might >> 1409: // fault for unaligned accesses. >> 1410: if (AlwaysAtomicAccesses) { > > I'm not sure this makes sense. Misaligned accesses can't ever be atomic. Yes, so the flag experimental flag `AlwaysAtomicAccesses` will attempt to force to make all accesses atomic - even misaligned ones which causes a memory access error if using LDAR. Hence we resort to the old code sequence when this flag is active. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2285491168 From duke at openjdk.org Tue Aug 19 14:48:43 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 14:48:43 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 11:27:53 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused > > src/hotspot/share/services/cpuTimeUsage.hpp line 47: > >> 45: static jlong gc_threads(); >> 46: static jlong vm_thread(); >> 47: static jlong stringdedup(); > > I feel the API surface contains some redundancy. > > For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. > > The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. If you look at e.g. `WeakProcessor::CountingClosure` the following is defined size_t dead() const { return _old_dead + _new_dead; } size_t new_dead() const { return _new_dead; } size_t total() const { return dead() + _live; } so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. `statistics()` is a less important convenience method that can be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285510749 From adinn at openjdk.org Tue Aug 19 15:02:41 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 19 Aug 2025 15:02:41 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <3saG-GQybxPQeykQ-Dqu-HvcXpq5q4N51ay93V3kfPU=.f40f508e-1ec1-41a4-8afa-42180471b49c@github.com> Message-ID: On Tue, 19 Aug 2025 10:46:15 GMT, Fei Gao wrote: >>> Do you think these numbers are trustworthy? >> >> Yes, but it's a microarchitecture-dependent optimization, and it's just a single case. I'm seeing virtually identical times on Apple M1 between these: >> >> >> #define ACTION1 \ >> "movz x0, #1234; " \ >> "movk x0, #1234, lsl #16; " \ >> "movk x0, #1234, lsl #32; " \ >> "movz x2, #1234; " \ >> "movk x2, #1234, lsl #16; " \ >> "movk x2, #1234, lsl #32; " \ >> "add x1, x2, x0; " \ >> >> #define ACTION2 \ >> "adrp x0, . + 20480 * 4096; " \ >> "add x0, x0, #48; " \ >> "adrp x2, . + 20480 * 4096; " \ >> "add x2, x2, #48; " \ >> "add x1, x2, x0; " \ >> >> >> >> >> 96,642,308 cycles:u # 2.858 GHz >> 702,095,662 instructions:u # 7.26 insn per cycle >> >> 103,939,352 cycles:u # 2.930 GHz >> 502,095,644 instructions:u # 4.83 insn per cycle >> >> >> >> All of this stuff is pretty marginal. I can at least accept that `adrp; addp` is shorter therefore better,. >> >> But I do not look forward to a blizzard of such changes. > >> All of this stuff is pretty marginal. I can at least accept that `adrp; addp` is shorter therefore better,. >> >> But I do not look forward to a blizzard of such changes. > > @theRealAph That does make sense. Thanks for running the experimental tests ? much appreciated! > > I've disabled this reachability-based optimization during AOT code dumping in the new commit as suggested by @adinn . > > Could you please take a look? Thanks again. @fg1417 How does this code relate to the far_jump and far_call code? Is there an overlap in functionality here that we need to simplify? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3201115396 From ayang at openjdk.org Tue Aug 19 15:03:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 19 Aug 2025 15:03:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:27:59 GMT, Jonas Norlinder wrote: > now we finally have a specific method that is called for GC activites... Then, it should be in `Universe::before_exit`, not inside heap. >> src/hotspot/share/services/cpuTimeUsage.hpp line 47: >> >>> 45: static jlong gc_threads(); >>> 46: static jlong vm_thread(); >>> 47: static jlong stringdedup(); >> >> I feel the API surface contains some redundancy. >> >> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one. >> >> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable. > > The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. > > If you look at e.g. `WeakProcessor::CountingClosure` the following is defined > > size_t dead() const { return _old_dead + _new_dead; } > size_t new_dead() const { return _new_dead; } > size_t total() const { return dead() + _live; } > > > so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. > > `statistics()` is a less important convenience method that can be removed. I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285544932 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285551132 From duke at openjdk.org Tue Aug 19 15:06:56 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 15:06:56 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE Message-ID: According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: > Atomically sets the value of a variable to the newValue with the > memory semantics of setVolatile if the variable's current value, > referred to as the witness value, == the expectedValue, as accessed > with the memory semantics of getVolatile. Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). The unused cmpxchgw is removed. [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) ------------- Commit messages: - 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE Changes: https://git.openjdk.org/jdk/pull/26845/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26845&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365799 Stats: 113 lines in 3 files changed: 67 ins; 40 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26845/head:pull/26845 PR: https://git.openjdk.org/jdk/pull/26845 From duke at openjdk.org Tue Aug 19 15:06:56 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 15:06:56 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:59:42 GMT, Samuel Chee wrote: > According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: > >> Atomically sets the value of a variable to the newValue with the >> memory semantics of setVolatile if the variable's current value, >> referred to as the witness value, == the expectedValue, as accessed >> with the memory semantics of getVolatile. > > Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. > > Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). > > The unused cmpxchgw is removed. > > [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) Tested and passes jcstress. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3201126186 From duke at openjdk.org Tue Aug 19 15:10:40 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 15:10:40 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:59:42 GMT, Samuel Chee wrote: > According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: > >> Atomically sets the value of a variable to the newValue with the >> memory semantics of setVolatile if the variable's current value, >> referred to as the witness value, == the expectedValue, as accessed >> with the memory semantics of getVolatile. > > Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. > > Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). > > The unused cmpxchgw is removed. > > [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) Ok looks like there are some very recent changes to the relevant files since I last touched it. Need to fix my merge-conflict and have a look at whats changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3201148632 From kvn at openjdk.org Tue Aug 19 15:48:39 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 19 Aug 2025 15:48:39 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> References: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> Message-ID: On Tue, 19 Aug 2025 07:06:55 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time a... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Use print_cr instead of \n src/hotspot/share/opto/compile.cpp line 5411: > 5409: } > 5410: > 5411: Node* Compile::make_debug_print_call(const char* str, address call_addr, PhaseGVN* gvn, I think it should be in graphKit.cpp similar to `GraphKit::make_runtime_call()` src/hotspot/share/runtime/sharedRuntime.hpp line 642: > 640: static void print_ic_miss_histogram(); > 641: > 642: // Runtime methods for printf-style debug nodes All these methods should be under #ifdef COMPILER2` since they used only by C2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2285667276 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2285670974 From duke at openjdk.org Tue Aug 19 15:56:39 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 15:56:39 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:57:51 GMT, Albert Mingkun Yang wrote: >> The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks. >> >>> this calls back to Universe >> >> It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue. >> >> > CLDG printing is not necessarily tired to heap >> >> That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag? > >> now we finally have a specific method that is called for GC activites... > > Then, it should be in `Universe::before_exit`, not inside heap. FWIW; `Universe::print_on` do actually call collected heap as well. void Universe::print_on(outputStream* st) { GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread. st->print_cr("Heap"); StreamIndentor si(st, 1); heap()->print_heap_on(st); MetaspaceUtils::print_on(st); } I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285690897 From duke at openjdk.org Tue Aug 19 15:58:52 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 15:58:52 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2] In-Reply-To: References: Message-ID: > According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: > >> Atomically sets the value of a variable to the newValue with the >> memory semantics of setVolatile if the variable's current value, >> referred to as the witness value, == the expectedValue, as accessed >> with the memory semantics of getVolatile. > > Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. > > Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). > > The unused cmpxchgw is removed. > > [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) Samuel Chee has updated the pull request incrementally with one additional commit since the last revision: Merge master fix Change-Id: I74d44f711de208395bce47595fecd801564bcb54 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26845/files - new: https://git.openjdk.org/jdk/pull/26845/files/4a95340c..e6e46d16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26845&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26845&range=00-01 Stats: 68 lines in 1 file changed: 0 ins; 65 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26845/head:pull/26845 PR: https://git.openjdk.org/jdk/pull/26845 From duke at openjdk.org Tue Aug 19 15:58:53 2025 From: duke at openjdk.org (Samuel Chee) Date: Tue, 19 Aug 2025 15:58:53 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:59:42 GMT, Samuel Chee wrote: > According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: > >> Atomically sets the value of a variable to the newValue with the >> memory semantics of setVolatile if the variable's current value, >> referred to as the witness value, == the expectedValue, as accessed >> with the memory semantics of getVolatile. > > Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. > > Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). > > The unused cmpxchgw is removed. > > [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) Have fixed :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3201320979 From duke at openjdk.org Tue Aug 19 16:03:42 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 19 Aug 2025 16:03:42 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: <2wSybZnJX_B_94UbbiPj_gMeKGqoFeyhXk8AAtiM9lQ=.6ae7d021-fd81-425d-b47a-bf767ad7b4dd@github.com> On Tue, 19 Aug 2025 15:00:15 GMT, Albert Mingkun Yang wrote: >> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it. >> >> If you look at e.g. `WeakProcessor::CountingClosure` the following is defined >> >> size_t dead() const { return _old_dead + _new_dead; } >> size_t new_dead() const { return _new_dead; } >> size_t total() const { return dead() + _live; } >> >> >> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it. >> >> `statistics()` is a less important convenience method that can be removed. > > I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV. I would remove `CPUTimeUsage::GC::statistics()` as I would prefer having coherent types between classes in the namespace and since using structs over of classes defeats some of the utility of putting everything into a namespace. For instance, it makes little sense to define a struct for `Runtime` which only include one component currently and it would be less than ideal to return `jlong` for some classes and custom structs for others if we only have to pick one of these approaches. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285707652 From dlong at openjdk.org Tue Aug 19 16:37:39 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Aug 2025 16:37:39 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v11] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:36:05 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with two additional commits since the last revision: > > - Print timeout properly > - Use static buffer for method name src/hotspot/share/utilities/globalDefinitions.hpp line 154: > 152: > 153: // Format pointers and padded integral values which change size between 32- and 64-bit. > 154: #define INTX_FORMAT "%" PRIdPTR Do we really need to add this back? This was removed by JDK-8346990. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2285785156 From dlong at openjdk.org Tue Aug 19 16:40:41 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Aug 2025 16:40:41 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v11] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:36:05 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with two additional commits since the last revision: > > - Print timeout properly > - Use static buffer for method name src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 47: > 45: char method_name_buf[SIZE]; > 46: task->method()->name_and_sig_as_C_string(method_name_buf, SIZE); > 47: assert(false, "compile task %d (%s) timed out after " INTX_FORMAT " ms", Can we use %zd here? INTX_FORMAT was removed in JDK-8346990. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2285791418 From kvn at openjdk.org Tue Aug 19 16:41:38 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 19 Aug 2025 16:41:38 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: On Thu, 7 Aug 2025 11:43:33 GMT, Fei Gao wrote: > So, the reachability method needs to return false if `AOTCodeCache::is_on_for_dump() returns true. This may be not enough. I just fixed the issue in premain for aarch64 after https://bugs.openjdk.org/browse/JDK-8358329 : https://github.com/openjdk/leyden/commit/2c69aa27ee88cca0c85ab275b4b5f24035ecf4d6 The issue was that `ICache::invalidate_range()` was called only for part of AOTed stub code based `static_call_stub_size()` which could be smaller in production run. In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3201453302 From kvn at openjdk.org Tue Aug 19 16:41:38 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 19 Aug 2025 16:41:38 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> Message-ID: <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> On Tue, 19 Aug 2025 16:37:47 GMT, Vladimir Kozlov wrote: > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. Or code should be the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3201458373 From mhaessig at openjdk.org Tue Aug 19 17:02:41 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 19 Aug 2025 17:02:41 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v11] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 16:34:59 GMT, Dean Long wrote: >> Manuel H?ssig has updated the pull request incrementally with two additional commits since the last revision: >> >> - Print timeout properly >> - Use static buffer for method name > > src/hotspot/share/utilities/globalDefinitions.hpp line 154: > >> 152: >> 153: // Format pointers and padded integral values which change size between 32- and 64-bit. >> 154: #define INTX_FORMAT "%" PRIdPTR > > Do we really need to add this back? This was removed by JDK-8346990. I was not aware of that. I will remove it and use `%zd`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2285834958 From mhaessig at openjdk.org Tue Aug 19 17:31:58 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 19 Aug 2025 17:31:58 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v12] In-Reply-To: References: Message-ID: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Print with %zd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26023/files - new: https://git.openjdk.org/jdk/pull/26023/files/9926971f..64738e25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26023&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023 PR: https://git.openjdk.org/jdk/pull/26023 From mhaessig at openjdk.org Tue Aug 19 17:31:58 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 19 Aug 2025 17:31:58 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v11] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 16:38:00 GMT, Dean Long wrote: >> Manuel H?ssig has updated the pull request incrementally with two additional commits since the last revision: >> >> - Print timeout properly >> - Use static buffer for method name > > src/hotspot/os/linux/compilerThreadTimeout_linux.cpp line 47: > >> 45: char method_name_buf[SIZE]; >> 46: task->method()->name_and_sig_as_C_string(method_name_buf, SIZE); >> 47: assert(false, "compile task %d (%s) timed out after " INTX_FORMAT " ms", > > Can we use %zd here? INTX_FORMAT was removed in JDK-8346990. Yes, 64738e2 fixes this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2285892747 From egahlin at openjdk.org Tue Aug 19 19:02:36 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Aug 2025 19:02:36 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 06:58:58 GMT, Thomas Stuefe wrote: > You mean adding the vsize, swap etc fields to ResidentSetSize? > > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) I was thinking something like this: When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal. These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. > It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance). We should not sacrifice the design unless the overhead is significant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3201882624 From coleenp at openjdk.org Tue Aug 19 19:06:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Aug 2025 19:06:40 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v3] In-Reply-To: <7jnsZfWEq8fF6vmr9czvFxA44uSgViPcJO6s6WhQS_Q=.d273176d-fca6-4088-9b70-de1056763010@github.com> References: <7jnsZfWEq8fF6vmr9czvFxA44uSgViPcJO6s6WhQS_Q=.d273176d-fca6-4088-9b70-de1056763010@github.com> Message-ID: On Wed, 13 Aug 2025 22:02:34 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - use special marker for fp in freeze fast path too > - use special marker value for unused fp src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 34: > 32: > 33: // fp value used for frozen stub/native frame > 34: static intptr_t* const UNUSED_FP = reinterpret_cast(UCONST64(0xC0C0C0C0DEADBAAD)); In globalDefinitions.hpp there's a block of special constants for debugging. Can you add this constant to that with a generic name so that it might be reusable for other stack related addresses. Or just use badAddressVal, which is -2. I don't think it's going to crash a lot so you'd need something very recognizable. Just something that would crash. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2286097396 From coleenp at openjdk.org Tue Aug 19 19:47:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Aug 2025 19:47:38 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... This looks good. I think resolved_indy_entry_at() should be valid because the index is a known indy so it would not have a null _resolved_indy_entries. Calling the length function may be called when dumping, so does need to defend against null as you saw in the crash. The resolved indy work went in JDK 21 baselevel 16 - don't know which update that would be though. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26770#pullrequestreview-3133614452 From kbarrett at openjdk.org Tue Aug 19 19:57:37 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Aug 2025 19:57:37 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 07:17:09 GMT, Johan Sj?len wrote: >> doc/cpp17-features.md line 128: >> >>> 126: [n4147](http://wg21.link/n4147) >>> 127: [n4424](http://wg21.link/n4424) >>> 128: [p0386r2](http://wg21.link/p0386r2) >> >> After looking at inline variables more carefully as part of writing it up for >> the style guide, I'm inclined to move inline variables to the undecided or >> forbidden category. They seem to be a solution to a problem I think we don't >> really have. >> >> Basically, they let you provide the full definition for a non-local variable >> in a header file, rather than declaring it in the header and defining it in >> an associated .cpp file. The motivating use-case is a component or library >> that is header only, to simplify client use by avoiding build issues. But >> that's just not a thing we care about for HotSpot code. >> >> So what WE get from an inline variable is having a complete declaration and >> definition in one place, rather than separating the declaration from the >> definition (so probably saving a little bit of code), at the cost of putting >> the initialization expression in the header (which might require pulling other >> stuff into the header), and maybe making the compiler work a little harder. >> >> The benefit of that seems minimal at best. >> >> The one part of it that seems slightly useful is that a constexpr variable is >> implicitly inline, so doesn't need a definition without an initializer in a >> .cpp file if the variable is ODR-used. Indeed, that's now treated as a >> duplicate defintion and deprecated usage. But we haven't had any warnings, so >> guessing we don't actually have any of those. We can take advantage of this >> for future usage. >> >> Any other opinions? > > It's a bit of ceremony to do the header + source file edits for static variables, but maybe it's one worth living with to not have to explain to people what an inline variable is. I think that they'll be accepting of `static constexpr` variables being defined inline, as there's no inline keyword involved and constexpr is already special anyway. OK, @jdksjolen and @theRealAph have convinced me. I would have needed to say something about them anyway, because of the constexpr => implicit inline => deprecation of separate definition. Note that the constexpr => implicit inline is only for static data members, not for ordinary variables; no idea why, but that's what it says. Also, will be forbidding `inline thread_local`; we heavily restrict `thread_local` anyway. No idea how `inline` interacts with the compiler-specific `thread_local` replacements we use, and don't think it's worth the trouble to explore that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2286195483 From pchilanomate at openjdk.org Tue Aug 19 20:42:23 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 19 Aug 2025 20:42:23 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v4] In-Reply-To: References: Message-ID: > Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. > > Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. > > The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: use existing badAddressVal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26660/files - new: https://git.openjdk.org/jdk/pull/26660/files/742e361d..91a685bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26660&range=02-03 Stats: 11 lines in 2 files changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26660/head:pull/26660 PR: https://git.openjdk.org/jdk/pull/26660 From pchilanomate at openjdk.org Tue Aug 19 20:42:23 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 19 Aug 2025 20:42:23 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v4] In-Reply-To: References: <7jnsZfWEq8fF6vmr9czvFxA44uSgViPcJO6s6WhQS_Q=.d273176d-fca6-4088-9b70-de1056763010@github.com> Message-ID: On Tue, 19 Aug 2025 19:03:58 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> use existing badAddressVal > > src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 34: > >> 32: >> 33: // fp value used for frozen stub/native frame >> 34: static intptr_t* const UNUSED_FP = reinterpret_cast(UCONST64(0xC0C0C0C0DEADBAAD)); > > In globalDefinitions.hpp there's a block of special constants for debugging. Can you add this constant to that with a generic name so that it might be reusable for other stack related addresses. > > Or just use badAddressVal, which is -2. I don't think it's going to crash a lot so you'd need something very recognizable. Just something that would crash. Right, that?s better. Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26660#discussion_r2286279144 From dholmes at openjdk.org Tue Aug 19 20:54:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 20:54:39 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v4] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 20:42:23 GMT, Patricio Chilano Mateo wrote: >> Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. >> >> Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. >> >> The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > use existing badAddressVal Updates look good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26660#pullrequestreview-3133801771 From matsaave at openjdk.org Tue Aug 19 20:59:35 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 19 Aug 2025 20:59:35 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... I believe the constant pool cache refactor was introduced in JDK 21 which explains why older classlist files may cause some trouble. The fix looks good and I believe it should be sufficient as we don't tend to call `resolved_indy_entry_at()` if we know that `_resolved_indy_entries` is null. Thanks! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26770#pullrequestreview-3133812806 From coleenp at openjdk.org Tue Aug 19 21:16:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Aug 2025 21:16:38 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 06:22:15 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed bugs found in JCK testing I have a few initial comments and only skimmed the rest. I didn't imagine there'd be so much code for this. src/hotspot/share/cds/dumpTimeClassInfo.cpp line 90: > 88: _old_verifier_dependencies = new (mtClass) GrowableArray(4, mtClass); > 89: } > 90: _old_verifier_dependencies->append(name); I wonder why there's append and push that do the same thing in GrowableArray. I'm used to seeing push(). src/hotspot/share/cds/metaspaceShared.cpp line 636: > 634: > 635: void VM_PopulateDumpSharedSpace::doit() { > 636: CDSConfig::set_is_at_cds_safepoint(true); Can you just use SafepointSynchronize::is_at_safepoint()? Why new flag? src/hotspot/share/classfile/systemDictionaryShared.cpp line 264: > 262: } > 263: > 264: extra blank lines. src/hotspot/share/runtime/mutexLocker.cpp line 309: > 307: MUTEX_DEFN(DumpTimeTable_lock , PaddedMutex , nosafepoint); > 308: MUTEX_DEFN(CDSLambda_lock , PaddedMutex , nosafepoint); > 309: MUTEX_DEFN(DumpRegion_lock , PaddedMutex , nosafepoint-1); // Holds DumpTimeTable_lock There's a MUTEX_DEFL where you can define the mutex in terms of the locks that it takes out. ------------- PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3129452422 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286327664 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286332210 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286336645 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286347290 From coleenp at openjdk.org Tue Aug 19 21:16:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Aug 2025 21:16:40 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: <7tWS1j21tqFe67Vz86fdjTKNvVfJt09pbNfr2awyy6E=.4fbd1e9c-b27b-4fc7-8b8c-ef9af8a4a6bc@github.com> References: <7tWS1j21tqFe67Vz86fdjTKNvVfJt09pbNfr2awyy6E=.4fbd1e9c-b27b-4fc7-8b8c-ef9af8a4a6bc@github.com> Message-ID: On Thu, 14 Aug 2025 20:48:06 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/cdsConfig.cpp line 940: >> >>> 938: >>> 939: bool CDSConfig::is_old_class_for_verifier(const InstanceKlass* ik) { >>> 940: return ik->major_version() < 50 /*JAVA_6_VERSION*/; >> >> Java 6 classes may have methods with no stack maps, which falls back to old verification. Does InstanceKlass have info on whether each method used the old verifier or StackMapTable? Attribute detection alone does not work because SMT may be omitted if the control flow is trivial. > >> Does InstanceKlass have info on whether each method used the old verifier or StackMapTable? > > The "fail over" verification happens on the entire class file. If a Java 6 class failed the new verification, it will be verified again with the old verifier. > > Currently, such classes will be excluded from the AOT cache: > > https://github.com/openjdk/jdk/blob/c5cbcac828e1c7aa845cf16e68f6306ae49e050c/src/hotspot/share/classfile/verifier.cpp#L231-L243 > > I will add a test case in this PR to make sure this case is covered. > > I also created a new RFE to include such classes in the AOT cache: https://bugs.openjdk.org/browse/JDK-8365575 I don't know why you don't fix these together, ie why does this differentiate < 50 classfiles or 50 that failed over to the old verifier? Seems like is_old_class_for_verifier should be both. You might have to set a status flag in the classfile for this though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2283145992 From pchilanomate at openjdk.org Tue Aug 19 21:32:40 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 19 Aug 2025 21:32:40 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 05:54:13 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - The oop preservation and exception handling has been fixed. > - Test added. > - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 > - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 > - added _ > - wong phase > - fixed name > - simplified after feedback > - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state src/hotspot/share/prims/jvmtiExport.cpp line 1844: > 1842: // Additionally, the result oop should be preserved while the thread is in java. > 1843: BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); > 1844: We could add the following assert here (or in `frame::interpreter_frame_result`): `assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, ??);` src/hotspot/share/prims/jvmtiExport.cpp line 1850: > 1848: // Deferred transition to VM, so we can stash away the return oop before GC > 1849: // Note that this transition is not needed when throwing an exception, because > 1850: // there is no oop to retain. This sentence about not needing the transition should be removed. src/hotspot/share/prims/jvmtiExport.cpp line 1853: > 1851: JvmtiThreadState *state; > 1852: { > 1853: ThreadInVMfromJava tiv(thread); The `JRT_BLOCK` below can be moved up. We always transition to vm anyways, so we don?t need the extra `ThreadInVMfromJava`. test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1: > 1: /* Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file? test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 52: > 50: enable(); > 51: exceptionExit(); > 52: disableAndCheck(); `disableAndCheck` should be moved after the try-catch block otherwise we will never call it. test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 62: > 60: if (upcall_method == nullptr) { > 61: fatal(jni,"Can't find upCall method."); > 62: } Missing the upcall (not noticed now because of never calling `disableAndCheck`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286328220 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286358481 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286331388 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286355238 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286335516 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286337948 From dholmes at openjdk.org Tue Aug 19 21:41:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 21:41:42 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: <0DEFfBCDPJsd5_MXkS5Uo1gAI-SYfnhKtnomWrC4G4I=.d8e4efe9-ce78-48bf-9df4-e75b0a1ffbc1@github.com> On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes wrote: > EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes. > > This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf... I am replacing this PR with a refreshed one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26470#issuecomment-3202320187 From dholmes at openjdk.org Tue Aug 19 21:41:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 21:41:43 GMT Subject: Withdrawn: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 01:40:45 GMT, David Holmes wrote: > EDIT: I've just realized that the `[[nodiscard]]` attribute is not currently permitted. So I may have to revise this aspect of the changes. > > This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26470 From dholmes at openjdk.org Tue Aug 19 22:09:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Aug 2025 22:09:19 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked Message-ID: This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) From: https://bugs.openjdk.org/browse/JDK-8347707 The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. The potential errors are, generally speaking, not something we should encounter in our own well-written code: - encoding error: not applicable as we are not using extended character sets - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) - mal-formed formatting directives - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. The potential clients of this API then fall into a number of camps: 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. 4. Those who present a buffer but know that truncation is a possibility, and either need to handle it themselves, or else need to use the return value in subsequent operations. These clients are also directed to use `os::snprintf`. In summary we provide the following API: - `[[nodiscard]] int os::vsnprintf` is the building block for the other methods, it: - asserts on precondition failures - asserts on error - guarantees null-termination in the case of unexpected errors (as the standards are still unclear on that point - is declared `[[nodiscard[]]` so that callers cannot ignore the return value (they can explicitly cast to `void` to indicate they don't need it) - `void os::snprintf_checked` - calls `os::vnsprintf`` so asserts on errors - asserts on truncation - `[[nodiscard]] int os::snprintf` - calls `os::vnsprintf` so asserts on errors In terms of the effects on the existing code we: - Change callers of `::snprintf`/`os::snprintf` that ignore the return value and ensure the buffer is large enough to use `os::snprintf_checked` - those that allow truncation to happen must use `os::snprintf`. - Change all callers of `::snprintf`/`os::snprintf` that use the return value to use `os::snprintf`, plus any additional assertions needed - Change the 9 callers of `os::snprintf_checked` that do use the return value, to use `os::snprintf` with their own assertions added - Callers of `os::vnsprintf` are adjusted as needed The PR is comprising multiple dependent commits so that you can view things in stages. There are 46 modified files. The bulk of the changes replace calls to `snprintf`/`os::snprintf` with calls to `os::snprintf_checked`. Note the use of `[[nodiscard]]` is permitted but not yet documented as such in the style-guide. ------------- Commit messages: - Merge - Make os::snprintf "nodiscard" and adjust final callsites - Convert os::snprintf() to os::snprintf_checked() where appropriate. - Forbid C library snprintf - Change return-value using snprintf to explicit os::snprintf - Change raw snprintf to os::snprintf_checked, whereever truncation would not - Change os::snprintf_checked to be void function. - Mark os::vsnprintf as nodiscard and update the callsites. Changes: https://git.openjdk.org/jdk/pull/26849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26849&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347707 Stats: 195 lines in 46 files changed: 14 ins; 5 del; 176 mod Patch: https://git.openjdk.org/jdk/pull/26849.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26849/head:pull/26849 PR: https://git.openjdk.org/jdk/pull/26849 From dlong at openjdk.org Tue Aug 19 22:30:38 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Aug 2025 22:30:38 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v12] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 17:31:58 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Print with %zd Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3134033980 From lmesnik at openjdk.org Tue Aug 19 23:25:23 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Aug 2025 23:25:23 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v6] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision: - moved JRT_BLOCK - added assertion and removed comment. - test fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/d9d21af6..32b08587 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=04-05 Stats: 34 lines in 3 files changed: 14 ins; 7 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Tue Aug 19 23:25:24 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Aug 2025 23:25:24 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> On Tue, 19 Aug 2025 21:17:16 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: >> >> - The oop preservation and exception handling has been fixed. >> - Test added. >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 >> - added _ >> - wong phase >> - fixed name >> - simplified after feedback >> - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state > > test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1: > >> 1: /* > > Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file? It makes test name serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java so it is better to left it on this level And tests usually have single lib*.cpp per directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286597518 From lmesnik at openjdk.org Tue Aug 19 23:28:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Aug 2025 23:28:39 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 21:02:26 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: >> >> - The oop preservation and exception handling has been fixed. >> - Test added. >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192 >> - added _ >> - wong phase >> - fixed name >> - simplified after feedback >> - 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state > > src/hotspot/share/prims/jvmtiExport.cpp line 1844: > >> 1842: // Additionally, the result oop should be preserved while the thread is in java. >> 1843: BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); >> 1844: > > We could add the following assert here (or in `frame::interpreter_frame_result`): > > `assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, ??);` Thanks, added. > src/hotspot/share/prims/jvmtiExport.cpp line 1853: > >> 1851: JvmtiThreadState *state; >> 1852: { >> 1853: ThreadInVMfromJava tiv(thread); > > The `JRT_BLOCK` below can be moved up. We always transition to vm anyways, so we don?t need the extra `ThreadInVMfromJava`. I tried to do this in the first implementation, probably because of other problems. Seems, it can be done now. I run some testing to verify this fix. > test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 62: > >> 60: if (upcall_method == nullptr) { >> 61: fatal(jni,"Can't find upCall method."); >> 62: } > > Missing the upcall (not noticed now because of never calling `disableAndCheck`). Thanks, I removed it right before final clean up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286603703 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286603775 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286604585 From iklam at openjdk.org Tue Aug 19 23:32:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Aug 2025 23:32:42 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: <7tWS1j21tqFe67Vz86fdjTKNvVfJt09pbNfr2awyy6E=.4fbd1e9c-b27b-4fc7-8b8c-ef9af8a4a6bc@github.com> Message-ID: On Mon, 18 Aug 2025 18:30:01 GMT, Coleen Phillimore wrote: >>> Does InstanceKlass have info on whether each method used the old verifier or StackMapTable? >> >> The "fail over" verification happens on the entire class file. If a Java 6 class failed the new verification, it will be verified again with the old verifier. >> >> Currently, such classes will be excluded from the AOT cache: >> >> https://github.com/openjdk/jdk/blob/c5cbcac828e1c7aa845cf16e68f6306ae49e050c/src/hotspot/share/classfile/verifier.cpp#L231-L243 >> >> I will add a test case in this PR to make sure this case is covered. >> >> I also created a new RFE to include such classes in the AOT cache: https://bugs.openjdk.org/browse/JDK-8365575 > > I don't know why you don't fix these together, ie why does this differentiate < 50 classfiles or 50 that failed over to the old verifier? Seems like is_old_class_for_verifier should be both. You might have to set a status flag in the classfile for this though. This PR is complicated enough, so I want to fix the `== 50` case in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286611939 From iklam at openjdk.org Tue Aug 19 23:35:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Aug 2025 23:35:36 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> On Tue, 19 Aug 2025 21:02:07 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed bugs found in JCK testing > > src/hotspot/share/cds/dumpTimeClassInfo.cpp line 90: > >> 88: _old_verifier_dependencies = new (mtClass) GrowableArray(4, mtClass); >> 89: } >> 90: _old_verifier_dependencies->append(name); > > I wonder why there's append and push that do the same thing in GrowableArray. I'm used to seeing push(). I am not sure why there are two versions. They seem to be used at similar frequency (about 300 calls each). > src/hotspot/share/cds/metaspaceShared.cpp line 636: > >> 634: >> 635: void VM_PopulateDumpSharedSpace::doit() { >> 636: CDSConfig::set_is_at_cds_safepoint(true); > > Can you just use SafepointSynchronize::is_at_safepoint()? Why new flag? We need to know if are are at the CDS safepoint, not any safepoint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286614502 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286615456 From cslucas at openjdk.org Tue Aug 19 23:52:50 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 19 Aug 2025 23:52:50 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points Message-ID: The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. ------------- Commit messages: - Shenandoah API clean-up. Changes: https://git.openjdk.org/jdk/pull/26850/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26850&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356289 Stats: 31 lines in 9 files changed: 1 ins; 8 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/26850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26850/head:pull/26850 PR: https://git.openjdk.org/jdk/pull/26850 From iklam at openjdk.org Tue Aug 19 23:54:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Aug 2025 23:54:39 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v3] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - @coleenp comments - More bug fixes from JCK testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/b7f51ed2..e3080281 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=01-02 Stats: 9 lines in 4 files changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From iklam at openjdk.org Tue Aug 19 23:54:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Aug 2025 23:54:41 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 21:07:27 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed bugs found in JCK testing > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 264: > >> 262: } >> 263: >> 264: > > extra blank lines. Fixed. > src/hotspot/share/runtime/mutexLocker.cpp line 309: > >> 307: MUTEX_DEFN(DumpTimeTable_lock , PaddedMutex , nosafepoint); >> 308: MUTEX_DEFN(CDSLambda_lock , PaddedMutex , nosafepoint); >> 309: MUTEX_DEFN(DumpRegion_lock , PaddedMutex , nosafepoint-1); // Holds DumpTimeTable_lock > > There's a MUTEX_DEFL where you can define the mutex in terms of the locks that it takes out. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286641037 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2286640872 From kvn at openjdk.org Tue Aug 19 23:59:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 19 Aug 2025 23:59:40 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 04:27:23 GMT, Ioi Lam wrote: >> Implement `-Xlog:aot+map` in the production run: >> >> >> $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ >> -Xlog:aot+map=file=aot.map:none:filesize=0 \ >> HelloWorld >> >> >> I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: >> >> 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. >> 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed crash with ZGC src/hotspot/share/cds/aotMapLogger.hpp line 54: > 52: // > 53: // Because the output can be large, it's best to save it to a file > 54: // java -XX:AOTCache=app.aot -Xlog:aot+map*=trace:file=aot.map:none:filesize=0 --version why `filesize=0`? test/hotspot/jtreg/runtime/cds/CDSMapTest.java line 94: > 92: vmArgs.add("-Xlog:cds=debug"); > 93: vmArgs.add("-Xshare:on"); > 94: vmArgs.add("-Xlog:aot+map=debug,aot+map+oops=trace:file=" + mapName + ":none:filesize=0"); Looks like this test is intended for old CDS archive. Do you have test for new AOTCache workflow? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26514#discussion_r2286644603 PR Review Comment: https://git.openjdk.org/jdk/pull/26514#discussion_r2286648767 From duke at openjdk.org Wed Aug 20 00:44:47 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 20 Aug 2025 00:44:47 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 10:27:30 GMT, Francesco Andreuzzi wrote: > > For example, when the threshold is set to 50 I get this compilation error: > > How can we possibly get a compilation error when everything should build with PCH disabled? @dholmes-ora FYI I tracked the failure and opened a ticket: https://bugs.openjdk.org/browse/JDK-8365829 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3203544026 From dholmes at openjdk.org Wed Aug 20 01:17:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 01:17:51 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v28] In-Reply-To: References: Message-ID: <3zW1KOc15HDoagM6NTMgYkHmk7xD-rRyZrKtFdi6cpY=.a1645af1-92f7-4cec-886c-17ad894af153@github.com> On Tue, 19 Aug 2025 08:25:13 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewer's comments Asserts should always provide as much error detail as is available - otherwise when they fail we do not know why. Thanks src/hotspot/os/linux/os_linux.cpp line 306: > 304: int ret = sysinfo(&si); > 305: if (ret != 0) { > 306: assert(false, "sysinfo failed in total_swap_space()?"); We should report the value of errno in these cases. Suggestion: assert(false, "sysinfo failed in total_swap_space(): %s", os::strerror(errno)); src/hotspot/os/windows/os_windows.cpp line 869: > 867: return true; > 868: } else { > 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory()."); These should report the value of `::GetLastError()` src/hotspot/os/windows/os_windows.cpp line 870: > 868: } else { > 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory()."); > 870: return res == TRUE; Suggestion: return false; Please restore all these to "return false" as we know that `res == false` here. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3134449354 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2286731388 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2286734810 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2286736956 From dholmes at openjdk.org Wed Aug 20 02:35:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 02:35:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused I'll leave it to the GC folk to approve, but the shared code changes look good to me. Thanks src/hotspot/share/services/cpuTimeUsage.cpp line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. When refactoring code into a new file, the first copyright year for the new file should be the earliest copyright year of the substantial code/content in that file?not the year the new file is created. ------------- PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3134573286 PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2286823424 From dholmes at openjdk.org Wed Aug 20 02:39:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 02:39:39 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 19 Aug 2025 08:59:18 GMT, Kim Barrett wrote: >> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > src/hotspot/share/utilities/ostream.cpp line 1001: > >> 999: xtty = nullptr; >> 1000: OrderAccess::fence(); // force visibility to concurrently executing threads >> 1001: delete ds; > > There are lots of places in the VM that don't even try to clean up on VM exit. I think we even talk > about non-cleanup on exit in the style guide. So why are we doing this cleanup, in such a potentially > sensitive/fragile area? Because we are flushing and closing the output streams so their content will be made available. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26832#discussion_r2286836368 From dholmes at openjdk.org Wed Aug 20 02:51:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 02:51:38 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v9] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 19 Aug 2025 07:34:30 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments Looks good. Thanks. FTR use of `volatile` is the preferred convention. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26656#pullrequestreview-3134602873 From kbarrett at openjdk.org Wed Aug 20 03:02:36 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Aug 2025 03:02:36 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Wed, 20 Aug 2025 02:36:48 GMT, David Holmes wrote: >> src/hotspot/share/utilities/ostream.cpp line 1001: >> >>> 999: xtty = nullptr; >>> 1000: OrderAccess::fence(); // force visibility to concurrently executing threads >>> 1001: delete ds; >> >> There are lots of places in the VM that don't even try to clean up on VM exit. I think we even talk >> about non-cleanup on exit in the style guide. So why are we doing this cleanup, in such a potentially >> sensitive/fragile area? > > Because we are flushing and closing the output streams so their content will be made available. flush, sure. but closing and deleting seems to be asking for trouble. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26832#discussion_r2286859537 From stuefe at openjdk.org Wed Aug 20 04:44:40 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 20 Aug 2025 04:44:40 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Wed, 20 Aug 2025 03:00:23 GMT, Kim Barrett wrote: >> Because we are flushing and closing the output streams so their content will be made available. > > flush, sure. but closing and deleting seems to be asking for trouble. I agree with @kimbarrett . Apart from stability, it is also just unnecessary work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26832#discussion_r2286964944 From ksakata at openjdk.org Wed Aug 20 04:49:41 2025 From: ksakata at openjdk.org (Koichi Sakata) Date: Wed, 20 Aug 2025 04:49:41 GMT Subject: RFR: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: <8akZ1xG9anggLvGw3S6Z-eH0C67ERmZB5V95QiILzdI=.b041c64f-896d-46e4-93b5-120bacffd042@github.com> On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... Thank you for the reviews, Coleen and Matias! Based on your feedback, I?ll proceed with integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26770#issuecomment-3204172460 From ksakata at openjdk.org Wed Aug 20 04:49:42 2025 From: ksakata at openjdk.org (Koichi Sakata) Date: Wed, 20 Aug 2025 04:49:42 GMT Subject: Integrated: 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 07:30:40 GMT, Koichi Sakata wrote: > A crash occurs when running with `-Xshare:dump` and specifying a class list file generated by an older JDK (e.g. JDK 17) via `-XX:SharedClassListFile`. > This pull request fixes the issue and prevents the crash. > > # Details > Example command to reproduce: > > $ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux- > aarch64) > # Problematic frame: > # V [libjvm.so+0x90355c] ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc > [full crash log omitted for brevity] > > The class list file that triggers the problem, generated by JDK 17, looks like this: > > @lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder; > > > In contrast, the recent JDK generates class list contents as follows: > > @cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141 > @cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 2... This pull request has now been integrated. Changeset: 506625b7 Author: Koichi Sakata URL: https://git.openjdk.org/jdk/commit/506625b768c940a3f4fc2efce485d9207ca61cfe Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 Reviewed-by: coleenp, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/26770 From stuefe at openjdk.org Wed Aug 20 04:57:18 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 20 Aug 2025 04:57:18 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v5] In-Reply-To: References: Message-ID: > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - feedback Caspar - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - Feedback Johan - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - merge master - copyrights - fix big-endian problem on AIX - Update klass.cpp - Update metaspace.hpp - Update metaspace.hpp - ... and 4 more: https://git.openjdk.org/jdk/compare/640b71da...6cc648c7 ------------- Changes: https://git.openjdk.org/jdk/pull/25891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=04 Stats: 485 lines in 26 files changed: 401 ins; 27 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From stuefe at openjdk.org Wed Aug 20 04:57:19 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 20 Aug 2025 04:57:19 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v4] In-Reply-To: References: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> Message-ID: On Tue, 19 Aug 2025 13:35:47 GMT, Casper Norrbin wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Johan > > src/hotspot/share/oops/metadata.hpp line 49: > >> 47: static constexpr uint32_t common_prefix_mask = BUILD_32(0xFFFF, 0); >> 48: static constexpr uint32_t instance_klass_token = BUILD_32(0x3E7A, 0x100); >> 49: static constexpr uint32_t array_klass_token = BUILD_32(0x3E7A, 0x101); > > Nit / question: Any particular reason we're building the tokens with `BUILD_32(high, low)` instead of writing out the full literal (e.g. `0x3E7A0100`)? Is it mainly for readability or are there other considerations? None whatsoever, apart from readability. I changed to use plain constants. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2286977051 From lmesnik at openjdk.org Wed Aug 20 04:58:20 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 04:58:20 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: NULL replaced ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/32b08587..0008f725 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From stuefe at openjdk.org Wed Aug 20 05:24:38 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 20 Aug 2025 05:24:38 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 18:59:18 GMT, Erik Gahlin wrote: > > You mean adding the vsize, swap etc fields to ResidentSetSize? > > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) > > I was thinking something like this: > > ``` > > > > > > > > ``` Hmm, yes, that would be one alternative. > > When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. > > > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. > > Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal. > > These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation. Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way. In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss. I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the most important platform. On Windows, for example, we can ask for the size of the commit charge. That is a nice complementary information. On Linux, we also have a commit charge (as in, how much of the process memory was committed by the OS, underlaid with swap according to the kernel overcommit rules). That would be useful to know, since it can explain native OOMs when the OS runs out of swap. But I don't see a way to obtain that information on Linux. Since I only have the number on Windows, I left it out. And I realize this is a bit arbitrary, since I included values I only get for Linux. Shaping events the right way is hard, and I am thankful for any direction from your side. > > > It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance). > > We should not sacrifice the design unless the overhead is significant. Hm, sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3204233221 From dholmes at openjdk.org Wed Aug 20 05:37:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 05:37:43 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: Message-ID: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> On Wed, 20 Aug 2025 04:58:20 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > NULL replaced I'm very confused by this issue. The description indicates we are calling `get_jvmti_thread_state` from the wrong state, but nowhere here or in JBS do I see anything showing me the actual failing code path. JBS has a part of a hs_err file that reports "# fatal error: LEAF method calling lock? " but I don't see how that relates to the stated problem of being in the wrong state ?? Also you state `post_method_exit` is not called when the method terminates via an exception, but I can't see that as being the case. The MethodExit callback in JVMTI is called under all termination conditions and post_method_exit seems similarly unconditional. ?? test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32: > 30: * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred > 31: */ > 32: public class ExceptionOccurred { I'm very confused by the naming here: what exception has occurred where? test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 42: > 40: > 41: > 42: // Called from ExcptionExit MethodExit callback via JNI Suggestion: // Called from ExceptionExit MethodExit callback via JNI test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 32: > 30: bool method_exit_posted = false; > 31: static void JNICALL > 32: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method, Can you add a comment describing the logic of this callback function please. I cannot make sense of the logic below. How many times will this callback get executed? ------------- PR Review: https://git.openjdk.org/jdk/pull/26713#pullrequestreview-3134777503 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286990333 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286984860 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286995606 From dholmes at openjdk.org Wed Aug 20 05:37:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 05:37:45 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v6] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 23:25:23 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision: > > - moved JRT_BLOCK > - added assertion and removed comment. > - test fixed. src/hotspot/share/prims/jvmtiExport.cpp line 1839: > 1837: value.l = 0L; > 1838: // post_method_exist is called only when the method is not exit because of > 1839: // exception so result should be always initialized. Suggestion: // post_method_exit is only called when the method exits normally, // so result should be always initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286979400 From dholmes at openjdk.org Wed Aug 20 05:37:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 05:37:46 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> References: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> Message-ID: <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com> On Tue, 19 Aug 2025 23:22:09 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 1: >> >>> 1: /* >> >> Shouldn't this file be placed in `test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred` along with the cpp file? > > It makes test name > serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java > so it is better to left it on this level > And tests usually have single lib*.cpp per directory. It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2286984421 From lmesnik at openjdk.org Wed Aug 20 05:47:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 05:47:54 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v8] In-Reply-To: References: Message-ID: <9_uLv6OW8fN5Ow5KAK2fLwEJpUrDjGbE8--Az6wO480=.db6786c7-6485-4582-94f4-768d38ac0019@github.com> > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/0008f725..320b93eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Wed Aug 20 06:30:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 06:30:39 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: On Wed, 20 Aug 2025 05:35:33 GMT, David Holmes wrote: > I'm very confused by this issue. The description indicates we are calling `get_jvmti_thread_state` from the wrong state, but nowhere here or in JBS do I see anything showing me the actual failing code path. JBS has a part of a hs_err file that reports "# fatal error: LEAF method calling lock? " but I don't see how that relates to the stated problem of being in the wrong state ?? > The comment in JBS shows the stacktrace from hs_err. I copied it here: Stack: [0x00007f13537f9000,0x00007f13538f9000], sp=0x00007f13538f6b60, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x10c4458] JavaThread::check_for_valid_safepoint_state()+0xc8 (javaThread.cpp:401) V [libjvm.so+0x16fe5e1] Mutex::lock()+0x41 (mutex.cpp:119) V [libjvm.so+0x1403b7b] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x39b (mutexLocker.hpp:204) V [libjvm.so+0x140b178] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool) [clone .constprop.0]+0x98 (jvmtiExport.cpp:424) V [libjvm.so+0x1415b57] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x77 (jvmtiExport.cpp:1834) V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278) Also, I updated another comment to show how to reproduce the bug. The testing is not integrated in CI yet. However, it could be reproduced using our tests. Also, the problem could be quite easy reproduced if assertion from the patch is added to ` JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) { ` > Also you state `post_method_exit` is not called when the method terminates via an exception, but I can't see that as being the case. The MethodExit callback in JVMTI is called under all termination conditions and post_method_exit seems similarly unconditional. ?? The method ` void JvmtiExport::post_method_exit_inner(JavaThread* thread, methodHandle& mh, JvmtiThreadState *state, bool exception_exit, frame current_frame, jvalue& value) { ` is used by `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame) {` to post MethodExit events. And ` void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) { ` that also calls `JvmtiExport::post_method_exit_inner()` is used only when method exit normally. T `JvmtiExport::post_method_exit()` has the variable `exception_exit`. This variable is set to true while the thread has exception that has been thrown but haven't caught yet. It might happens if VM or JNI made upcall while thread has ES_DETECTED _exception_state. So current method is exit normally while thread is processing exception. Pretty rare case that is reproduced in the test 'ExceptionOccured'. The method is called from MethodExit event for the method where exception has been thrown. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3204367348 From lmesnik at openjdk.org Wed Aug 20 06:36:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 06:36:58 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v9] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added comments to the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/320b93eb..6960b1aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=07-08 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Wed Aug 20 06:46:03 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 06:46:03 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v10] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/prims/jvmtiExport.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/6960b1aa..67d87dbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lmesnik at openjdk.org Wed Aug 20 06:46:03 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 06:46:03 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com> References: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com> Message-ID: On Wed, 20 Aug 2025 04:59:29 GMT, David Holmes wrote: >> It makes test name >> serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java >> so it is better to left it on this level >> And tests usually have single lib*.cpp per directory. > > It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp The test name would be test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java I don't like this duplication. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287145310 From lmesnik at openjdk.org Wed Aug 20 06:46:03 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 06:46:03 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: On Wed, 20 Aug 2025 05:04:38 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> NULL replaced > > test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32: > >> 30: * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred >> 31: */ >> 32: public class ExceptionOccurred { > > I'm very confused by the naming here: what exception has occurred where? The exception was thrown in the current thread/ However, the current method is not unwinded. It is called using JNI while the thread has already thrown but not yet caught exception. I thought to name it MethodExitWhileExceptionPending, however full name would be serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java so I started to "reduce" it. Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind. > test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 32: > >> 30: bool method_exit_posted = false; >> 31: static void JNICALL >> 32: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method, > > Can you add a comment describing the logic of this callback function please. I cannot make sense of the logic below. How many times will this callback get executed? Done, hope it makes logic clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287048500 PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287139860 From duke at openjdk.org Wed Aug 20 07:04:44 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 20 Aug 2025 07:04:44 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v8] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <06AvqaWD0vLK3WmCjuRcoRQdcF4Uahs1kgIMKjTi9gs=.fe782803-f44f-49f0-a7e0-479eaf963c41@github.com> On Sun, 17 Aug 2025 21:34:05 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8364819: Added atomic loads to getters > > Our convention for lock-free code is that we should use `Atomic::load` and `Atomic::store` for all accesses to the shared variable. - this serves as clear documentation of the lock-free nature of the code. The use, or not, of `volatile` on the declaration of the shared variable is not a convention we have firmly established or documented. I am in the camp that the `volatile` should not be present on the declaration as we have internalised/encapsulated the `volatile` within the `Atomic` functions. > > @albertnetymk suggestion to use explicit `release` between the store and the `pthread_kill` does also address the visibility concern unlike the earlier `release_store` suggestion which puts the `release` in the wrong place. On further reflection my suggestion about the `fence` should also make the `fence` explicit between the store and the `pthread_kill` rather than being inside the setter method (which again by our own conventions should be renamed to have `fence` in the name if we did that). > > Arguably, as stated much much earlier, we don't need any explicit memory ordering here in practice as the signal implementation must provide its own ordering guarantees to actually function - and there is no way a compiler would ever re-order the store with the `pthread_kill` call! Thanks @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3204460815 From aboldtch at openjdk.org Wed Aug 20 07:12:56 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 20 Aug 2025 07:12:56 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - conditional includes > - variants I have a few questions/comments. There are now a bunch of unconditional includes for JVM features which can be disabled. With the exception of CDS, in the rest of the codebase we have been very careful to always guard these includes when using them outside their own sub-components. I understand that these are generated includes, but I think we can curate the list some manually. Currently `c1/c1_globals.hpp` `jvmci/jvmci_globals.hpp` and `opto/c2_globals.hpp` are included which are optional features, `compiler/compiler_globals.hpp` (which is also included) should be used instead. Same goes for `gc/serial/serial_globals.hpp` and `gc/shared/gc_globals.hpp`. In addition to those globals files we have all the JFR and CDS includes which are unguarded. I am not sure I understand completely what goes into the list of conditional includes here. I understand that there might be duplicates across the different conditional includes, but now there are also includes which are duplicated in the unconditional includes. So is it a list of all includes which are beneficial when building with just that feature, or is it suppose to be a list of extra includes which are beneficial if that feature is enabled. Or are those lists something else? ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3135090453 From duke at openjdk.org Wed Aug 20 07:19:36 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 20 Aug 2025 07:19:36 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: References: Message-ID: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/a1f14803..a3ed98aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=27-28 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Wed Aug 20 07:19:39 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 20 Aug 2025 07:19:39 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v28] In-Reply-To: <3zW1KOc15HDoagM6NTMgYkHmk7xD-rRyZrKtFdi6cpY=.a1645af1-92f7-4cec-886c-17ad894af153@github.com> References: <3zW1KOc15HDoagM6NTMgYkHmk7xD-rRyZrKtFdi6cpY=.a1645af1-92f7-4cec-886c-17ad894af153@github.com> Message-ID: <-sJOMWcZkzXUaXiO8Do6SGibgdKYdkHAju44WGdkTI8=.7c7b464b-ac01-4f86-915f-08963e63b6c8@github.com> On Wed, 20 Aug 2025 01:06:34 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Addressed reviewer's comments > > src/hotspot/os/linux/os_linux.cpp line 306: > >> 304: int ret = sysinfo(&si); >> 305: if (ret != 0) { >> 306: assert(false, "sysinfo failed in total_swap_space()?"); > > We should report the value of errno in these cases. > Suggestion: > > assert(false, "sysinfo failed in total_swap_space(): %s", os::strerror(errno)); Added `errno `reporting as suggested. > src/hotspot/os/windows/os_windows.cpp line 869: > >> 867: return true; >> 868: } else { >> 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory()."); > > These should report the value of `::GetLastError()` Added error reporting as suggested. > src/hotspot/os/windows/os_windows.cpp line 870: > >> 868: } else { >> 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory()."); >> 870: return res == TRUE; > > Suggestion: > > return false; > > Please restore all these to "return false" as we know that `res == false` here. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2287217685 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2287217572 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2287217452 From duke at openjdk.org Wed Aug 20 07:23:41 2025 From: duke at openjdk.org (duke) Date: Wed, 20 Aug 2025 07:23:41 GMT Subject: RFR: 8364819: Post-integration cleanups for JDK-8359820 [v9] In-Reply-To: References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: On Tue, 19 Aug 2025 07:34:30 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a cleanup after https://github.com/openjdk/jdk/pull/26309 >> >> 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. >> >> 2) Added a missed brace in the error message. >> >> 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. >> >> Trivial change. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8364819: Addressed reviewer's comments @toxaart Your change (at version ee4ceadb1d3c3a028246dcc8ba9cf611be1d9f6d) is now ready to be sponsored by a Committer. @toxaart Your change (at version ee4ceadb1d3c3a028246dcc8ba9cf611be1d9f6d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3204531242 PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3204537276 From duke at openjdk.org Wed Aug 20 07:31:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 20 Aug 2025 07:31:47 GMT Subject: Integrated: 8364819: Post-integration cleanups for JDK-8359820 In-Reply-To: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> References: <52HWTyql-JmgGdaGWSLOifQ681Z-U6wNvUp1Nxk07Rs=.eabdb8c2-47f0-46f6-b0e1-e3b67dfc40f1@github.com> Message-ID: <3T0CR6caVjz4YkhZl7CqRiQz5IkLnmDYlg-CkFmBoTw=.c1ee27df-8e69-495b-aa3d-67e4ec1107aa@github.com> On Wed, 6 Aug 2025 10:05:08 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a cleanup after https://github.com/openjdk/jdk/pull/26309 > > 1) `_handshake_timed_out_thread `and `_safepoint_timed_out_thread` are now `Thread*` and not `intptr_t`, no conversions `p2i <-> i2p` needed. > > 2) Added a missed brace in the error message. > > 3) Updates are done with `Atomic::replace_if_null()` to address possible multiple updates and visibility among all threads. > > Trivial change. This pull request has now been integrated. Changeset: 4ffd2a8a Author: Anton Artemov Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/4ffd2a8aa45fa78c2546e84dc908263e7f342484 Stats: 31 lines in 5 files changed: 14 ins; 0 del; 17 mod 8364819: Post-integration cleanups for JDK-8359820 Reviewed-by: dholmes, ayang, shade ------------- PR: https://git.openjdk.org/jdk/pull/26656 From dholmes at openjdk.org Wed Aug 20 07:36:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 07:36:43 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com> Message-ID: <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com> On Wed, 20 Aug 2025 06:42:38 GMT, Leonid Mesnik wrote: >> It is normal/common to have a directory Foo that contains both Foo.java and libFoo.cpp > > The test name would be > test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java > I don't like this duplication. It is common to use a `Test` prefix on the actual file so we have directory `foo`, containing `TestFoo.java` and `libFoo.cpp` (or 'libTestFoo.cpp`). The point is that all the source files for one test reside in the same directory unless a different structure is needed for some reason. Placing the native code in its own subdirectory looks very odd to me. But of course there is no general consistency here and it depends on who wrote the test cases and when. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287263124 From fyang at openjdk.org Wed Aug 20 07:38:46 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 20 Aug 2025 07:38:46 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 In-Reply-To: References: Message-ID: <2uVYeF6NbvyhXG8DddOsSqpCN5uQ5VMI2OKtgbYjmqI=.f098a0f3-b854-4da9-9b52-8825dbe27012@github.com> On Tue, 19 Aug 2025 08:22:59 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Thanks for fixing this! I have several comments. BTW: I assume you have checked `float16_to_float_slow_path` as well? Does it need a fix? src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2394: > 2392: __ bind(stub.entry()); > 2393: > 2394: __ float_to_float16_NaN(src, dst, t0, t1); I see `t1` which is the rFlagsReg register for riscv is passed as a temp register. But this side effect (clobbering of `t1`) doesn't reflect on the callsite `float_to_float16` in `instruct convF2HF_reg_reg`. So I guess you might want to pass `tmp` instead of `t1` here. Like: `__ float_to_float16_NaN(src, dst, t0, tmp);` src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5958: > 5956: > 5957: // this is a utility method to process the slow path of NaN when converting float to float16 > 5958: // check j.l.Float.floatToFloat16 Suggestion: `Helper routine processing the slow path of NaN when converting float to float16` src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5959: > 5957: // this is a utility method to process the slow path of NaN when converting float to float16 > 5958: // check j.l.Float.floatToFloat16 > 5959: void MacroAssembler::float_to_float16_NaN(FloatRegister src, Register dst, Can you swap the first two params? I perfer to have `dst` which holds the result as the first one. I think that's what we always do for other assembler routines as well. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5968: > 5966: > 5967: // preserve the payloads of non-canonical NaNs. > 5968: // get the result by merging sign bit and payloads of preserved non-canonical NaNs. Maybe we can borrow some code comments from the java code? // Preserve high order bit of float NaN in the // binary16 result NaN (tenth bit); OR in remaining // bits into lower 9 bits of binary 16 significand. src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1434: > 1432: void java_round_double(Register dst, FloatRegister src, FloatRegister ftmp); > 1433: > 1434: // this is a utility method to process the slow path of NaN when converting float to float16 Suggestion: `Helper routine processing the slow path of NaN when converting float to float16` ------------- PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3134487961 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2286872903 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287256536 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2286883081 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287251315 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2286756857 From dholmes at openjdk.org Wed Aug 20 07:44:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 07:44:37 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: On Wed, 20 Aug 2025 06:28:26 GMT, Leonid Mesnik wrote: > The comment in JBS shows the stacktrace from hs_err. But nothing in that hs_err snippet indicates that the problem is we are in the wrong state. > void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame)` that also calls `JvmtiExport::post_method_exit_inner()` is used only when method exit normally. Thanks for clarifying. I was looking at remove_activation in the interpreter and did not see any special exception processing path. > So current method is exit normally while thread is processing exception. Still struggling with this part. So the method exited normally then as part of event processing a Java upcall can raise an exception? But according to the spec any such exceptions get dropped - so is the flag just to do the dropping? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3204655870 From dholmes at openjdk.org Wed Aug 20 07:50:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 07:50:39 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: On Wed, 20 Aug 2025 05:49:17 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java line 32: >> >>> 30: * @run main/othervm/native -agentlib:ExceptionOccurred ExceptionOccurred >>> 31: */ >>> 32: public class ExceptionOccurred { >> >> I'm very confused by the naming here: what exception has occurred where? > > The exception was thrown in the current thread/ However, the current method is not unwinded. It is called using JNI while the thread has already thrown but not yet caught exception. > I thought to name it MethodExitWhileExceptionPending, however full name would be > serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java > so I started to "reduce" it. > Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind. Well `ExceptionExit` is slightly clearer and ties in with `exceptionExit()`. Before this fix what happens if you run this test case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287298481 From dholmes at openjdk.org Wed Aug 20 07:50:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 07:50:40 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v10] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 06:46:03 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/prims/jvmtiExport.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp line 35: > 33: // has been popped by exception and call 'upCall' mthod using JNI. > 34: // 2) for upCall method it verifies that event has correct > 35: // return value and was not popped by execption. Suggestion: // return value and was not popped by exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2287292340 From sjohanss at openjdk.org Wed Aug 20 08:17:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 20 Aug 2025 08:17:43 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v10] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 15:54:29 GMT, Jonas Norlinder wrote: >>> now we finally have a specific method that is called for GC activites... >> >> Then, it should be in `Universe::before_exit`, not inside heap. > > FWIW; `Universe::print_on` do actually call collected heap as well. > > > void Universe::print_on(outputStream* st) { > GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread. > st->print_cr("Heap"); > > StreamIndentor si(st, 1); > heap()->print_heap_on(st); > MetaspaceUtils::print_on(st); > } > > > I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding. I'm good with moving it to `Universe::before_exit` as well. Looks like a good fit now when it was added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287363859 From aph at openjdk.org Wed Aug 20 08:41:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Aug 2025 08:41:41 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:38:54 GMT, Samuel Chee wrote: >> src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1410: >> >>> 1408: // be atomic - which includes unaligned ones - use the generic DMB + LD sequence, as LDAR might >>> 1409: // fault for unaligned accesses. >>> 1410: if (AlwaysAtomicAccesses) { >> >> I'm not sure this makes sense. Misaligned accesses can't ever be atomic. > > Yes, so the experimental flag `AlwaysAtomicAccesses` will attempt to force to make all accesses atomic - even misaligned ones which causes a memory access error if using LDAR. Hence we resort to the old code sequence when this flag is active. Right, but I don't think we need to do this. I'm asking around to find out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2287427842 From aph at openjdk.org Wed Aug 20 08:44:40 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Aug 2025 08:44:40 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 15:58:52 GMT, Samuel Chee wrote: >> According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: >> >>> Atomically sets the value of a variable to the newValue with the >>> memory semantics of setVolatile if the variable's current value, >>> referred to as the witness value, == the expectedValue, as accessed >>> with the memory semantics of getVolatile. >> >> Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. >> >> Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). >> >> The unused cmpxchgw is removed. >> >> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) > > Samuel Chee has updated the pull request incrementally with one additional commit since the last revision: > > Merge master fix > > Change-Id: I74d44f711de208395bce47595fecd801564bcb54 Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26845#pullrequestreview-3135439896 From aph at openjdk.org Wed Aug 20 08:47:39 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Aug 2025 08:47:39 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: On Tue, 19 Aug 2025 16:39:29 GMT, Vladimir Kozlov wrote: > > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. > > Or code should be the same. OK, so we should not commit this patch. it's not worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3204868243 From cnorrbin at openjdk.org Wed Aug 20 08:57:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 20 Aug 2025 08:57:43 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 04:57:18 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - feedback Caspar > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - Feedback Johan > - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - merge master > - copyrights > - fix big-endian problem on AIX > - Update klass.cpp > - Update metaspace.hpp > - Update metaspace.hpp > - ... and 4 more: https://git.openjdk.org/jdk/compare/640b71da...6cc648c7 src/hotspot/share/oops/metadata.hpp line 33: > 31: #include "utilities/ostream.hpp" > 32: > 33: #define BUILD_32(i16_h, i16_l) ( ((unsigned)i16_h << 16) | i16_l ) Macro is unused now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2287468286 From duke at openjdk.org Wed Aug 20 09:00:30 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Wed, 20 Aug 2025 09:00:30 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/79a3323a..f29d5af4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=09-10 Stats: 74 lines in 4 files changed: 22 ins; 45 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From stuefe at openjdk.org Wed Aug 20 09:05:19 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 20 Aug 2025 09:05:19 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v6] In-Reply-To: References: Message-ID: > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: remove stray macro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25891/files - new: https://git.openjdk.org/jdk/pull/25891/files/6cc648c7..b3feb6ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From cnorrbin at openjdk.org Wed Aug 20 09:10:40 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 20 Aug 2025 09:10:40 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 08:54:51 GMT, Casper Norrbin wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - feedback Caspar >> - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use >> - Feedback Johan >> - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use >> - merge master >> - copyrights >> - fix big-endian problem on AIX >> - Update klass.cpp >> - Update metaspace.hpp >> - Update metaspace.hpp >> - ... and 4 more: https://git.openjdk.org/jdk/compare/640b71da...6cc648c7 > > src/hotspot/share/oops/metadata.hpp line 33: > >> 31: #include "utilities/ostream.hpp" >> 32: >> 33: #define BUILD_32(i16_h, i16_l) ( ((unsigned)i16_h << 16) | i16_l ) > > Macro is unused now Including the `#undef BUILD_32` :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2287506770 From mli at openjdk.org Wed Aug 20 09:27:32 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 09:27:32 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v2] In-Reply-To: References: Message-ID: <9eVOWQms8n3ok8h-AlpMmJE5o00TfVtrNp3avFE2XFg=.b7af9dd4-c0a2-454e-b04f-4a8d57aa9ca0@github.com> > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: minors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26838/files - new: https://git.openjdk.org/jdk/pull/26838/files/3f834dfd..42858774 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=00-01 Stats: 12 lines in 4 files changed: 3 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From mli at openjdk.org Wed Aug 20 09:27:34 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 09:27:34 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v2] In-Reply-To: <2uVYeF6NbvyhXG8DddOsSqpCN5uQ5VMI2OKtgbYjmqI=.f098a0f3-b854-4da9-9b52-8825dbe27012@github.com> References: <2uVYeF6NbvyhXG8DddOsSqpCN5uQ5VMI2OKtgbYjmqI=.f098a0f3-b854-4da9-9b52-8825dbe27012@github.com> Message-ID: On Wed, 20 Aug 2025 03:12:48 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> minors > > src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2394: > >> 2392: __ bind(stub.entry()); >> 2393: >> 2394: __ float_to_float16_NaN(src, dst, t0, t1); > > I see `t1` which is the rFlagsReg register for riscv is passed as a temp register. But this side effect (clobbering of `t1`) doesn't reflect on the callsite `float_to_float16` in `instruct convF2HF_reg_reg`. So I guess you might want to pass `tmp` instead of `t1` here. Like: `__ float_to_float16_NaN(src, dst, t0, tmp);` Nice catch! it's a typo, fixed. > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5959: > >> 5957: // this is a utility method to process the slow path of NaN when converting float to float16 >> 5958: // check j.l.Float.floatToFloat16 >> 5959: void MacroAssembler::float_to_float16_NaN(FloatRegister src, Register dst, > > Can you swap the first two params? I perfer to have `dst` which holds the result as the first one. I think that's what we always do for other assembler routines as well. sure ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287549482 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287549915 From mli at openjdk.org Wed Aug 20 09:29:36 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 09:29:36 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v2] In-Reply-To: <2uVYeF6NbvyhXG8DddOsSqpCN5uQ5VMI2OKtgbYjmqI=.f098a0f3-b854-4da9-9b52-8825dbe27012@github.com> References: <2uVYeF6NbvyhXG8DddOsSqpCN5uQ5VMI2OKtgbYjmqI=.f098a0f3-b854-4da9-9b52-8825dbe27012@github.com> Message-ID: On Wed, 20 Aug 2025 07:35:52 GMT, Fei Yang wrote: > Thanks for fixing this! I have several comments. BTW: I assume you have checked `float16_to_float_slow_path` as well? Does it need a fix? Thank for having a look. I think so. In this case, it does not lose any information in NaN. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26838#issuecomment-3205121494 From mli at openjdk.org Wed Aug 20 09:32:57 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 09:32:57 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v3] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26838/files - new: https://git.openjdk.org/jdk/pull/26838/files/42858774..7f9268ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From mli at openjdk.org Wed Aug 20 09:32:58 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 09:32:58 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v3] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 14:20:23 GMT, Andrey Turbanov wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> typo > > test/hotspot/jtreg/compiler/intrinsics/float16/Binary16ConversionNaN_2.java line 144: > >> 142: >> 143: private static float testRoundTrip(float f) { >> 144: short s = Float.floatToFloat16(f); > > Suggestion: > > short s = Float.floatToFloat16(f); Thanks, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287566436 From duke at openjdk.org Wed Aug 20 09:39:41 2025 From: duke at openjdk.org (Ruben) Date: Wed, 20 Aug 2025 09:39:41 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Tue, 19 Aug 2025 11:42:50 GMT, Martin Doerr wrote: >> Ruben has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Tier 1 has passed on linux ppc64le. Nice cleanup! Thank you for running the tests @TheRealMDoerr, @RealFYang, @offamitkumar. @dafedafe, could you approve if the patch looks good, please? (there have been no code changes since your last comment) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3205174580 From jbhateja at openjdk.org Wed Aug 20 10:11:47 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 20 Aug 2025 10:11:47 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Update callGenerator.hpp copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/70c22932..340f1849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From azafari at openjdk.org Wed Aug 20 10:30:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 20 Aug 2025 10:30:37 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> <_V9WS-34rEFeSXcQmB1MPQCvHGzYJIjEcl3BFFCB1hE=.4168bee1-7452-4266-b40e-4e7a28888ab7@github.com> Message-ID: On Sun, 17 Aug 2025 12:41:52 GMT, Kim Barrett wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 1079: >> >>> 1077: return result; >>> 1078: } >>> 1079: >> >> This still has an overflowing left shift, and it's hard for the reader to follow. >> >> I'd do something like this: >> >> >> inline void set_low (jlong* value, jint low ) { >> union { >> jlong value_s; >> julong value_u; >> }; >> value_s = *value; >> value_u = (value_u & ~(julong)0xffffffff) | (julong)low; >> *value = value_s; >> } >> >> inline void set_high(jlong* value, jint high) { >> union { >> jlong value_s; >> julong value_u; >> }; >> value_s = *value; >> value_u = (value_u & (julong)0xfffffffful) | ((julong)high << 32); >> *value = value_s; >> } > > First, we do not care about left shift of negative value on its own > (JDK-8240259). Indicating this issue has anything to do with that is just > confusing matters. > > What we care about is signed integer overflow, which is UB. And there is > indeed such overflow in this code. Having the JBS issue and the PR description > be more direct about that would have avoided confusion on my part. > > (I'm somewhat surprised none of our compilers just breaks this obvious > overflow. Or maybe they do and we've not noticed, though that seems unlikely.) > > As @theRealAph points out, the proposed change still contains overflows. For example > > 1061: *value &= (jlong)0xffffffff << 32; > > > But this can be vastly simplified to just > > inline jlong jlong_from(jint h, jint l) { > // First cast jint values to juint, so cast to julong will zero-extend. > julong high = (julong)(juint)h << 32; > julong low = (julong)(juint)l; > return (jlong)(high | low); > } > > and delete the now unused set_high and set_low functions. (There are set_high > and set_low functions in sharedRuntimeMath.hpp, but they deal with double > rather than jlong.) I am aware of not caring the issues of 'left-shift of negative values' since after C++20 they will not be UB anymore. I use UBSAN left-shift checks for finding other hidden/potential problems around left-shifts. Sorry if missing enough explanation in title and/or description parts brought you confusion. AFAIU, the code `(jlong)0xffffffff << 32` is not problematic since `jlong` is 64 bits and `0xffffffff` is `unsigned int` then casting to `jlong` makes it as `0x00000000ffffffff` and shifting it 32 bits to left results in `0xffffffff00000000` which means the the result is still representable with no loss. What am I missing here? So, if my understanding above is correct, there will be no issue in these two functions since left-shift o f negative values are to be ignored for now. IOW, we can close this PR without integration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2287721038 From ayang at openjdk.org Wed Aug 20 10:41:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 20 Aug 2025 10:41:44 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit src/hotspot/share/memory/universe.cpp line 1318: > 1316: } > 1317: > 1318: const double vm_thread_cpu_time = (double) CPUTimeUsage::Runtime::vm_thread() / NANOSECS_PER_SEC; Does `vm_thread_cpu_time` include gc-vm-thread time? Looking at how it's printed, "VM Thread" and "Garbage Collection" are two separate lines, suggesting there are no overlapping btw them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287752295 From duke at openjdk.org Wed Aug 20 10:41:44 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Wed, 20 Aug 2025 10:41:44 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> References: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> Message-ID: On Tue, 12 Aug 2025 19:54:14 GMT, Yuri Gaevsky wrote: >> Hello All, >> >> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. >> >> Thank you, >> -Yuri Gaevsky >> >> **Correctness checks:** >> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. > > Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check for zero length; changed lmul from m8 to m2. More performance data for m2 vs m4 vs m8: ========================================================================================================================== -XX:-UseRVV -XX:+UseRVV(m2) -XX:+UseRVV(m4) -XX:+UseRVV(m8) ========================================================================================================================== Benchmark (size) Mode Cnt Score Error Score Error Score Error Score Error Units Int.differentSubrangeMatches 100 avgt 10 137.172 ? 0.054 98.497 ? 0.310 79.800 ? 0.279 69.906 ? 0.268 ns/op Int.differentSubrangeMatches 200 avgt 10 156.312 ? 0.281 140.852 ? 0.361 118.496 ? 1.082 103.428 ? 0.425 ns/op Int.differentSubrangeMatches 300 avgt 10 327.659 ? 0.317 191.959 ? 0.440 148.588 ? 1.106 138.767 ? 0.635 ns/op Int.differentSubrangeMatches 400 avgt 10 240.912 ? 0.429 230.264 ? 0.164 179.730 ? 0.306 170.405 ? 0.312 ns/op Int.differentSubrangeMatches 500 avgt 10 523.581 ? 0.292 286.112 ? 0.307 210.887 ? 0.311 172.616 ? 0.517 ns/op Int.differentSubrangeMatches 600 avgt 10 352.296 ? 0.480 322.362 ? 0.924 249.807 ? 0.290 201.274 ? 0.633 ns/op Int.differentSubrangeMatches 700 avgt 10 725.652 ? 0.555 382.037 ? 0.434 278.503 ? 0.633 245.203 ? 0.391 ns/op Int.differentSubrangeMatches 800 avgt 10 455.651 ? 1.003 412.241 ? 0.411 312.572 ? 0.475 271.538 ? 0.319 ns/op -------------------------------------------------------------------------------------------------------------------------- Int.matches 100 avgt 10 143.116 ? 0.627 128.433 ? 0.057 110.221 ? 0.056 95.322 ? 0.049 ns/op Int.matches 200 avgt 10 227.868 ? 0.190 231.481 ? 0.343 172.225 ? 0.052 160.328 ? 0.019 ns/op Int.matches 300 avgt 10 336.983 ? 0.094 301.416 ? 0.279 234.191 ? 0.036 199.844 ? 0.224 ns/op Int.matches 400 avgt 10 440.492 ? 0.503 389.587 ? 0.752 312.521 ? 0.103 259.867 ? 0.030 ns/op Int.matches 500 avgt 10 524.292 ? 0.828 490.197 ? 1.283 362.972 ? 0.847 297.545 ? 0.140 ns/op Int.matches 600 avgt 10 627.717 ? 0.880 577.573 ? 0.764 420.304 ? 0.086 361.774 ? 0.720 ns/op Int.matches 700 avgt 10 730.503 ? 0.281 719.430 ? 0.278 487.603 ? 2.297 397.502 ? 0.467 ns/op Int.matches 800 avgt 10 831.331 ? 0.446 810.678 ? 0.482 580.438 ? 0.966 472.532 ? 0.484 ns/op -------------------------------------------------------------------------------------------------------------------------- Int.mismatchEnd 100 avgt 10 133.878 ? 0.434 106.791 ? 0.056 82.681 ? 0.070 86.513 ? 0.050 ns/op Int.mismatchEnd 200 avgt 10 220.972 ? 1.055 223.622 ? 0.110 170.348 ? 0.415 159.113 ? 0.195 ns/op Int.mismatchEnd 300 avgt 10 326.363 ? 0.069 294.368 ? 0.076 230.101 ? 0.934 190.400 ? 0.042 ns/op Int.mismatchEnd 400 avgt 10 432.284 ? 0.311 380.235 ? 0.096 288.662 ? 0.049 252.551 ? 0.123 ns/op Int.mismatchEnd 500 avgt 10 512.964 ? 0.139 466.615 ? 0.135 370.821 ? 0.071 285.593 ? 0.080 ns/op Int.mismatchEnd 600 avgt 10 613.120 ? 0.291 568.137 ? 0.120 414.635 ? 0.074 356.367 ? 0.084 ns/op Int.mismatchEnd 700 avgt 10 716.861 ? 0.667 709.291 ? 0.571 476.794 ? 0.399 404.384 ? 0.494 ns/op Int.mismatchEnd 800 avgt 10 821.902 ? 0.564 740.929 ? 0.241 542.111 ? 1.102 456.066 ? 0.119 ns/op -------------------------------------------------------------------------------------------------------------------------- Int.mismatchMid 100 avgt 10 84.289 ? 0.221 77.660 ? 0.018 63.073 ? 0.145 53.226 ? 0.010 ns/op Int.mismatchMid 200 avgt 10 142.339 ? 0.228 120.884 ? 0.037 102.706 ? 0.020 86.411 ? 0.014 ns/op Int.mismatchMid 300 avgt 10 170.238 ? 0.248 164.259 ? 0.457 127.066 ? 0.624 120.582 ? 0.147 ns/op Int.mismatchMid 400 avgt 10 221.964 ? 0.555 207.503 ? 0.126 164.960 ? 0.069 152.796 ? 0.026 ns/op Int.mismatchMid 500 avgt 10 275.343 ? 0.848 252.248 ? 0.395 187.275 ? 0.017 157.191 ? 0.032 ns/op Int.mismatchMid 600 avgt 10 322.031 ? 0.173 317.887 ? 0.314 226.728 ? 0.052 186.001 ? 0.040 ns/op Int.mismatchMid 700 avgt 10 371.653 ? 0.259 337.068 ? 0.069 247.348 ? 0.034 219.186 ? 0.051 ns/op Int.mismatchMid 800 avgt 10 419.094 ? 0.087 394.663 ? 0.231 288.703 ? 0.094 252.383 ? 0.078 ns/op -------------------------------------------------------------------------------------------------------------------------- Int.mismatchStart 100 avgt 10 28.920 ? 0.179 34.449 ? 0.015 40.712 ? 0.007 53.854 ? 0.011 ns/op Int.mismatchStart 200 avgt 10 28.845 ? 0.051 35.706 ? 0.022 40.710 ? 0.008 53.853 ? 0.007 ns/op Int.mismatchStart 300 avgt 10 28.928 ? 0.051 34.444 ? 0.008 40.704 ? 0.017 53.234 ? 0.011 ns/op Int.mismatchStart 400 avgt 10 29.369 ? 0.127 35.698 ? 0.008 40.702 ? 0.005 53.226 ? 0.011 ns/op Int.mismatchStart 500 avgt 10 29.953 ? 0.595 34.488 ? 0.045 40.709 ? 0.017 54.288 ? 0.837 ns/op Int.mismatchStart 600 avgt 10 28.809 ? 0.008 34.459 ? 0.011 41.957 ? 0.008 53.232 ? 0.009 ns/op Int.mismatchStart 700 avgt 10 28.930 ? 0.124 35.702 ? 0.009 40.984 ? 0.092 54.495 ? 0.008 ns/op Int.mismatchStart 800 avgt 10 28.814 ? 0.017 35.697 ? 0.009 40.711 ? 0.012 54.487 ? 0.013 ns/op ========================================================================================================================== I would say that m4 looks more or less better in general for `sizes >=100` than m2 and/or m8. WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3205509437 From adinn at openjdk.org Wed Aug 20 11:18:41 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Aug 2025 11:18:41 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: On Wed, 20 Aug 2025 08:44:30 GMT, Andrew Haley wrote: > OK, so we should not commit this patch. it's not worth it. I think Andrew is right that the gain here is too small to justify the extra complexity this adds, including for AOT code. There is no clear performance difference between the two variants across different micro-architectures. The saving in instruction count is real but is not going to be very significant (pointer moves are rare and not all of them will be susceptible to this optimization). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3205716082 From fyang at openjdk.org Wed Aug 20 11:52:38 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 20 Aug 2025 11:52:38 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v3] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 09:32:57 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > typo Thanks for the quick update. Looks good modulo two minor comments about code style. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5970: > 5968: // bits into lower 9 bits of binary 16 significand. > 5969: // > 5970: // check j.l.Float.floatToFloat16 for more information. Suggestion: `// Check j.l.Float.floatToFloat16 for more information.` src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5978: > 5976: orr(tmp2, tmp2, tmp1); > 5977: andi(tmp1, dst, 0xf); > 5978: orr(dst, tmp2, tmp1); Suggestion for adding some extra code comment to help understand the numbers: // 10 bits slli(tmp1, dst, 9 + 32); srli(tmp1, tmp1, 9 + 32 + 13); orr(tmp2, tmp2, tmp1); // 9 bits slli(tmp1, dst, 19 + 32); srli(tmp1, tmp1, 19 + 32 + 4); orr(tmp2, tmp2, tmp1); // 4 bits andi(tmp1, dst, 0xf); orr(dst, tmp2, tmp1); ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3136217621 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287913244 PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2287911692 From dholmes at openjdk.org Wed Aug 20 12:28:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 12:28:38 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov wrote: > The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. Some alignment nits where you have added additional condition clauses. Some of these are difficult to evaluate in isolation and will need review from the specific component areas. src/hotspot/share/adlc/output_h.cpp line 1952: > 1950: }*/ > 1951: else if( instr->is_ideal_copy() && > 1952: (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) && Suggestion: (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) && src/hotspot/share/c1/c1_LinearScan.cpp line 4422: > 4420: > 4421: if ((cur != nullptr) && > 4422: (cur->from() < split_pos)) { Suggestion: (cur->from() < split_pos)) { src/hotspot/share/nmt/mallocSiteTable.cpp line 172: > 170: index < pos_idx && head != nullptr; > 171: index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head : > 172: (MallocSiteHashtableEntry*)head->next()) {} This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null. src/hotspot/share/opto/vectorIntrinsics.cpp line 1319: > 1317: log_if_needed(" ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no", > 1318: is_scatter, is_scatter ? "scatter" : "gather", > 1319: num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type())); There is a bug here but I'm not sure it is what you think it is. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26798#pullrequestreview-3136325292 PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287976814 PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287984002 PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287993050 PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287996530 From dholmes at openjdk.org Wed Aug 20 12:32:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 12:32:42 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov wrote: > The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. I've added some additional mailing lists to ensure better coverage here. Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206112684 From mli at openjdk.org Wed Aug 20 12:35:47 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 12:35:47 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v4] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26838/files - new: https://git.openjdk.org/jdk/pull/26838/files/7f9268ea..9eef4961 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From mli at openjdk.org Wed Aug 20 12:35:48 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Aug 2025 12:35:48 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v3] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 11:49:21 GMT, Fei Yang wrote: > Thanks for the quick update. Looks good modulo two minor comments about code style. Thank you! Comments updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26838#issuecomment-3206117451 From dholmes at openjdk.org Wed Aug 20 12:36:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 12:36:41 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add HYBRID to CPUFeature in JVMCI Seems to me that if your issue is that `(7 cores per cpu, 2 threads per core) ` is an incorrect description then `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. If we can't get accurate/reliable core and thread counts then maybe we should not report anything in that part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3206131900 From duke at openjdk.org Wed Aug 20 12:39:37 2025 From: duke at openjdk.org (Samuel Chee) Date: Wed, 20 Aug 2025 12:39:37 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 13:42:19 GMT, Samuel Chee wrote: >> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. >> >> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. >> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. >> >> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > > Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd > - Refine code generation for mem2reg_volatile > > The patch is contributed by @theRealAph. > > Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 Also have just finished running jcstress and it seems to pass fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3206150519 From dholmes at openjdk.org Wed Aug 20 12:43:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 12:43:40 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2] In-Reply-To: References: Message-ID: <5Ek03nIMubMQj-MaRNWRE4joIwv5GR-260AOA__AlZs=.5cd6bfdf-6a6f-44ec-a188-cf779ca85f79@github.com> On Tue, 19 Aug 2025 15:58:52 GMT, Samuel Chee wrote: >> According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: >> >>> Atomically sets the value of a variable to the newValue with the >>> memory semantics of setVolatile if the variable's current value, >>> referred to as the witness value, == the expectedValue, as accessed >>> with the memory semantics of getVolatile. >> >> Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. >> >> Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). >> >> The unused cmpxchgw is removed. >> >> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) > > Samuel Chee has updated the pull request incrementally with one additional commit since the last revision: > > Merge master fix > > Change-Id: I74d44f711de208395bce47595fecd801564bcb54 Not sure why you are using the specification for the Java API cmpxchg function to determine what the MacroAssembler function does?? Is this the intrinsic for the Java code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3206161458 From dholmes at openjdk.org Wed Aug 20 12:55:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 12:55:43 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> References: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> Message-ID: On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan wrote: >> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). >> >> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma. > > But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed. > > The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1 @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288072431 From dholmes at openjdk.org Wed Aug 20 13:04:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 13:04:38 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Wed, 20 Aug 2025 04:42:23 GMT, Thomas Stuefe wrote: >> flush, sure. but closing and deleting seems to be asking for trouble. > > I agree with @kimbarrett . Apart from stability, it is also just unnecessary work. We have been doing it for a very long time now and aside from this order-of-operations issue it has worked fine. Changing that aspect of it seems a complete unknown to me and not worth any potential risk. And we delete a lot of things at VM shutdown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26832#discussion_r2288095772 From ihse at openjdk.org Wed Aug 20 13:12:47 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Aug 2025 13:12:47 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: On Wed, 20 Aug 2025 07:10:16 GMT, Axel Boldt-Christmas wrote: > There are now a bunch of unconditional includes for JVM features which can be disabled. Hm. Either there is a bug in @fandreuz script, or these files are still included even if you disable all features. The list of unconditional includes is supposed to be generated by building a JVM with no features at all enabled (with the possible exception of epsilon-gc; I believe having at least one GC is a requirement), and then checking which files are indeed included. My guess is that the logic is not so much as "don't include file c1_foo unless C1 is enabled", as "in c1_foo, guard all contents with an ifdef on C1". So then this is what you'd see in that case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3206277753 From fgao at openjdk.org Wed Aug 20 14:10:42 2025 From: fgao at openjdk.org (Fei Gao) Date: Wed, 20 Aug 2025 14:10:42 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: On Wed, 20 Aug 2025 08:44:30 GMT, Andrew Haley wrote: > > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. > > Or code should be the same. Would it make sense to disable the reachability-based optimization when `AOTCodeCache::is_on()` returns true? In this case, we would always emit `mov` triples for foreign calls if AoT is involved, whether dumping or using the AoT code cache. For calls that must relocate into the code cache, we already always emit `adrp + add`, ensuring consistent behavior regardless of whether the code is AOT-compiled or JIT-compiled. What do you think? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3206574431 From kbarrett at openjdk.org Wed Aug 20 14:19:40 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Aug 2025 14:19:40 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Sun, 17 Aug 2025 06:49:47 GMT, Afshin Zafari wrote: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3136854093 From kbarrett at openjdk.org Wed Aug 20 14:19:41 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Aug 2025 14:19:41 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> <_V9WS-34rEFeSXcQmB1MPQCvHGzYJIjEcl3BFFCB1hE=.4168bee1-7452-4266-b40e-4e7a28888ab7@github.com> Message-ID: <2YJQo5SuIo7dZhnA_7R3ZrFHHjtF3zBqG3eKSQYDO9A=.ac738369-1a97-4bb8-bc6a-c2d93d399820@github.com> On Wed, 20 Aug 2025 10:28:05 GMT, Afshin Zafari wrote: >> First, we do not care about left shift of negative value on its own >> (JDK-8240259). Indicating this issue has anything to do with that is just >> confusing matters. >> >> What we care about is signed integer overflow, which is UB. And there is >> indeed such overflow in this code. Having the JBS issue and the PR description >> be more direct about that would have avoided confusion on my part. >> >> (I'm somewhat surprised none of our compilers just breaks this obvious >> overflow. Or maybe they do and we've not noticed, though that seems unlikely.) >> >> As @theRealAph points out, the proposed change still contains overflows. For example >> >> 1061: *value &= (jlong)0xffffffff << 32; >> >> >> But this can be vastly simplified to just >> >> inline jlong jlong_from(jint h, jint l) { >> // First cast jint values to juint, so cast to julong will zero-extend. >> julong high = (julong)(juint)h << 32; >> julong low = (julong)(juint)l; >> return (jlong)(high | low); >> } >> >> and delete the now unused set_high and set_low functions. (There are set_high >> and set_low functions in sharedRuntimeMath.hpp, but they deal with double >> rather than jlong.) > > I am aware of not caring the issues of 'left-shift of negative values' since after C++20 they will not be UB anymore. I use UBSAN left-shift checks for finding other hidden/potential problems around left-shifts. > > Sorry if missing enough explanation in title and/or description parts brought you confusion. > > AFAIU, the code `(jlong)0xffffffff << 32` is not problematic since `jlong` is 64 bits and `0xffffffff` is `unsigned int` then casting to `jlong` makes it as `0x00000000ffffffff` and shifting it 32 bits to left results in `0xffffffff00000000` which means the the result is still representable with no loss. What am I missing here? > > So, if my understanding above is correct, there will be no issue in these two functions since left-shift o f negative values are to be ignored for now. IOW, we can close this PR without integration. `(jlong)0xffffffff << 32` is a (obvious) signed integer overflow. It's a signed shift, and the sign bit changes. However, there was a subtle but intentional change in C++14 that permits this specific overflow case. A signed left shift that moves a 1 bit into the sign bit position (but not beyond!) is permitted. The actual wording is C++14 5.8/2 "[...] if E1 has a signed type and non-negative value, and E1?2E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; [...]" C++11 5.8/2 "[...] if E1 has a signed type and non-negative value, and E1?2E2 is representable in the result type, then that is the resulting value; [...]" So that code has an overflow that is UB in C++11 and earlier, but it's not UB in C++14 and later. That's all very complicated and subtle analysis. I think my proposed alternative skips all, is very straightforward to understand, and insulates us from any future explorations of the sort that led us here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2288334648 From adinn at openjdk.org Wed Aug 20 14:22:37 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Aug 2025 14:22:37 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov wrote: > The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. I'm not clear that the original issue is necessarily a bug that needs fixing with a skip to the next else if case. The justification for adding `instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr` to the if branch test is that earlier code allows for the possibility that `instr->_matrule` might be null. However, that check is performed in an unconditional context for any value of `instr` whereas this specific else branch limits the circumstance to the case where `instr->is_ideal_copy()` is found to be true. So, the prior test offers no guarantee that in this restricted case a null pointer should or should not be possible. The original design may assume that a successful test for `instr->is_ideal_copy()` ought to guarantee that both `instr->_matrule` and `instr->_matrule->_rChild` are non-null. That cannot be determined by the evidence offered. It can only be determined by looking at how instr is constructed. So, rather than just skip to the next case we might need to handle this with an assert and fix whatever code is producing an ideal copy with null fields. Given the level of analysis offered for this case I am suspicious as to whether the other cases tacked onto this issue ought to be accepted at face value without some justification as to why a null check and skip to the next case is correct. I'm also wondering how and why all these cases and associated amendments were arrived at? Is this perhaps based on output from a code analysis tool (perhaps even a genAI tool). If so then I think 1) we ought to be told and 2) we ought to treat its recommendations with a very healthy dose of skepticism. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206613521 From syan at openjdk.org Wed Aug 20 14:28:43 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 20 Aug 2025 14:28:43 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> Message-ID: On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes wrote: >> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed. >> >> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1 > > @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout. Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests. So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593). I do agree this change, what I mean is this change has some side effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288361080 From adinn at openjdk.org Wed Aug 20 14:34:40 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Aug 2025 14:34:40 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: <_9u93d5tL5YjjDV4CyNjlKwVrNOQQ8Lt0VSGKClDw6c=.cd45cdc4-2057-4ce7-8eaa-a929de9536a2@github.com> On Wed, 20 Aug 2025 14:07:42 GMT, Fei Gao wrote: >>> > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >>> >>> Or code should be the same. >> >> OK, so we should not commit this patch. it's not worth it. > >> > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >> >> Or code should be the same. > > Would it make sense to disable the reachability-based optimization when `AOTCodeCache::is_on()` returns true? > In this case, we would always emit `mov` triples for foreign calls if AoT is involved, whether dumping or using the AoT code cache. > > For calls that must relocate into the code cache, we already always emit `adrp + add`, ensuring consistent behavior regardless of whether the code is AOT-compiled or JIT-compiled. > > What do you think? Thanks! @fg1417 > Would it make sense to disable the reachability-based optimization when AOTCodeCache::is_on() returns true? If we were to proceed with this patch then yes I guess that would be the easiest way to proceed. However, @theRealAph's argument was that we should not proceed with this optimization because it adds extra code complexity (i.e. a maintenance burden) with no guarantee of a noticeable performance gain. I agree with that argument. Bypassing the optimization in the AOT case does not help to reduce complexity or improve the performance so it does not change that argument. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3206673353 From duke at openjdk.org Wed Aug 20 14:36:53 2025 From: duke at openjdk.org (Samuel Chee) Date: Wed, 20 Aug 2025 14:36:53 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2] In-Reply-To: References: Message-ID: <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com> On Tue, 19 Aug 2025 15:58:52 GMT, Samuel Chee wrote: >> According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]: >> >>> Atomically sets the value of a variable to the newValue with the >>> memory semantics of setVolatile if the variable's current value, >>> referred to as the witness value, == the expectedValue, as accessed >>> with the memory semantics of getVolatile. >> >> Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen. >> >> Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB). >> >> The unused cmpxchgw is removed. >> >> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...) > > Samuel Chee has updated the pull request incrementally with one additional commit since the last revision: > > Merge master fix > > Change-Id: I74d44f711de208395bce47595fecd801564bcb54 You're right, it is a little inaccurate to use the Java API to determine what `cmpxchgptr` does. Although the original intent to remove the membar is still functionality correct. Although looking into it more, it seems that `cmpxchgptr` can now be removed completely. The recent PR https://github.com/openjdk/jdk/pull/26594 removed two of its call sites, and the only other existing one is within `MacroAssembler::cmpxchg_obj_header` - a method which never gets called to. So I propose: - We close this pr - Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3206680482 From lmesnik at openjdk.org Wed Aug 20 14:43:44 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 14:43:44 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v11] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/67d87dbb..106e5a1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From kbarrett at openjdk.org Wed Aug 20 14:47:43 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Aug 2025 14:47:43 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: <1bLU50VrPIETq3MpOLq605JqdlCQ-f17dsuJ2Lp4LrY=.8e78ccfd-78d6-46fc-8306-ab5466ecd45a@github.com> On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. doc/cpp17-features.md line 1103: > 1101: Template template parameters are barely used (if at all) in HotSpot. > 1102: > 1103: [n4051](http://wg21.link/n4051) I'm moving this to the permitted category, after realizing that I'd unknowingly used it in some exploratory work I'm conducting. Artifically disallowing this syntactic regularization serves no useful purpose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2288416731 From pchilanomate at openjdk.org Wed Aug 20 14:49:45 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 20 Aug 2025 14:49:45 GMT Subject: RFR: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error [v4] In-Reply-To: References: Message-ID: <55Ml_wR48M8X3fKTXPkiMLlyJpWsjN-Gaca-kFxYmFI=.30f75410-2a83-479d-8ed1-7bc01b6576fa@github.com> On Tue, 19 Aug 2025 20:52:12 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> use existing badAddressVal > > Updates look good. Thanks Thanks for the reviews @dholmes-ora, @fbredber and @coleenp! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26660#issuecomment-3206733361 From lmesnik at openjdk.org Wed Aug 20 14:52:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 14:52:41 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: On Wed, 20 Aug 2025 07:41:48 GMT, David Holmes wrote: > Still struggling with this part. So the method exited normally then as part of event processing a Java upcall can raise an exception? But according to the spec any such exceptions get dropped - so is the flag just to do the dropping? Vice versa. The exception is thrown in "usual" method. Usually, the stack is unwinded until exception is caught. However, it is possible to call the method (using upCall) in the middle of this process. And this 'upCall' method doesn't throw or caught any exceptions. Should just work normally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3206745557 From pchilanomate at openjdk.org Wed Aug 20 14:52:48 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 20 Aug 2025 14:52:48 GMT Subject: Integrated: 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error In-Reply-To: References: Message-ID: On Wed, 6 Aug 2025 16:52:23 GMT, Patricio Chilano Mateo wrote: > Please review the following small change. On linux-aarch64, ASan reports an overflow error on a read that occurs when frames are copied from the stack to the heap?specifically during preemption on monitorenter and Object.wait when coming from compiled code. This read is benign and comes from reading either all (freeze fast path case) or part (freeze slow path case) of the `frame::metadata_words_at_bottom` stored in the callee frame (return pc+fp) for the top frame. In these preemption cases the callee frame is the frame of the VM native method being called (e.g. `Runtime1::monitorenter`). Now, the Arm 64-bit ABI doesn't specify a location where the frame record (returnpc+fp) has to be stored within a stack frame and GCC currently chooses to save it at the top of the frame (lowest address). So this causes ASan to treat the memory access in the callee as an overflow access to one of the locals stored in that frame. > > Accessing the callee to read `frame::metadata_words_at_bottom` is only necessary when the top frame is compiled. In that case, the callee is `Continuation.doYield` and those words contain the return pc and fp of the top frame we are freezing, where possibly fp might contain an oop. For the preemption cases mentioned above though, the return pc used for the top frame is always the one from the anchor, not the stack. Also, there is never a callee saved value in fp that needs to be preserved, the fp is always constructed again when thawing the frame. But because of sharing the code path with the compiled frame case we also read these words. I?ve added the full details on where these memory accesses occur in the freeze code, both slow and fast paths, in the bug comments. > > The fix is to adjust these shared paths to avoid the read in the preemption case. I was able to reproduce the issue and have verified it is now fixed. I also ran the patch through mach5 tiers1-7. > > Thanks, > Patricio This pull request has now been integrated. Changeset: ebf5ae84 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/ebf5ae8435e27e4315e43237b1167a1e99150393 Stats: 71 lines in 9 files changed: 58 ins; 0 del; 13 mod 8359222: [asan] jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest triggers stack-buffer-overflow error Reviewed-by: dholmes, fbredberg, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/26660 From kvn at openjdk.org Wed Aug 20 14:58:41 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 20 Aug 2025 14:58:41 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: <_9u93d5tL5YjjDV4CyNjlKwVrNOQQ8Lt0VSGKClDw6c=.cd45cdc4-2057-4ce7-8eaa-a929de9536a2@github.com> References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> <_9u93d5tL5YjjDV4CyNjlKwVrNOQQ8Lt0VSGKClDw6c=.cd45cdc4-2057-4ce7-8eaa-a929de9536a2@github.com> Message-ID: <1uFv5fS6e7wFrN4XeW1UmIthp_EBQFu_UsglwyvhA9U=.ae3c3a96-e410-42ab-a7a3-c60990beed59@github.com> On Wed, 20 Aug 2025 14:31:50 GMT, Andrew Dinn wrote: > Would it make sense to disable the reachability-based optimization when AOTCodeCache::is_on() returns true? AOTCodeCache::_cache is set in AOTCodeCache::init2() which is called after universe_init() and some stubs are generated. There are runtime calls in stubs which we may need to adjust using temporary `cache` value created in AOTCodeCache::initialize(). So we can't rely on AOTCodeCache::is_on() in production run for this. Yes, it is complicated "dance" to make sure AOT is working properly. We can use AOTCodeCache::is_caching_enabled() instead which simple checks flags set during flags parsing. But it also not reliable because flags could be adjust later when we later load AOT code cache and check its compatibility. I agree with both Andrews that this change seems don't provide much benefits to accept it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3206768915 From lmesnik at openjdk.org Wed Aug 20 15:02:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 15:02:39 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com> References: <2NdrVGCIXOMEsF4QnPvEpBUAIUuF8qIHCvivRQWdVqk=.e37d6998-5bab-45f9-964c-5109f57cb58d@github.com> <26kP5LTWrJHRbvmuSG5B2VCz2I_yrUEk-ijYa87NTk4=.bef450a6-f47e-45d5-8fc5-2a6ad18af602@github.com> <7K0TQY1mJpEYAuY4KLK8GJJupooahpMEQOdiVLTNRm4=.bd623d94-e03c-4890-b803-973226de8e43@github.com> Message-ID: On Wed, 20 Aug 2025 07:34:04 GMT, David Holmes wrote: >> The test name would be >> test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/ExceptionOccurred.java >> I don't like this duplication. > > It is common to use a `Test` prefix on the actual file so we have directory `foo`, containing `TestFoo.java` and `libFoo.cpp` (or 'libTestFoo.cpp`). The point is that all the source files for one test reside in the same directory unless a different structure is needed for some reason. Placing the native code in its own subdirectory looks very odd to me. But of course there is no general consistency here and it depends on who wrote the test cases and when. let me rename it to serviceability/jvmti/events/MethodExit/PendingException/TestMethodExitWithPendingException.java is ti make more clear? The "upcall" is used in the test only to call some method in the middle of exception handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2288464868 From lmesnik at openjdk.org Wed Aug 20 15:02:40 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 15:02:40 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: <6WnMC2pVTGGsJvoBNA3DEFTXps1C-RjUzHlfBlVki-I=.b225d746-10fb-4488-bc98-83bf7a0552d1@github.com> On Wed, 20 Aug 2025 07:47:34 GMT, David Holmes wrote: >> The exception was thrown in the current thread/ However, the current method is not unwinded. It is called using JNI while the thread has already thrown but not yet caught exception. >> I thought to name it MethodExitWhileExceptionPending, however full name would be >> serviceability/jvmti/events/MethodExit/MethodExitWhileExceptionPending/MethodExitWhileExceptionPending.java >> so I started to "reduce" it. >> Moved to upper directory and removed MethodExit. Also the state looks similar to 'ExceptionOccurred' for JNI method. Let me know if you have better name in the mind. > > Well `ExceptionExit` is slightly clearer and ties in with `exceptionExit()`. > > Before this fix what happens if you run this test case? Before my fix, the MethodExit for 'upCall' method has been called with was_popped_by_exception = true and return_value = nullptr, like it existed with popping exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2288451146 From duke at openjdk.org Wed Aug 20 15:14:34 2025 From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 20 Aug 2025 15:14:34 GMT Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics Message-ID: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Hi all, The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. ------------- Commit messages: - Remove deoptimization statistics dead code. Changes: https://git.openjdk.org/jdk/pull/26744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26744&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365378 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26744/head:pull/26744 PR: https://git.openjdk.org/jdk/pull/26744 From ihse at openjdk.org Wed Aug 20 15:19:42 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Aug 2025 15:19:42 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > after suggestion from Daniel doc/testing.md line 385: > 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a > 384: certain amount of time will apply this factor. If we run in > 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) I don't think there is any point linking to the build source code. Suggestion: certain amount of time will apply this factor. If you run in forced compilation mode (`-Xcomp`) using `make test`, it will automatically adjust this factor to compensate for the interpreter not being as fast as JITed code. Defaults to 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288510800 From ihse at openjdk.org Wed Aug 20 15:24:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Aug 2025 15:24:39 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com> On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > after suggestion from Daniel It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run. I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3206865824 From jsikstro at openjdk.org Wed Aug 20 15:43:55 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 20 Aug 2025 15:43:55 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> References: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> Message-ID: On Wed, 20 Aug 2025 07:19:36 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewer's comments src/hotspot/os/windows/os_windows.cpp line 4167: > 4165: BOOL res = GlobalMemoryStatusEx(&ms); > 4166: if (res != TRUE) > 4167: { To fit in with the surrounding style, the '{' should be moved to the same line as the if-statement. Suggestion: if (res != TRUE) { src/hotspot/share/gc/shared/gcInitLogger.cpp line 66: > 64: void GCInitLogger::print_memory() { > 65: size_t memory = os::physical_memory(); > 66: log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory)); Here as well. src/hotspot/share/gc/z/zLargePages.cpp line 35: > 33: > 34: const size_t memory = os::physical_memory(); > 35: log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory)); I would like to see PROPERFMT + PROPERFMTARGS here instead of the expanded version. src/hotspot/share/runtime/os.hpp line 343: > 341: > 342: static size_t physical_memory(); > 343: static bool has_allocatable_memory_limit(size_t* limit); This is likely a mistake from merging. `static bool has_allocatable_memory_limit(size_t* limit)` was renamed to `static size_t commit_memory_limit()` in [JDK-8364248](https://bugs.openjdk.org/browse/JDK-8364248), so the definition should be removed here. src/hotspot/share/utilities/globalDefinitions.hpp line 1367: > 1365: > 1366: //---------------------------------------------------------------------------------------------------- > 1367: Now I'm bit picky, but I think one line extra here is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288552444 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288548579 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288489717 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288563780 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288562309 From jsikstro at openjdk.org Wed Aug 20 15:43:59 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 20 Aug 2025 15:43:59 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: References: Message-ID: <9mMZXA3hNYC7DcJcPfC1bSmNE3Lmp2VBj8l3Dq7YpW0=.1d85c474-482a-4a25-b26e-c57b60ce746c@github.com> On Tue, 5 Aug 2025 05:12:11 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 26 commits: >> >> - 8357086: Addressed reviewer's comments >> - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs >> - 8357086: Fixed merge conflict >> - 8357086: Removed extra line >> - 8357086: Made physical_memory() return size_t, added dummy ATTRIBUTE_NODISCARD >> - 8357086: Small fixes >> - 8357086: Made physical_memory() return void >> - 8357086: Fixed behavior of total_swap_space on Linux >> - 8357086: Addressed reviewer's comments. >> - 8357086: Fixed void conversion. >> - ... and 16 more: https://git.openjdk.org/jdk/compare/57553ca1...a3898f43 > > src/hotspot/share/runtime/os.hpp line 343: > >> 341: >> 342: static size_t physical_memory(); >> 343: static bool has_allocatable_memory_limit(size_t* limit); > > Future cleanup: for consistency should this now also take a reference? This is no longer relevant as it has been re-worked in [JDK-8364248](https://bugs.openjdk.org/browse/JDK-8364248) to not have an out-parameter and renamed to `static size_t commit_memory_limit()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2288574114 From eastigeevich at openjdk.org Wed Aug 20 15:46:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 20 Aug 2025 15:46:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking Message-ID: There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. Tested fastdebug and release builds: Linux x86_64 and arm64 - The reproducer from JDK-8277444 passed. - Tier1 - tier3 passed. ------------- Commit messages: - 8277444: Race condition on Instrumentation.retransformClasses() and class linking Changes: https://git.openjdk.org/jdk/pull/26863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277444 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From eastigeevich at openjdk.org Wed Aug 20 15:46:46 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 20 Aug 2025 15:46:46 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 15:36:14 GMT, Evgeny Astigeevich wrote: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - Tier1 - tier3 passed. Hi @coleenp, Could you please take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3206937011 From lmesnik at openjdk.org Wed Aug 20 15:54:05 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 15:54:05 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v12] In-Reply-To: References: Message-ID: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: test renamed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/106e5a1f..ce132751 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=10-11 Stats: 116 lines in 3 files changed: 56 ins; 56 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lkorinth at openjdk.org Wed Aug 20 16:27:39 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 20 Aug 2025 16:27:39 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> after suggestion from Daniel > > doc/testing.md line 385: > >> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >> 384: certain amount of time will apply this factor. If we run in >> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) > > I don't think there is any point linking to the build source code. > > Suggestion: > > certain amount of time will apply this factor. If you run in > forced compilation mode (`-Xcomp`) using `make test`, it > will automatically adjust this factor to compensate for the > interpreter not being as fast as JITed code. Defaults to 1. I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288683592 From lmesnik at openjdk.org Wed Aug 20 16:48:56 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Aug 2025 16:48:56 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v13] In-Reply-To: References: Message-ID: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26713/files - new: https://git.openjdk.org/jdk/pull/26713/files/ce132751..d56e3536 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26713&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26713/head:pull/26713 PR: https://git.openjdk.org/jdk/pull/26713 From lkorinth at openjdk.org Wed Aug 20 17:05:59 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 20 Aug 2025 17:05:59 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: update testing.md, remove makefile link, fix bad text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=03-04 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Wed Aug 20 17:05:59 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 20 Aug 2025 17:05:59 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com> On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth wrote: >> doc/testing.md line 385: >> >>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >>> 384: certain amount of time will apply this factor. If we run in >>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) >> >> I don't think there is any point linking to the build source code. >> >> Suggestion: >> >> certain amount of time will apply this factor. If you run in >> forced compilation mode (`-Xcomp`) using `make test`, it >> will automatically adjust this factor to compensate for the >> interpreter not being as fast as JITed code. Defaults to 1. > > I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake). fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288793081 From eastigeevich at openjdk.org Wed Aug 20 17:31:22 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 20 Aug 2025 17:31:22 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - Tier1 - tier3 passed. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Add missing include runtime/synchronizer.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26863/files - new: https://git.openjdk.org/jdk/pull/26863/files/4882b2db..d6895181 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From jsjolen at openjdk.org Wed Aug 20 17:59:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 20 Aug 2025 17:59:41 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: <1bLU50VrPIETq3MpOLq605JqdlCQ-f17dsuJ2Lp4LrY=.8e78ccfd-78d6-46fc-8306-ab5466ecd45a@github.com> References: <1bLU50VrPIETq3MpOLq605JqdlCQ-f17dsuJ2Lp4LrY=.8e78ccfd-78d6-46fc-8306-ab5466ecd45a@github.com> Message-ID: On Wed, 20 Aug 2025 14:44:21 GMT, Kim Barrett wrote: >> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can >> be more easily structured and captured than bare email. Once discussion >> settles down I'll turn the results into HotSpot Style Guide changes. I don't >> intend to integrate any version of this document to the OpenJDK repository. > > doc/cpp17-features.md line 1103: > >> 1101: Template template parameters are barely used (if at all) in HotSpot. >> 1102: >> 1103: [n4051](http://wg21.link/n4051) > > I'm moving this to the permitted category, after realizing that I'd > unknowingly used it in some exploratory work I'm conducting. Artifically > disallowing this syntactic regularization serves no useful purpose. I have used this, so happy to see it being approved. This spurred me to have a second look at this document, seems like I've missed some things. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2288903833 From iveresov at openjdk.org Wed Aug 20 18:25:13 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 20 Aug 2025 18:25:13 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() Message-ID: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. ------------- Commit messages: - Fix TD verification Changes: https://git.openjdk.org/jdk/pull/26866/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365407 Stats: 84 lines in 6 files changed: 52 ins; 16 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From iveresov at openjdk.org Wed Aug 20 18:32:22 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 20 Aug 2025 18:32:22 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix minimal build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/997b4858..b9dde139 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From ihse at openjdk.org Wed Aug 20 19:36:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Aug 2025 19:36:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text Build changes look good now. Thanks! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3137980952 From duke at openjdk.org Wed Aug 20 20:00:37 2025 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 20 Aug 2025 20:00:37 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 05:22:23 GMT, Thomas Stuefe wrote: >>> You mean adding the vsize, swap etc fields to ResidentSetSize? >>> >>> I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) >> >> I was thinking something like this: >> >> >> >> >> >> >> >> >> >> >> >> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. >> >>> Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. >> >> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal. >> >> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. >> >>> It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance). >> >> We should not sacrifice the design unless the overhead is significant. > >> > You mean adding the vsize, swap etc fields to ResidentSetSize? >> > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) >> >> I was thinking something like this: >> >> ``` >> >> >> >> >> >> >> >> ``` > > Hmm, yes, that would be one alternative. > >> >> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. >> >> > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. >> >> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal. >> >> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. > > I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation. > > Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way. > > In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss. > > I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the most important platform. > > On Windows, for exa... @tstuefe I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not touching `jdk.ResidentSetSize`) makes sense. - This allows JMC to continue as normal - And also keeps the relevant metrics together so they can be easily interpreted in relation to each other. - @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go this route, maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation at some point in the future to allow JMC time to eventually switch over to using the new event for its charts? > When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? I think this new swap data is process-specific so is not already covered by `jdk.SwapSpace`, which shows the max amount available and how much is currently free to the OS. I think it could be reasonable to leave the process' swap data in `ProcessSize` rather than the `jdk.SwapSpace` which contains data for the whole OS. The connecting thread is that this info is a "process" metric being grouped with other memory metrics for this specific process. Another option, in order to avoid duplication, could be to leave the RSS metrics in the `jdk.ResidentSetSize` event, not put them in the `ProcessSize` event, and correlate them by giving them the same timestamp as (Erik mentions above). Something similar was also done with the `NativeMemoryUsagePeak` and `NativeMemoryUsageTotalPeak` events (which are GraalVM specific) to avoid having to modify `NativeMemoryUsage` and `NativeMemoryUsageTotal`. Admittedly, this is not as clean or convenient. Either way, I agree that putting all the metrics in `ProcessSize` in their own individual events is not the best way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3207897026 From kbarrett at openjdk.org Wed Aug 20 20:19:39 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Aug 2025 20:19:39 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes wrote: > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... I noticed there are a number of calls with `buflen - 1`. Probably from the bad old days when some snprintf variants didn't guarantee null termination. I didn't see forced null terminations for the few I spot-checked though, and it's not obvious in some cases that the final byte is certain to be null going in. Nothing to be done about that here, but there might be some following cleanup work called for. src/hotspot/os/linux/os_linux.cpp line 4801: > 4799: char buf [16]; // according to glibc manpage, 16 chars incl. '/0' > 4800: (void) os::snprintf(buf, sizeof(buf), "%s", name); > 4801: buf[sizeof(buf) - 1] = '\0'; pre-existing. Adding null termination at the end hasn't been needed for a while. There are probably others like this that can be deferred to following cleanup. src/hotspot/os/posix/attachListener_posix.cpp line 351: > 349: int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", > 350: os::get_temp_directory(), os::current_process_id()); > 351: assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`? src/hotspot/share/opto/idealGraphPrinter.cpp line 644: > 642: // Only use up to 4 chars and fall back to a generic "I" to keep it short. > 643: int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value); > 644: if (written_chars > 0 && written_chars <= 4) { I don't understand the addition of `written_chars > 0` here and line 658? src/hotspot/share/runtime/os.hpp line 810: > 808: // Performs vsnprintf and asserts the result is non-negative (so there was not > 809: // an encoding error or any other kind of usage error). > 810: [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0); Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together? And maybe a line break between the attributes and the signature, just to avoid pushing the signature way over to the right. ------------- PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3138069291 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289177595 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289182600 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289195737 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289201763 From kdnilsen at openjdk.org Wed Aug 20 20:20:38 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 20 Aug 2025 20:20:38 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas wrote: > The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. > > This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. Looks good to me. Have we run this change through our internal CI regression pipelines? ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3138114458 From wkemper at openjdk.org Wed Aug 20 20:58:36 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Aug 2025 20:58:36 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 20:18:21 GMT, Kelvin Nilsen wrote: >> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. >> >> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. > > Looks good to me. Have we run this change through our internal CI regression pipelines? Looks reasonable to me. I have the same question as @kdnilsen . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3208064052 From dlong at openjdk.org Wed Aug 20 21:23:36 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 20 Aug 2025 21:23:36 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes wrote: > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic? It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3208122700 From bmaillard at openjdk.org Wed Aug 20 21:27:39 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Wed, 20 Aug 2025 21:27:39 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: References: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> Message-ID: On Tue, 19 Aug 2025 15:44:42 GMT, Vladimir Kozlov wrote: >> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: >> >> Use print_cr instead of \n > > src/hotspot/share/opto/compile.cpp line 5411: > >> 5409: } >> 5410: >> 5411: Node* Compile::make_debug_print_call(const char* str, address call_addr, PhaseGVN* gvn, > > I think it should be in graphKit.cpp similar to `GraphKit::make_runtime_call()` This was the case in the first iteration of the implementation, but this meant that it could only be used during parsing, and not in subsequent phases. It was actually requested to be moved out of `GraphKit`, and a large chunk of the logic is about doing the wiring of the call node without depending on the `SafePointNode` available in `GraphKit`. The three examples in the _More Examples_ section highlight use cases where `GraphKit` is not available. Maybe I should have started with one of these instead of the `return_values` example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2289332208 From dholmes at openjdk.org Wed Aug 20 21:32:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Aug 2025 21:32:39 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com> Message-ID: On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie wrote: > I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds. > Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources. For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3208143195 From dlong at openjdk.org Wed Aug 20 21:55:36 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 20 Aug 2025 21:55:36 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes wrote: > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727: > 725: > 726: int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 "); > 727: get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len); Suggestion: int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 "); if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) { get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len); } If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289384784 From jsikstro at openjdk.org Wed Aug 20 22:07:30 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 20 Aug 2025 22:07:30 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> References: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> Message-ID: On Wed, 20 Aug 2025 07:19:36 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewer's comments Overall this looks really good, thank you. I have a few comments with some things that stood out to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3137068716 From liach at openjdk.org Wed Aug 20 22:22:15 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 20 Aug 2025 22:22:15 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code Message-ID: When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. ------------- Commit messages: - 8365885: Clean up constant pool reflection native code Changes: https://git.openjdk.org/jdk/pull/26870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26870&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365885 Stats: 142 lines in 6 files changed: 18 ins; 3 del; 121 mod Patch: https://git.openjdk.org/jdk/pull/26870.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26870/head:pull/26870 PR: https://git.openjdk.org/jdk/pull/26870 From dlong at openjdk.org Wed Aug 20 22:24:58 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 20 Aug 2025 22:24:58 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes wrote: > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... src/hotspot/os/aix/attachListener_aix.cpp line 423: > 421: log_trace(attach)("Failed to find attach file: %s, trying alternate", fn); > 422: os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d", > 423: os::get_temp_directory(), os::current_process_id()); This could fail if os::get_temp_directory() returns an extremely long path. How about doing a truncation check like at line 354? src/hotspot/os/aix/os_aix.cpp line 1055: > 1053: if (ebuf != nullptr && ebuflen > 0) { > 1054: os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", > 1055: filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); Suggestion: (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH. src/hotspot/os/aix/os_aix.cpp line 1097: > 1095: struct utsname name; > 1096: uname(&name); > 1097: os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version); Suggestion: (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version); src/hotspot/os/aix/porting_aix.cpp line 939: > 937: // retrieve the path to the currently running executable binary > 938: // to open it > 939: os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid()); Suggestion: os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid()); src/hotspot/os/aix/porting_aix.cpp line 1157: > 1155: } > 1156: if (ebuf != nullptr && ebuflen > 0) { > 1157: os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report); Suggestion: (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report); src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324: > 322: > 323: virtual void do_thread(Thread* t) { > 324: os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); Suggestion: (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); Can this be a JavaThread with an arbitrarily long name()? src/hotspot/share/utilities/virtualizationSupport.cpp line 76: > 74: if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > 75: has_host_information = true; > 76: os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info); Are these two guaranteed not to overflow/truncate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289418676 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289425021 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289426575 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289429123 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289430247 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289397586 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289406269 From kvn at openjdk.org Wed Aug 20 22:39:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 20 Aug 2025 22:39:57 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> References: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> Message-ID: On Tue, 19 Aug 2025 07:06:55 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Use print_cr instead of \n What assembler is look like? AOT code generation may have issue with this. We need to preserve C string passed to runtime call. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3208278627 From dlong at openjdk.org Wed Aug 20 23:02:51 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 20 Aug 2025 23:02:51 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com> On Wed, 20 Aug 2025 22:13:31 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/os/aix/attachListener_aix.cpp line 423: > >> 421: log_trace(attach)("Failed to find attach file: %s, trying alternate", fn); >> 422: os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d", >> 423: os::get_temp_directory(), os::current_process_id()); > > This could fail if os::get_temp_directory() returns an extremely long path. How about doing a truncation check like at line 354? Nevermind, same thing. We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289472350 From dholmes at openjdk.org Thu Aug 21 00:05:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 00:05:57 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 15:43:03 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Hi @coleenp, > Could you please take a look? @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3208497225 From ysuenaga at openjdk.org Thu Aug 21 00:14:52 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 21 Aug 2025 00:14:52 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 12:33:51 GMT, David Holmes wrote: > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14". However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3208514020 From dholmes at openjdk.org Thu Aug 21 00:30:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 00:30:54 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 19 Aug 2025 08:19:16 GMT, Andrew Haley wrote: > We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. But if we introduce a new path to that code that might not be the case and so we will introduce a new place where we switch modes. That can lead to redundancy. The whole thing (as it has from day one) seems ad-hoc. But if the proposed scheme performs better in general, and is not obviously "worse" from the ad-hoc perspective then ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3208537749 From fyang at openjdk.org Thu Aug 21 01:09:54 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 21 Aug 2025 01:09:54 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v4] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 12:35:47 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > comments Updated version LGTM. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3138705027 From dholmes at openjdk.org Thu Aug 21 01:18:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 01:18:01 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> References: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> Message-ID: On Wed, 20 Aug 2025 07:19:36 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewer's comments src/hotspot/os/windows/os_windows.cpp line 869: > 867: return true; > 868: } else { > 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory(): %u", ::GetLastError()); Suggestion: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory(): %lu", ::GetLastError()); There is no consistency here but the primary ways we print `GetLastError` are using `%lu`, `%ld` or `%d`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2289632489 From dholmes at openjdk.org Thu Aug 21 01:41:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 01:41:53 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: <296rFrGzsjxV05kcDUyoznrtsMS7FBNP-hYf1ACWqjI=.d67d4cfb-7981-4e0a-a283-52cc97be2ee4@github.com> Message-ID: <8JW0vmIDxZSwqe1jTVrG2jgUWzgK91TdEQCCs7TIwro=.a56ec3fc-4d7c-463d-aa11-f2329bac69aa@github.com> On Wed, 20 Aug 2025 14:50:25 GMT, Leonid Mesnik wrote: > Vice versa. The exception is thrown in "usual" method. Usually, the stack is unwinded until exception is caught. However, it is possible to call the method (using upCall) in the middle of this process. And this 'upCall' method doesn't throw or caught any exceptions. Should just work normally. So the callback does an upcall that invokes the same method we are still posting the "method exit" for. That is a distinct frame/activation so the exit mode of the original should be immaterial. Though not sure how we avoid infinite loop in such a recursive case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3208641908 From fyang at openjdk.org Thu Aug 21 01:50:53 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 21 Aug 2025 01:50:53 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: References: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> Message-ID: On Wed, 20 Aug 2025 10:37:36 GMT, Yuri Gaevsky wrote: >> Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: >> >> removed unneeded check for zero length; changed lmul from m8 to m2. > > More performance data for m2 vs m4 vs m8: > > ========================================================================================================================== > -XX:-UseRVV -XX:+UseRVV(m2) -XX:+UseRVV(m4) -XX:+UseRVV(m8) > ========================================================================================================================== > Benchmark (size) Mode Cnt Score Error Score Error Score Error Score Error Units > Int.differentSubrangeMatches 100 avgt 10 137.172 ? 0.054 98.497 ? 0.310 79.800 ? 0.279 69.906 ? 0.268 ns/op > Int.differentSubrangeMatches 200 avgt 10 156.312 ? 0.281 140.852 ? 0.361 118.496 ? 1.082 103.428 ? 0.425 ns/op > Int.differentSubrangeMatches 300 avgt 10 327.659 ? 0.317 191.959 ? 0.440 148.588 ? 1.106 138.767 ? 0.635 ns/op > Int.differentSubrangeMatches 400 avgt 10 240.912 ? 0.429 230.264 ? 0.164 179.730 ? 0.306 170.405 ? 0.312 ns/op > Int.differentSubrangeMatches 500 avgt 10 523.581 ? 0.292 286.112 ? 0.307 210.887 ? 0.311 172.616 ? 0.517 ns/op > Int.differentSubrangeMatches 600 avgt 10 352.296 ? 0.480 322.362 ? 0.924 249.807 ? 0.290 201.274 ? 0.633 ns/op > Int.differentSubrangeMatches 700 avgt 10 725.652 ? 0.555 382.037 ? 0.434 278.503 ? 0.633 245.203 ? 0.391 ns/op > Int.differentSubrangeMatches 800 avgt 10 455.651 ? 1.003 412.241 ? 0.411 312.572 ? 0.475 271.538 ? 0.319 ns/op > -------------------------------------------------------------------------------------------------------------------------- > Int.matches 100 avgt 10 143.116 ? 0.627 128.433 ? 0.057 110.221 ? 0.056 95.322 ? 0.049 ns/op > Int.matches 200 avgt 10 227.868 ? 0.190 231.481 ? 0.343 172.225 ? 0.052 160.328 ? 0.019 ns/op > Int.matches 300 avgt 10 336.983 ? 0.094 301.416 ? 0.279 234.191 ? 0.036 199.844 ? 0.224 ns/op > Int.matches 400 avgt 10 440.492 ? 0.503 389.587 ? 0.752 312.521 ? 0.103 259.867 ? 0.030 ns/op > Int.matches 500 avgt 10 524.292 ? 0.828 490.197 ? 1.283 362.972 ? 0.847 297.545 ? 0.140 ns/op > Int.matches 600 avgt 10 627.717 ? 0.880 577.573 ? 0.764 420.304 ? 0.086 361.774 ? 0.720 ns/op > Int.matches 700 avgt 10 730.503 ? 0.281 719.430 ? 0.278 487.603 ? 2.297 397.502 ? 0.467 ns/op > Int.... @ygaevsky : From the posted JMH numbers, performance regression for smaller sizes (< 64) happens for each case. And there is also a regression for `Int.mismatchStart` for large sizes (>=100). So I don't think that it's acceptable in the current shape. Is it possible to fix that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3208655204 From ysr at openjdk.org Thu Aug 21 01:59:51 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 21 Aug 2025 01:59:51 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas wrote: > The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. > > This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. Marked as reviewed by ysr (Reviewer). Same; performance impact would be good to know (i.e. that it's performance neutral or may be even a bit better). ------------- PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3138778757 PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3208682261 From dholmes at openjdk.org Thu Aug 21 02:00:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 02:00:57 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v13] In-Reply-To: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> References: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> Message-ID: On Wed, 20 Aug 2025 16:48:56 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed comment. To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand: { ThreadInVMfromJava __tiv(thread); state = get_jvmti_thread_state(thread); } With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call: current_frame.interpreter_frame_result(&oop_result, &value); current_frame.interpreter_frame_expression_stack_size() > 0 if we may not be in interp_only mode? If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3208690123 From dholmes at openjdk.org Thu Aug 21 02:24:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 02:24:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> On Wed, 20 Aug 2025 18:32:22 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix minimal build Just a few drive-by comments as I'm not familiar with this "training" stuff. src/hotspot/share/compiler/compilationPolicy.cpp line 141: > 139: } > 140: > 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { This method seems to be waiting for something to finish, not "flushing" anything itself. src/hotspot/share/compiler/compilationPolicy.cpp line 142: > 140: > 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { > 142: MonitorLocker locker(THREAD, TrainingReplayQueue_lock); There is no exception processing here so this method should not be declared to take `TRAPS`. If you want to pass the current thread just declare a `JavaThread* current` parameter directly please. src/hotspot/share/oops/trainingData.hpp line 678: > 676: void dec_init_deps_left(KlassTrainingData* ktd); > 677: int init_deps_left() const { > 678: return Atomic::load_acquire(&_init_deps_left); Where is the `release_store` (or other ordered atomic op) that this pairs with? Also there is a convention to make acquire/release semantics clear in the API method names i.e. in this case `init_deps_left_acquire()`. src/hotspot/share/runtime/java.cpp line 522: > 520: if (AOTVerifyTrainingData) { > 521: EXCEPTION_MARK; > 522: CompilationPolicy::flush_replay_training_at_init(THREAD); Looks odd to have an `at_init` method executing during VM shutdown. ------------- PR Review: https://git.openjdk.org/jdk/pull/26866#pullrequestreview-3138788035 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289684061 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289682761 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289698544 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289701195 From dholmes at openjdk.org Thu Aug 21 02:24:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 02:24:53 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:01:26 GMT, David Holmes wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minimal build > > src/hotspot/share/compiler/compilationPolicy.cpp line 142: > >> 140: >> 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { >> 142: MonitorLocker locker(THREAD, TrainingReplayQueue_lock); > > There is no exception processing here so this method should not be declared to take `TRAPS`. If you want to pass the current thread just declare a `JavaThread* current` parameter directly please. Hmmm I see this code is full of incorrect TRAPS usage! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289686080 From dholmes at openjdk.org Thu Aug 21 02:28:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 02:28:51 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 00:12:12 GMT, Yasumasa Suenaga wrote: > > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. > > I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14". > > However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like? I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets". ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3208778346 From iveresov at openjdk.org Thu Aug 21 02:33:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 02:33:55 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:02:56 GMT, David Holmes wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minimal build > > src/hotspot/share/compiler/compilationPolicy.cpp line 141: > >> 139: } >> 140: >> 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { > > This method seems to be waiting for something to finish, not "flushing" anything itself. It has a semantic effect of flushing the queue... What would you like it to be renamed to? > src/hotspot/share/oops/trainingData.hpp line 678: > >> 676: void dec_init_deps_left(KlassTrainingData* ktd); >> 677: int init_deps_left() const { >> 678: return Atomic::load_acquire(&_init_deps_left); > > Where is the `release_store` (or other ordered atomic op) that this pairs with? > > Also there is a convention to make acquire/release semantics clear in the API method names i.e. in this case `init_deps_left_acquire()`. There is an `Atomic::sub()` in `dec_init_deps_left()`. > src/hotspot/share/runtime/java.cpp line 522: > >> 520: if (AOTVerifyTrainingData) { >> 521: EXCEPTION_MARK; >> 522: CompilationPolicy::flush_replay_training_at_init(THREAD); > > Looks odd to have an `at_init` method executing during VM shutdown. `init` here means `class initialization`. We can rename it if you want, but that's the current convention everybody expects in the leyden project. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289712736 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289708246 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289710061 From iveresov at openjdk.org Thu Aug 21 02:33:56 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 02:33:56 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:05:03 GMT, David Holmes wrote: >> src/hotspot/share/compiler/compilationPolicy.cpp line 142: >> >>> 140: >>> 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { >>> 142: MonitorLocker locker(THREAD, TrainingReplayQueue_lock); >> >> There is no exception processing here so this method should not be declared to take `TRAPS`. If you want to pass the current thread just declare a `JavaThread* current` parameter directly please. > > Hmmm I see this code is full of incorrect TRAPS usage! Yeah, good point, I'll clean this up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289712667 From iveresov at openjdk.org Thu Aug 21 02:45:08 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 02:45:08 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v3] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <35GmGxUo9cqdaEpS_CkmIy5upOwwZrA_vFysYoDIkAQ=.b523c75f-0920-4b21-aea9-4fbea14f073b@github.com> > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Rephrase arguments of the flush() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/b9dde139..3a4690fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From iveresov at openjdk.org Thu Aug 21 03:00:11 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 03:00:11 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: More cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/3a4690fc..289fb74c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=02-03 Stats: 11 lines in 3 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From iveresov at openjdk.org Thu Aug 21 03:00:12 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 03:00:12 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: <4D_wqUeSNSk0d8oNpJqKiE6USu4CNEE6Sv5OvvqRSpI=.d2f863be-6a2f-46cc-a175-2902c7a7cb5b@github.com> On Thu, 21 Aug 2025 02:31:40 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilationPolicy.cpp line 141: >> >>> 139: } >>> 140: >>> 141: void CompilationPolicy::flush_replay_training_at_init(TRAPS) { >> >> This method seems to be waiting for something to finish, not "flushing" anything itself. > > It has a semantic effect of flushing the queue... What would you like it to be renamed to? I'll rename it to `wait`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289732989 From iveresov at openjdk.org Thu Aug 21 03:00:12 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 03:00:12 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:31:36 GMT, Igor Veresov wrote: >> Hmmm I see this code is full of incorrect TRAPS usage! > > Yeah, good point, I'll clean this up. I cleaned it up around the init replay queue and its usage. There are more instances of this but it would probably need to be a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289735389 From dholmes at openjdk.org Thu Aug 21 03:04:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 03:04:49 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga wrote: > According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in ECX from CPUID leaf 80000008h means number of threads, not cores. Thus we should divide it by threads per core. That appears to be a documentation errata that was fixed in June 2023 i.e it used to say "cores" (hence the NC name) but now it says "physical threads". I'm not sure the meaning actually changed based on the chip family (`if (cpu_family() >= 0x17) `) but rather should always be interpreted as number-of-threads no matter which chip you have. Unfortunately I/we have no way to test this across a range of AMD chips! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3208834587 From dholmes at openjdk.org Thu Aug 21 03:20:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 03:20:56 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:55:37 GMT, Igor Veresov wrote: >> Yeah, good point, I'll clean this up. > > I cleaned it up around the init replay queue and its usage. There are more instances of this but it would probably need to be a separate PR. Yeah I noticed it is quite wide-spread and pinged the compiler team internally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289753070 From dholmes at openjdk.org Thu Aug 21 03:20:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 03:20:57 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Thu, 21 Aug 2025 03:00:11 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup src/hotspot/share/compiler/compilationPolicy.cpp line 173: > 171: } > 172: > 173: void CompilationPolicy::replay_training_at_init(InstanceKlass* klass, JavaThread* THREAD) { Please rename `THREAD` to `current`. `THREAD` is still inherently part of the `TRAPS` mechanism. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289757585 From dholmes at openjdk.org Thu Aug 21 03:20:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 03:20:59 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: On Thu, 21 Aug 2025 02:27:40 GMT, Igor Veresov wrote: >> src/hotspot/share/oops/trainingData.hpp line 678: >> >>> 676: void dec_init_deps_left(KlassTrainingData* ktd); >>> 677: int init_deps_left() const { >>> 678: return Atomic::load_acquire(&_init_deps_left); >> >> Where is the `release_store` (or other ordered atomic op) that this pairs with? >> >> Also there is a convention to make acquire/release semantics clear in the API method names i.e. in this case `init_deps_left_acquire()`. > > There is an `Atomic::sub()` in `dec_init_deps_left()`. Okay - not obvious we actually require acquire semantics when reading a simple count, but I'm not sure what the count may imply. But please consider renaming the method. >> src/hotspot/share/runtime/java.cpp line 522: >> >>> 520: if (AOTVerifyTrainingData) { >>> 521: EXCEPTION_MARK; >>> 522: CompilationPolicy::flush_replay_training_at_init(THREAD); >> >> Looks odd to have an `at_init` method executing during VM shutdown. > > `init` here means `class initialization`. We can rename it if you want, but that's the current convention everybody expects in the leyden project. "from_init" might be better if this represents training data from class initialization time. Though is there non-init training data? i.e. could it just be `flush_replay_training`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289754815 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289756627 From iveresov at openjdk.org Thu Aug 21 04:21:52 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 04:21:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <2mpeNLuJywlDXNQZ13_2ffFsW_4pwOXr-vWqnwQW4jM=.0d50c86f-02dc-4431-bf4f-999a0d7da232@github.com> On Thu, 21 Aug 2025 03:18:38 GMT, David Holmes wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup > > src/hotspot/share/compiler/compilationPolicy.cpp line 173: > >> 171: } >> 172: >> 173: void CompilationPolicy::replay_training_at_init(InstanceKlass* klass, JavaThread* THREAD) { > > Please rename `THREAD` to `current`. `THREAD` is still inherently part of the `TRAPS` mechanism. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2289813352 From dholmes at openjdk.org Thu Aug 21 05:37:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 05:37:52 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> References: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> Message-ID: <6mwFNPgecEzR5PYjXk61WNnz3KrKFIgiRhBxUy5W4H4=.846ebbef-9b26-47e2-937e-5be9c4bfe3b4@github.com> On Wed, 20 Aug 2025 20:03:04 GMT, Kim Barrett wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/os/linux/os_linux.cpp line 4801: > >> 4799: char buf [16]; // according to glibc manpage, 16 chars incl. '/0' >> 4800: (void) os::snprintf(buf, sizeof(buf), "%s", name); >> 4801: buf[sizeof(buf) - 1] = '\0'; > > pre-existing. Adding null termination at the end hasn't been needed for a while. There are probably > others like this that can be deferred to following cleanup. Okay I have filed [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) to clean this up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289902515 From dholmes at openjdk.org Thu Aug 21 05:40:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 05:40:51 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> References: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> Message-ID: On Wed, 20 Aug 2025 20:05:51 GMT, Kim Barrett wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/os/posix/attachListener_posix.cpp line 351: > >> 349: int n = os::snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", >> 350: os::get_temp_directory(), os::current_process_id()); >> 351: assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); > > I don't see any other uses of `n` besides this assert. Maybe this should be using `os::snprintf_checked`? Agreed - changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289906758 From dholmes at openjdk.org Thu Aug 21 05:45:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 05:45:52 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> References: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> Message-ID: On Wed, 20 Aug 2025 20:12:35 GMT, Kim Barrett wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/share/opto/idealGraphPrinter.cpp line 644: > >> 642: // Only use up to 4 chars and fall back to a generic "I" to keep it short. >> 643: int written_chars = os::snprintf(buffer, sizeof(buffer), "%d", value); >> 644: if (written_chars > 0 && written_chars <= 4) { > > I don't understand the addition of `written_chars > 0` here and line 658? Well in theory, in a release build, `os::snprintf` could return -1 and I didn't want any static analysis tools pointing this out to me later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289912608 From chagedorn at openjdk.org Thu Aug 21 05:51:55 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 21 Aug 2025 05:51:55 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v12] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 17:31:58 GMT, Manuel H?ssig wrote: >> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. >> >> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. >> >> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. >> >> Testing: >> - [x] Github Actions >> - [x] tier1, tier2 on all platforms >> - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug >> - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Print with %zd Still good! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26023#pullrequestreview-3139108863 From dholmes at openjdk.org Thu Aug 21 06:00:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:00:51 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:20:50 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic? It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future. Thanks for looking at this @dean-long ! > Could we map snprintf to os::snprintf_checked with a macro or some kind of namespace magic? It would reduce the number of files changed and catch any new cases of snprintf that might get accidentally added in the future. Raw `snprintf` is now prohibited so no future accidental additions are possible. I don't think hiding the fact we are not using the library `snprintf` is a good thing either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3209102280 From dholmes at openjdk.org Thu Aug 21 06:06:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:06:52 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:53:11 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 727: > >> 725: >> 726: int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 "); >> 727: get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len); > > Suggestion: > > int desc_len = os::snprintf(_cpu_desc, CPU_DETAILED_DESC_BUF_SIZE, "AArch64 "); > if (desc_len < CPU_DETAILED_DESC_BUF_SIZE) { > get_compatible_board(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len); > } > > If there is truncation, _cpu_desc + desc_len will be past the end of the buffer and CPU_DETAILED_DESC_BUF_SIZE - desc_len will be negative in get_compatible_board(), which will cause problems when converted to size_t. There cannot be truncation here. We are writing a fixed-size string of 8 characters (plus nul-terminator) to a buffer of size 4096. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289943417 From dholmes at openjdk.org Thu Aug 21 06:25:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:25:52 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: On Wed, 20 Aug 2025 21:59:17 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324: > >> 322: >> 323: virtual void do_thread(Thread* t) { >> 324: os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); > > Suggestion: > > (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); > > Can this be a JavaThread with an arbitrarily long name()? Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289969498 From dholmes at openjdk.org Thu Aug 21 06:25:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:25:53 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: On Thu, 21 Aug 2025 06:21:00 GMT, David Holmes wrote: >> src/hotspot/share/gc/shared/satbMarkQueue.cpp line 324: >> >>> 322: >>> 323: virtual void do_thread(Thread* t) { >>> 324: os::snprintf_checked(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); >> >> Suggestion: >> >> (void) os::snprintf(_buffer, SATB_PRINTER_BUFFER_SIZE, "Thread: %s", t->name()); >> >> Can this be a JavaThread with an arbitrarily long name()? > > Yes it could - thanks. It is likely enough that we could hit this during testing that asserting if it happens is not really useful. Long Java thread names are not necessarily errors to be fixed. In addition, if we were to hit such a name we are not likely to increase the buffer size just for this extreme case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289973406 From dholmes at openjdk.org Thu Aug 21 06:28:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:28:56 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: <6JAI2s1fJRYWYXtcyA_b2Bhn_7_GGAc67YuAFoGUrso=.55792b10-d6c0-4625-84b2-953ace2cf039@github.com> On Wed, 20 Aug 2025 22:05:10 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/share/utilities/virtualizationSupport.cpp line 76: > >> 74: if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { >> 75: has_host_information = true; >> 76: os::snprintf_checked(host_information, sizeof(host_information), "%s", result_info); > > Are these two guaranteed not to overflow/truncate? The issue is not whether they can overflow, but if they do is it something we want to detect during testing so we can take action - e.g. by increasing the buffer size. This is very subjective, but my initial position in most cases has been yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289978047 From ysuenaga at openjdk.org Thu Aug 21 06:29:30 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 21 Aug 2025 06:29:30 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v3] In-Reply-To: References: Message-ID: > `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: > > > CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss > CPU Model and flags from /proc/cpuinfo: > model name : Intel(R) Core(TM) Ultra 5 225U > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd > > > It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". > https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html > > According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 > In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove number of threads on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26808/files - new: https://git.openjdk.org/jdk/pull/26808/files/234a67b6..b1fd242c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26808/head:pull/26808 PR: https://git.openjdk.org/jdk/pull/26808 From ysuenaga at openjdk.org Thu Aug 21 06:29:31 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 21 Aug 2025 06:29:31 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 02:25:58 GMT, David Holmes wrote: >>> `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. >> >> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14". >> >> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like? > >> > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. >> >> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14". >> >> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like? > > I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets". I removed number of threads information on hybrid CPU. @dholmes-ora Can you review? We can get following strings on hybrid CPU after this change: CPU: total 14 (initial active 14) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid CPU Model and flags from /proc/cpuinfo: model name : Intel(R) Core(TM) Ultra 5 225U ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3209164534 From dholmes at openjdk.org Thu Aug 21 06:33:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:33:51 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> <7bUyzA85sBzPhzJMPaLcMflpd4QPUUXBy5z0A7gNbnE=.335d09e8-d7fc-4381-b77e-71c2636748d1@github.com> Message-ID: <5WIH7DnsEDDENhwj3xVo2Y7Qq6g7ULcdkoGnJWAlZZE=.09e34d8a-048d-4e01-9ada-d0fd54ff6ee4@github.com> On Wed, 20 Aug 2025 22:59:51 GMT, Dean Long wrote: >> src/hotspot/os/aix/attachListener_aix.cpp line 423: >> >>> 421: log_trace(attach)("Failed to find attach file: %s, trying alternate", fn); >>> 422: os::snprintf_checked(fn, sizeof(fn), "%s/.attach_pid%d", >>> 423: os::get_temp_directory(), os::current_process_id()); >> >> This could fail if os::get_temp_directory() returns an extremely long path. How about doing a truncation check like at line 354? > > Nevermind, same thing. We would need to fix a lot of code if os::get_temp_directory() returned a pathologically long string. I've changed line 352 as per Kim's comment above because `snprintf` followed by an assert for truncation is what `snprintf_checked` does. Again the question to ask is: if we hit this during testing do we think it indicates we need to increase the buffer size. Again I am initially in the yes camp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289987176 From dholmes at openjdk.org Thu Aug 21 06:38:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:38:55 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: On Wed, 20 Aug 2025 22:18:28 GMT, Dean Long wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/os/aix/os_aix.cpp line 1055: > >> 1053: if (ebuf != nullptr && ebuflen > 0) { >> 1054: os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", >> 1055: filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); > > Suggestion: > > (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", > filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); > > This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH. Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values. > src/hotspot/os/aix/os_aix.cpp line 1097: > >> 1095: struct utsname name; >> 1096: uname(&name); >> 1097: os::snprintf_checked(buf, buflen, "%s %s", name.release, name.version); > > Suggestion: > > (void) os::snprintf(buf, buflen, "%s %s", name.release, name.version); See previous replies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289995061 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289996137 From dholmes at openjdk.org Thu Aug 21 06:38:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:38:56 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> References: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> Message-ID: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com> On Wed, 20 Aug 2025 20:15:25 GMT, Kim Barrett wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > src/hotspot/share/runtime/os.hpp line 810: > >> 808: // Performs vsnprintf and asserts the result is non-negative (so there was not >> 809: // an encoding error or any other kind of usage error). >> 810: [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0); > > Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together? > And maybe a line break between the attributes and the signature, just to avoid pushing the > signature way over to the right. I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2289993291 From dholmes at openjdk.org Thu Aug 21 06:46:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:46:03 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: References: Message-ID: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... David Holmes has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26849/files - new: https://git.openjdk.org/jdk/pull/26849/files/2de6ac98..38003a22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26849&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26849&range=00-01 Stats: 13 lines in 4 files changed: 5 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26849.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26849/head:pull/26849 PR: https://git.openjdk.org/jdk/pull/26849 From dholmes at openjdk.org Thu Aug 21 06:46:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 06:46:05 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: <4UAB8nFSiBclUHIOuDsRkEpX_ZUma9yvK11iRkMOTtM=.4f9402f4-7f44-4f6e-a854-6e2313c412c9@github.com> On Wed, 20 Aug 2025 22:21:45 GMT, Dean Long wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer feedback > > src/hotspot/os/aix/porting_aix.cpp line 939: > >> 937: // retrieve the path to the currently running executable binary >> 938: // to open it >> 939: os::snprintf_checked(buffer, 100, "/proc/%ld/object/a.out", (long)getpid()); > > Suggestion: > > os::snprintf_checked(buffer, sizeof(buffer), "/proc/%ld/object/a.out", (long)getpid()); It doesn't really matter as we only need at most 30 bytes. > src/hotspot/os/aix/porting_aix.cpp line 1157: > >> 1155: } >> 1156: if (ebuf != nullptr && ebuflen > 0) { >> 1157: os::snprintf_checked(ebuf, ebuflen - 1, "%s", error_report); > > Suggestion: > > (void) os::snprintf(ebuf, ebuflen - 1, "%s", error_report); See previous replies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290002985 PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290003771 From ysuenaga at openjdk.org Thu Aug 21 06:52:51 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 21 Aug 2025 06:52:51 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: <55ZEwg9gcFmnPis8F_FxnzKYBoZcz49BY_ecF3KZWbc=.94ebfa86-d276-4a7f-a838-6b02d4485781@github.com> On Thu, 21 Aug 2025 03:02:23 GMT, David Holmes wrote: > I'm not sure the meaning actually changed based on the chip family (`if (cpu_family() >= 0x17)` ) I made the change in `VM_Version::cores_per_cpu()`, however this function calls from `threads_per_core()` in some case as following. To prevent recursive call, I add a condition for CPU family. SMT (equivalent with HT in Intel) seems to be introduced in Zen architecture (family `17h`), thus this logic should work. uint VM_Version::threads_per_core() { uint result = 1; if (is_intel() && supports_processor_topology()) { result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; } else if (is_zx() && supports_processor_topology()) { result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { if (cpu_family() >= 0x17) { result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; } else { result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / cores_per_cpu(); } } return (result == 0 ? 1 : result); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3209226406 From mhaessig at openjdk.org Thu Aug 21 07:12:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 21 Aug 2025 07:12:04 GMT Subject: RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v4] In-Reply-To: References: <7SKfaULZBs_ccRipoMMWXKUAASHIhq9um43xaxToBKE=.83db680e-fc44-4be9-8f15-0030e764b4f8@github.com> Message-ID: On Thu, 7 Aug 2025 18:57:14 GMT, Dean Long wrote: >> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: >> >> ASSERT > > Thinking about _timeout_armed a little more, the fact the the signal handler received TIMEOUT_SIGNAL should be enough. The value of _timeout_armed should be redundant, and your assert could be changed to: > > assert(false, "compile task timed out"); > > and _timeout_armed could be removed. It's just an inexact mirror of the timer state. Thank you for your reviews, @dean-long and @chhagedorn! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26023#issuecomment-3209292036 From mhaessig at openjdk.org Thu Aug 21 07:12:07 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 21 Aug 2025 07:12:07 GMT Subject: Integrated: 8308094: Add a compilation timeout flag to catch long running compilations In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 17:36:54 GMT, Manuel H?ssig wrote: > This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations. > > The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out. > > Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers. > > Testing: > - [x] Github Actions > - [x] tier1, tier2 on all platforms > - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug > - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail) This pull request has now been integrated. Changeset: c74c60fb Author: Manuel H?ssig URL: https://git.openjdk.org/jdk/commit/c74c60fb8b8aa5c917fc4e1c157cc8083f5797a0 Stats: 282 lines in 8 files changed: 279 ins; 0 del; 3 mod 8308094: Add a compilation timeout flag to catch long running compilations Co-authored-by: Dean Long Reviewed-by: dlong, chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/26023 From dzhang at openjdk.org Thu Aug 21 07:27:53 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 21 Aug 2025 07:27:53 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v4] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 12:35:47 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > comments src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5972: > 5970: // Check j.l.Float.floatToFloat16 for more information. > 5971: // 10 bits > 5972: slli(tmp1, dst, 9+32); Suggestion for adding some whitespace: Suggestion: slli(tmp1, dst, 9 + 32); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2290133418 From dlong at openjdk.org Thu Aug 21 07:48:57 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 21 Aug 2025 07:48:57 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: On Thu, 21 Aug 2025 06:35:44 GMT, David Holmes wrote: >> src/hotspot/os/aix/os_aix.cpp line 1055: >> >>> 1053: if (ebuf != nullptr && ebuflen > 0) { >>> 1054: os::snprintf_checked(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", >>> 1055: filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); >> >> Suggestion: >> >> (void) os::snprintf(ebuf, ebuflen - 1, "%s, LIBPATH=%s, LD_LIBRARY_PATH=%s : %s", >> filename, ::getenv("LIBPATH"), ::getenv("LD_LIBRARY_PATH"), error_report); >> >> This could easily truncate, based on LIBPATH and LD_LIBRARY_PATH. > > Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values. In this case the buffer size comes from shared code. Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings. This is just the error message, so it might be OK to truncate it. Otherwise we could need to allocate the buffer using malloc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290181959 From aph at openjdk.org Thu Aug 21 08:16:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 21 Aug 2025 08:16:53 GMT Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE [v2] In-Reply-To: <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com> References: <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com> Message-ID: <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com> On Wed, 20 Aug 2025 14:33:43 GMT, Samuel Chee wrote: > * We close this pr > > * Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere. If you like, although we can (and we should) tidy up as we go along. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3209493737 From mhaessig at openjdk.org Thu Aug 21 08:17:05 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 21 Aug 2025 08:17:05 GMT Subject: RFR: 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations Message-ID: I broke the build by integrating #26023 so backing it out with this PR. ------------- Commit messages: - Revert "8308094: Add a compilation timeout flag to catch long running compilations" Changes: https://git.openjdk.org/jdk/pull/26874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365910 Stats: 282 lines in 8 files changed: 0 ins; 279 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26874/head:pull/26874 PR: https://git.openjdk.org/jdk/pull/26874 From chagedorn at openjdk.org Thu Aug 21 08:26:05 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 21 Aug 2025 08:26:05 GMT Subject: RFR: 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations In-Reply-To: References: Message-ID: <8isUDYa6n6Zciv7KtN4UFCCKxb9m06xasyQb5bnqxuk=.a0c03a0b-dec5-430a-8c6e-900f007f5ab9@github.com> On Thu, 21 Aug 2025 08:11:16 GMT, Manuel H?ssig wrote: > I broke the build by integrating #26023 so backing it out with this PR. Looks good and trivial, thanks for taking care of that! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26874#pullrequestreview-3139604294 From dholmes at openjdk.org Thu Aug 21 08:26:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Aug 2025 08:26:05 GMT Subject: RFR: 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 08:11:16 GMT, Manuel H?ssig wrote: > I broke the build by integrating #26023 so backing it out with this PR. Backout looks good. Thanks for the quick response. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26874#pullrequestreview-3139604822 From mhaessig at openjdk.org Thu Aug 21 08:26:06 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 21 Aug 2025 08:26:06 GMT Subject: RFR: 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 08:11:16 GMT, Manuel H?ssig wrote: > I broke the build by integrating #26023 so backing it out with this PR. Thank you for your reviews and sorry for the noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26874#issuecomment-3209520259 From duke at openjdk.org Thu Aug 21 08:26:21 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 08:26:21 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v30] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - 8357086: Fixed whitespace error - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Fixed merge conflict - 8357086: Removed extra line - ... and 22 more: https://git.openjdk.org/jdk/compare/51d710e3...530138ab ------------- Changes: https://git.openjdk.org/jdk/pull/25450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=29 Stats: 264 lines in 23 files changed: 102 ins; 2 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From mhaessig at openjdk.org Thu Aug 21 08:26:06 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 21 Aug 2025 08:26:06 GMT Subject: Integrated: 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations In-Reply-To: References: Message-ID: <5mthgljgOXuYQB7UXzBhFo-S8TCSBUQvDj5VqEHG9VU=.597f41b9-d025-47be-ad96-ad981e41cdf5@github.com> On Thu, 21 Aug 2025 08:11:16 GMT, Manuel H?ssig wrote: > I broke the build by integrating #26023 so backing it out with this PR. This pull request has now been integrated. Changeset: 5febc4e3 Author: Manuel H?ssig URL: https://git.openjdk.org/jdk/commit/5febc4e3bb1f47f69fc28c266a775e19cbac9e5f Stats: 282 lines in 8 files changed: 0 ins; 279 del; 3 mod 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations Reviewed-by: chagedorn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26874 From fgao at openjdk.org Thu Aug 21 08:41:59 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 21 Aug 2025 08:41:59 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: On Wed, 20 Aug 2025 08:44:30 GMT, Andrew Haley wrote: >>> In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >> >> Or code should be the same. > >> > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >> >> Or code should be the same. > > OK, so we should not commit this patch. it's not worth it. @theRealAph @adinn @vnkozlov I agree with your points. Thank you for taking the time to review and provide such a detailed explanation. I?ve learned a lot from the discussions. I?ll close this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3209567088 From fgao at openjdk.org Thu Aug 21 08:42:00 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 21 Aug 2025 08:42:00 GMT Subject: Withdrawn: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: Message-ID: <4PNsWvb-Htakll028iUakbrVf8SC0-62nVjPKS0-OFI=.0a2525f1-7084-4283-ad7c-e5b38c5c09ef@github.com> On Wed, 6 Aug 2025 09:13:30 GMT, Fei Gao wrote: > If the relocation or target address is guaranteed to reside within the CodeCache, we can safely replace a `movz + movk + movk` sequence with a more compact and efficient `adrp + add` instruction pair. > > In `MacroAssembler::mov(Register r, Address dest)`, this replacement can be applied if any of the following rules hold: > > 1. The relocation type indicates that the address resides within the CodeCache and the necessary patching logic is provided in `fix_relocation_after_move()`. > 2. The target address is fixed (i.e., does not require relocation) and is within the reachable range for `adrp`. > > The patch performs the filtering in `is_relocated_within_codecache()` and `is_adrp_reachable()` to ensure this optimization is applied safely and selectively. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26653 From duke at openjdk.org Thu Aug 21 08:48:26 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 08:48:26 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v31] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewers' comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/530138ab..c0e09fbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=29-30 Stats: 12 lines in 5 files changed: 0 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Thu Aug 21 08:48:27 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 08:48:27 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: References: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> Message-ID: On Thu, 21 Aug 2025 01:14:48 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Addressed reviewer's comments > > src/hotspot/os/windows/os_windows.cpp line 869: > >> 867: return true; >> 868: } else { >> 869: assert(false, "GlobalMemoryStatusEx failed in win32::available_memory(): %u", ::GetLastError()); > > Suggestion: > > assert(false, "GlobalMemoryStatusEx failed in win32::available_memory(): %lu", ::GetLastError()); > > There is no consistency here but the primary ways we print `GetLastError` are using `%lu`, `%ld` or `%d`. Addressed by usage of `%lu`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290343762 From duke at openjdk.org Thu Aug 21 08:48:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 08:48:28 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v29] In-Reply-To: References: <6REIPtecvg0hgCaEnCil_5yTXPgMAAVmXrdwoukfbcU=.20e9bf06-d830-42fa-bb07-c1da4e14cb3a@github.com> Message-ID: On Wed, 20 Aug 2025 15:33:02 GMT, Joel Sikstr?m wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Addressed reviewer's comments > > src/hotspot/os/windows/os_windows.cpp line 4167: > >> 4165: BOOL res = GlobalMemoryStatusEx(&ms); >> 4166: if (res != TRUE) >> 4167: { > > To fit in with the surrounding style, the '{' should be moved to the same line as the if-statement. > Suggestion: > > if (res != TRUE) { Thanks for spotting, addressed. > src/hotspot/share/gc/shared/gcInitLogger.cpp line 66: > >> 64: void GCInitLogger::print_memory() { >> 65: size_t memory = os::physical_memory(); >> 66: log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory)); > > Here as well. Addressed. > src/hotspot/share/gc/z/zLargePages.cpp line 35: > >> 33: >> 34: const size_t memory = os::physical_memory(); >> 35: log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory)); > > I would like to see PROPERFMT + PROPERFMTARGS here instead of the expanded version. Addressed. > src/hotspot/share/runtime/os.hpp line 343: > >> 341: >> 342: static size_t physical_memory(); >> 343: static bool has_allocatable_memory_limit(size_t* limit); > > This is likely a mistake from merging. > > `static bool has_allocatable_memory_limit(size_t* limit)` was renamed to `static size_t commit_memory_limit()` in [JDK-8364248](https://bugs.openjdk.org/browse/JDK-8364248), so the definition should be removed here. Removed. > src/hotspot/share/utilities/globalDefinitions.hpp line 1367: > >> 1365: >> 1366: //---------------------------------------------------------------------------------------------------- >> 1367: > > Now I'm bit picky, but I think one line extra here is enough. I removed all added lines, it is a leftover from the initial placing of the `ATTRIBUTE_NODISCARD` dummy placeholder. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290344867 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290345042 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290345246 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290344146 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290344640 From duke at openjdk.org Thu Aug 21 08:48:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 08:48:28 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v24] In-Reply-To: <9mMZXA3hNYC7DcJcPfC1bSmNE3Lmp2VBj8l3Dq7YpW0=.1d85c474-482a-4a25-b26e-c57b60ce746c@github.com> References: <9mMZXA3hNYC7DcJcPfC1bSmNE3Lmp2VBj8l3Dq7YpW0=.1d85c474-482a-4a25-b26e-c57b60ce746c@github.com> Message-ID: On Wed, 20 Aug 2025 15:41:37 GMT, Joel Sikstr?m wrote: >> src/hotspot/share/runtime/os.hpp line 343: >> >>> 341: >>> 342: static size_t physical_memory(); >>> 343: static bool has_allocatable_memory_limit(size_t* limit); >> >> Future cleanup: for consistency should this now also take a reference? > > This is no longer relevant as it has been re-worked in [JDK-8364248](https://bugs.openjdk.org/browse/JDK-8364248) to not have an out-parameter and renamed to `static size_t commit_memory_limit()`. Removed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290346842 From asemenov at openjdk.org Thu Aug 21 09:01:12 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 09:01:12 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: > The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. Artem Semenov has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/c1/c1_LinearScan.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/adlc/output_h.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26798/files - new: https://git.openjdk.org/jdk/pull/26798/files/80777ced..dd21148b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26798&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26798&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26798.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26798/head:pull/26798 PR: https://git.openjdk.org/jdk/pull/26798 From aph at openjdk.org Thu Aug 21 09:09:03 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 21 Aug 2025 09:09:03 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: On Wed, 20 Aug 2025 08:44:30 GMT, Andrew Haley wrote: >>> In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >> >> Or code should be the same. > >> > In short, in "production" run we need to know what code we are working on/patching: AOTed or normal JITed. >> >> Or code should be the same. > > OK, so we should not commit this patch. it's not worth it. > @theRealAph @adinn @vnkozlov > > I agree with your points. > > Thank you for taking the time to review and provide such a detailed explanation. I?ve learned a lot from the discussions. > > I?ll close this PR. Thank you. I hope you're not too discouraged by this. Performance-related patches are often a judgement call, and we often try something and it doesn't work. There's no other way to find out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3209661085 From asemenov at openjdk.org Thu Aug 21 09:11:53 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 09:11:53 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Wed, 20 Aug 2025 12:20:51 GMT, David Holmes wrote: >> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/hotspot/share/c1/c1_LinearScan.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/hotspot/share/adlc/output_h.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/nmt/mallocSiteTable.cpp line 172: > >> 170: index < pos_idx && head != nullptr; >> 171: index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head : >> 172: (MallocSiteHashtableEntry*)head->next()) {} > > This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null. A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290418847 From lkorinth at openjdk.org Thu Aug 21 09:12:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 21 Aug 2025 09:12:57 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> Message-ID: On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan wrote: >> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout. > > Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests. > > So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593). > > I do agree this change, what I mean is this change has some side effect. > >> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work. > > I think I can try it in a new PR. I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing. I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290422272 From stefank at openjdk.org Thu Aug 21 09:13:07 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Aug 2025 09:13:07 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v31] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 08:48:26 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Addressed reviewers' comments src/hotspot/os/windows/os_windows.cpp line 882: > 880: return true; > 881: } else { > 882: assert(false, "GlobalMemoryStatusEx failed in win32::total_swap_space(): %lu", ::GetLastError()); Suggestion: assert(false, "GlobalMemoryStatusEx failed in os::total_swap_space(): %lu", ::GetLastError()); src/hotspot/os/windows/os_windows.cpp line 895: > 893: return true; > 894: } else { > 895: assert(false, "GlobalMemoryStatusEx failed in win32::free_swap_space(): %lu", ::GetLastError()); Suggestion: assert(false, "GlobalMemoryStatusEx failed in os::free_swap_space(): %lu", ::GetLastError()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290418209 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290418787 From duke at openjdk.org Thu Aug 21 09:19:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 09:19:47 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v32] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/c0e09fbf..78efd51f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=30-31 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Thu Aug 21 09:19:50 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 09:19:50 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v31] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 09:08:41 GMT, Stefan Karlsson wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Addressed reviewers' comments > > src/hotspot/os/windows/os_windows.cpp line 882: > >> 880: return true; >> 881: } else { >> 882: assert(false, "GlobalMemoryStatusEx failed in win32::total_swap_space(): %lu", ::GetLastError()); > > Suggestion: > > assert(false, "GlobalMemoryStatusEx failed in os::total_swap_space(): %lu", ::GetLastError()); Thanks for spotting. Addressed in all affected lines. > src/hotspot/os/windows/os_windows.cpp line 895: > >> 893: return true; >> 894: } else { >> 895: assert(false, "GlobalMemoryStatusEx failed in win32::free_swap_space(): %lu", ::GetLastError()); > > Suggestion: > > assert(false, "GlobalMemoryStatusEx failed in os::free_swap_space(): %lu", ::GetLastError()); Thanks for spotting. Addressed in all affected lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290436377 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290436617 From fgao at openjdk.org Thu Aug 21 09:21:10 2025 From: fgao at openjdk.org (Fei Gao) Date: Thu, 21 Aug 2025 09:21:10 GMT Subject: RFR: 8362504: AArch64: Replace MOVZ+MOVK+MOVK with ADRP+ADD In-Reply-To: References: <8G8Djp2bD_zzy3Jm5R3oMoTSrWrbhbCMiIHC5Kl9ufY=.eaed94c1-416a-4c95-a36e-8ba8450d7db4@github.com> <16TGtzZAW6u3pmH7Zfmu8gpBkmnnnPlbE-4rdmcOSps=.8de26ecc-6e9c-4177-bf1e-19187a15f5d2@github.com> Message-ID: <1rgTIzpR96zFUtIXw36LRwwaPNv_C_RcdrDCP_WGZfE=.10e94d24-d1fa-419b-9b9d-97768065fd9b@github.com> On Thu, 21 Aug 2025 09:06:37 GMT, Andrew Haley wrote: > Thank you. I hope you're not too discouraged by this. Performance-related patches are often a judgement call, and we often try something and it doesn't work. There's no other way to find out. Yeah, that?s true ? no other way to find out indeed! I?m definitely not discouraged. This has been a useful learning step either way. Appreciate the feedback and the chance to dig into it. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26653#issuecomment-3209696154 From syan at openjdk.org Thu Aug 21 09:52:54 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 21 Aug 2025 09:52:54 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3] In-Reply-To: References: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com> Message-ID: On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth wrote: >> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests. >> >> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593). >> >> I do agree this change, what I mean is this change has some side effect. >> >>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work. >> >> I think I can try it in a new PR. > > I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing. > > I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you. @lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290523415 From adinn at openjdk.org Thu Aug 21 10:01:59 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Aug 2025 10:01:59 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 09:08:58 GMT, Artem Semenov wrote: >> src/hotspot/share/nmt/mallocSiteTable.cpp line 172: >> >>> 170: index < pos_idx && head != nullptr; >>> 171: index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head : >>> 172: (MallocSiteHashtableEntry*)head->next()) {} >> >> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null. > > A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error Hmm, is it possible? Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290543955 From duke at openjdk.org Thu Aug 21 10:13:57 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 21 Aug 2025 10:13:57 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - conditional includes > - variants I think I found a more sensible approach to tackle this problem. Using clang [`-ftime-trace`](https://clang.llvm.org/docs/analyzer/developer-docs/PerformanceInvestigation.html#performance-analysis-using-ftime-trace) we can get reports in [Trace Event format](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview?tab=t.0) about each header. Example of one such file here: [shenandoahOldGC.json](https://github.com/user-attachments/files/21915502/shenandoahOldGC.json). These files can be processed (e.g. with [ClangBuildAnalyzer](https://github.com/aras-p/ClangBuildAnalyzer/tree/main)) to dig where time was spent during the build. Among the information we can get from `ClangBuildAnalyzer`, here is the interesting one: **** Expensive headers: 597169 ms: /jdk/src/hotspot/share/oops/access.inline.hpp (included 650 times, avg 918 ms), included via: 80x: oop.inline.hpp iterator.inline.hpp 70x: javaClasses.inline.hpp 40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp 39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp 32x: g1CollectedHeap.inline.hpp g1ConcurrentMark.inline.hpp g1ConcurrentMarkBitMap.inline.hpp markBitMap.inline.hpp oop.inline.hpp iterator.inline.hpp 30x: ciUtilities.inline.hpp interfaceSupport.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp ... 425714 ms: /jdk/src/hotspot/share/memory/iterator.inline.hpp (included 646 times, avg 659 ms), included via: 80x: oop.inline.hpp 70x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 32x: g1CollectedHeap.inline.hpp g1ConcurrentMark.inline.hpp g1ConcurrentMarkBitMap.inline.hpp markBitMap.inline.hpp oop.inline.hpp 30x: ciUtilities.inline.hpp interfaceSupport.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp ... 400304 ms: /jdk/src/hotspot/share/oops/oop.inline.hpp (included 1165 times, avg 343 ms), included via: 80x: 70x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 66x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 60x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp iterator.inline.hpp instanceKlass.inline.hpp klass.inline.hpp classLoaderData.inline.hpp 40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp ... [...] This should give us a clear understanding of which headers should go into `precompiled.hpp`, and uses all information available from the compiler itself, as opposed to counting the number of inclusions. Now, improvements in build time are comparable with the initial approach I tried in this PR, but I think this approach will prove more accurate in the long term. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3209879924 From adinn at openjdk.org Thu Aug 21 10:17:56 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Aug 2025 10:17:56 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. >> >> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. > > Artem Semenov has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/c1/c1_LinearScan.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/adlc/output_h.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> n.b. Before accepting any of the changes in this PR I'd really like to know whether they have arisen from reports of an actual null pointer dereference or they are simply derived from some theoretical analysis. In the latter case then I think we would need a better explanation of why an error can happen than we have seen so far. Given that requirement I also think each of the changes should be submitted in its own PR with its own justification. We should not modify control flow logic on the nod. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209906082 From asemenov at openjdk.org Thu Aug 21 10:34:03 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 10:34:03 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Wed, 20 Aug 2025 12:29:34 GMT, David Holmes wrote: > I've added some additional mailing lists to ensure better coverage here. > > Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes. Please provide an example of an updated title? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209975632 From asemenov at openjdk.org Thu Aug 21 10:34:04 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 10:34:04 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Wed, 20 Aug 2025 12:22:18 GMT, David Holmes wrote: >> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/hotspot/share/c1/c1_LinearScan.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/hotspot/share/adlc/output_h.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1319: > >> 1317: log_if_needed(" ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no", >> 1318: is_scatter, is_scatter ? "scatter" : "gather", >> 1319: num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type())); > > There is a bug here but I'm not sure it is what you think it is. ```addr_type->isa_aryptr();``` might return nullptr, while in ```elem_consistent_with_arr(elem_bt, arr_type, false)```, arr_type is only checked with an assert. Moreover, the presence of a check in the original version indicates that arr_type can be null, and there is no protection against this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290615638 From asemenov at openjdk.org Thu Aug 21 11:11:56 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 11:11:56 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 09:59:01 GMT, Andrew Dinn wrote: >> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error > > Hmm, is it possible? > > Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe? ```head->next()``` returns a pointer to _next without any checks. In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread. >From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr. But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290701959 From duke at openjdk.org Thu Aug 21 11:59:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 11:59:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > CPUTimeUsage::Runtime::vm_thread() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== > > > Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove CPUTimeUsage::Runtime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26621/files - new: https://git.openjdk.org/jdk/pull/26621/files/f29d5af4..b7fdc0f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=10-11 Stats: 12 lines in 3 files changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621 PR: https://git.openjdk.org/jdk/pull/26621 From duke at openjdk.org Thu Aug 21 11:59:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 11:59:38 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v11] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit I had an offline discussion with @albertnetymk (thanks for bringing this up!) and we both agree that the current definition of `CPUTimeUsage::Runtime::vm_thread()` may be misread. As a consequence, we believe that expanding this interface to include more components would be best served by creating a separate PR that can serve as an explicit discussion for the layout. As such I'm removing `CPUTimeUsage::Runtime` from this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210275213 From ayang at openjdk.org Thu Aug 21 12:08:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 21 Aug 2025 12:08:56 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> CPUTimeUsage::Runtime::vm_thread() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] VM Thread 5.2992 0.33 0.1 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== >> >> >> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove CPUTimeUsage::Runtime Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3140358434 From adinn at openjdk.org Thu Aug 21 12:11:53 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Aug 2025 12:11:53 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 11:09:12 GMT, Artem Semenov wrote: > Moreover, pos_idx is also not being checked I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test. The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so. n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290852355 From duke at openjdk.org Thu Aug 21 12:15:18 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 12:15:18 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v33] In-Reply-To: References: Message-ID: <1TLlItn-8vRld4VIyGp0DyaVmeY7yel_Txp-yKzbx2A=.2e609b60-a9d8-4154-8476-2339e523f66d@github.com> > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewers' comments - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - 8357086: Fixed whitespace error - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - ... and 25 more: https://git.openjdk.org/jdk/compare/02fe095d...99599ae3 ------------- Changes: https://git.openjdk.org/jdk/pull/25450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=32 Stats: 259 lines in 23 files changed: 97 ins; 2 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From ihse at openjdk.org Thu Aug 21 12:19:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 21 Aug 2025 12:19:01 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: <0LwZCnCEv_YJU0E4pfVln83BASYzR6FCPErCCuUnGpw=.7d5a8ca7-c517-416e-ace7-f87f215c9083@github.com> On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - conditional includes > - variants That's interesting. Hopefully there is some consistency between compilers of how long time headers take to process. Ideally, we should get the same information from Microsoft CL, but I suspect that is not possible. (Since on Windows PCH makes the largest difference of any platform.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3210358607 From stefank at openjdk.org Thu Aug 21 12:20:04 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Aug 2025 12:20:04 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v33] In-Reply-To: <1TLlItn-8vRld4VIyGp0DyaVmeY7yel_Txp-yKzbx2A=.2e609b60-a9d8-4154-8476-2339e523f66d@github.com> References: <1TLlItn-8vRld4VIyGp0DyaVmeY7yel_Txp-yKzbx2A=.2e609b60-a9d8-4154-8476-2339e523f66d@github.com> Message-ID: On Thu, 21 Aug 2025 12:15:18 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs > - 8357086: Addressed reviewer's comments > - 8357086: Addressed reviewers' comments > - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs > - 8357086: Addressed reviewer's comments > - 8357086: Addressed reviewer's comments > - 8357086: Fixed whitespace error > - 8357086: Addressed reviewer's comments > - 8357086: Addressed reviewer's comments > - 8357086: Addressed reviewer's comments > - ... and 25 more: https://git.openjdk.org/jdk/compare/02fe095d...99599ae3 src/hotspot/os/windows/os_windows.cpp line 869: > 867: return true; > 868: } else { > 869: assert(false, "GlobalMemoryStatusEx failed in os::available_memory(): %lu", ::GetLastError()); I didn't request this to be changed and it was changed to the wrong function name. Suggestion: assert(false, "GlobalMemoryStatusEx failed in os::win32::available_memory(): %lu", ::GetLastError()); Tip: you can accept suggestions in the GitHub UI to get exactly what the reviewer requested (if you are brave enough to trust the reviewer :D ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290870945 From ihse at openjdk.org Thu Aug 21 12:21:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 21 Aug 2025 12:21:00 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4] In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com> References: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com> <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com> Message-ID: On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> after suggestion from Daniel > > It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run. > > I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). > > Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources. > @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds. That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3210365303 From kbarrett at openjdk.org Thu Aug 21 12:23:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 12:23:55 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> References: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> Message-ID: On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3140418082 From kbarrett at openjdk.org Thu Aug 21 12:23:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 12:23:56 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com> References: <7Fv64aM-zFkcWUby8KbInLT4AvxV9MRACDkp1_3s4JQ=.fbc07ee0-5177-4d42-bef8-5ad9a2f96db8@github.com> <9ON1pRJ6eZcRYoDahh1w2hCT95YZS9Z_2ORMj-laVZs=.aabd607e-72a7-4c6b-a2b6-8475feff4d41@github.com> Message-ID: On Thu, 21 Aug 2025 06:34:41 GMT, David Holmes wrote: >> src/hotspot/share/runtime/os.hpp line 810: >> >>> 808: // Performs vsnprintf and asserts the result is non-negative (so there was not >>> 809: // an encoding error or any other kind of usage error). >>> 810: [[nodiscard]] static int vsnprintf(char* buf, size_t len, const char* fmt, va_list args) ATTRIBUTE_PRINTF(3, 0); >> >> Consider moving the `ATTRIBUTE_PRINTF` to the front so all the attributes are together? >> And maybe a line break between the attributes and the signature, just to avoid pushing the >> signature way over to the right. > > I have done that and placed each attribute on its own line (we should have a style guide entry for this :) ). But I note that all the other ATTRIBUTE_PRINTF's are placed after the function. What you've done here matches what I did when adding `[[noreturn]]` to `report_xxx` functions in debug.hpp. So I'm good with that. The style guide already has this guidance: https://github.com/openjdk/jdk/blame/02fe095d29994bec28c85beb6bf2a69b0f49b206/doc/hotspot-style.md#L1120-L1122 There's just lots of old, non-conforming code. :) I forgot about that when I said "Consider moving", and should have pointed to the style guide. Whether and where there should be line breaks is something the style guide leaves to authors and reviewers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2290880828 From duke at openjdk.org Thu Aug 21 12:30:40 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 21 Aug 2025 12:30:40 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v34] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8357086: Fixed method name in assert in os_windows.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/99599ae3..b9cd155d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=32-33 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From stefank at openjdk.org Thu Aug 21 12:43:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Aug 2025 12:43:02 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v34] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 12:30:40 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Fixed method name in assert in os_windows.cpp > > Co-authored-by: Stefan Karlsson I think this now looks good to get integrated. I still would like to get approvals from others that have been involved in reviewing this. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3140493806 From jsjolen at openjdk.org Thu Aug 21 12:54:51 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 21 Aug 2025 12:54:51 GMT Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Message-ID: On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner wrote: > Hi all, > > The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. > > I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26744#pullrequestreview-3140536962 From coleenp at openjdk.org Thu Aug 21 13:03:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Aug 2025 13:03:03 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v33] In-Reply-To: References: <1TLlItn-8vRld4VIyGp0DyaVmeY7yel_Txp-yKzbx2A=.2e609b60-a9d8-4154-8476-2339e523f66d@github.com> Message-ID: On Thu, 21 Aug 2025 12:17:02 GMT, Stefan Karlsson 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 35 commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs >> - 8357086: Addressed reviewer's comments >> - 8357086: Addressed reviewers' comments >> - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs >> - 8357086: Addressed reviewer's comments >> - 8357086: Addressed reviewer's comments >> - 8357086: Fixed whitespace error >> - 8357086: Addressed reviewer's comments >> - 8357086: Addressed reviewer's comments >> - 8357086: Addressed reviewer's comments >> - ... and 25 more: https://git.openjdk.org/jdk/compare/02fe095d...99599ae3 > > src/hotspot/os/windows/os_windows.cpp line 869: > >> 867: return true; >> 868: } else { >> 869: assert(false, "GlobalMemoryStatusEx failed in os::available_memory(): %lu", ::GetLastError()); > > I didn't request this to be changed and it was changed to the wrong function name. > > Suggestion: > > assert(false, "GlobalMemoryStatusEx failed in os::win32::available_memory(): %lu", ::GetLastError()); > > > Tip: you can accept suggestions in the GitHub UI to get exactly what the reviewer requested (if you are brave enough to trust the reviewer :D ) Yes, this is really convenient but you have to remember to pull back to your local repo if you want to make additional changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2290988873 From coleenp at openjdk.org Thu Aug 21 13:03:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Aug 2025 13:03:52 GMT Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Message-ID: On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner wrote: > Hi all, > > The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. > > I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26744#pullrequestreview-3140555973 From duke at openjdk.org Thu Aug 21 13:03:53 2025 From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Thu, 21 Aug 2025 13:03:53 GMT Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics In-Reply-To: References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Message-ID: <5Y1nwFwNO7OtJ8Jdw0QvcMKRuRzFAkhYDcxFnm89zgQ=.9e48d059-7e2c-47ac-9690-75311501a348@github.com> On Thu, 21 Aug 2025 12:52:35 GMT, Johan Sj?len wrote: >> Hi all, >> >> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. >> >> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. > > Marked as reviewed by jsjolen (Reviewer). Thanks for reviewing, @jdksjolen and @coleenp! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26744#issuecomment-3210500698 From duke at openjdk.org Thu Aug 21 13:03:53 2025 From: duke at openjdk.org (duke) Date: Thu, 21 Aug 2025 13:03:53 GMT Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Message-ID: On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner wrote: > Hi all, > > The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. > > I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. @Arraying Your change (at version 392dd29e4e61c8b369b83fcbd9309021a719d857) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26744#issuecomment-3210508721 From stefank at openjdk.org Thu Aug 21 13:14:03 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Aug 2025 13:14:03 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v33] In-Reply-To: References: <1TLlItn-8vRld4VIyGp0DyaVmeY7yel_Txp-yKzbx2A=.2e609b60-a9d8-4154-8476-2339e523f66d@github.com> Message-ID: On Thu, 21 Aug 2025 12:59:59 GMT, Coleen Phillimore wrote: >> src/hotspot/os/windows/os_windows.cpp line 869: >> >>> 867: return true; >>> 868: } else { >>> 869: assert(false, "GlobalMemoryStatusEx failed in os::available_memory(): %lu", ::GetLastError()); >> >> I didn't request this to be changed and it was changed to the wrong function name. >> >> Suggestion: >> >> assert(false, "GlobalMemoryStatusEx failed in os::win32::available_memory(): %lu", ::GetLastError()); >> >> >> Tip: you can accept suggestions in the GitHub UI to get exactly what the reviewer requested (if you are brave enough to trust the reviewer :D ) > > Yes, this is really convenient but you have to remember to pull back to your local repo if you want to make additional changes. Yes and git will remind you about that if you try to push without doing so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2291021344 From asemenov at openjdk.org Thu Aug 21 13:21:02 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 21 Aug 2025 13:21:02 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 12:09:38 GMT, Andrew Dinn wrote: >> ```head->next()``` returns a pointer to _next without any checks. >> >> In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread. >> >> From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr. >> >> But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch. > >> Moreover, pos_idx is also not being checked > > I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test. > > The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so. > > n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works. pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size. I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer and confirmed by a specialist from another organization. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?. As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form. I certainly do not claim to understand this code as well as you or any other member of the hotspot team. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291041769 From sgehwolf at openjdk.org Thu Aug 21 13:43:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 21 Aug 2025 13:43:04 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v34] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 12:30:40 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Fixed method name in assert in os_windows.cpp > > Co-authored-by: Stefan Karlsson This looks OK as far as the container code is concerned. I can do the cleanup after this patch to align to the `size_t` changes here. ------------- PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3140742611 From duke at openjdk.org Thu Aug 21 13:52:53 2025 From: duke at openjdk.org (duke) Date: Thu, 21 Aug 2025 13:52:53 GMT Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v12] In-Reply-To: References: Message-ID: <7-F_uRu2j1uwCfI9QrIcLpaZ15gJVft_sNJlN7DicRc=.0d4f66ca-77f6-4f8e-bdbd-76fa86dbcaa2@github.com> On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). >> >> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: >> >> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() >> >> CPUTimeUsage::GC::gc_threads() >> CPUTimeUsage::GC::vm_thread() >> CPUTimeUsage::GC::stringdedup() >> >> >> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. >> >> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: >> >> >> [71.425s][info][cpu ] === CPU time Statistics ============================================================= >> [71.425s][info][cpu ] CPUs >> [71.425s][info][cpu ] s % utilized >> [71.425s][info][cpu ] Process >> [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 >> [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 >> [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 >> [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 >> [71.425s][info][cpu ] ===================================================================================== > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Remove CPUTimeUsage::Runtime @JonasNorlinder Your change (at version b7fdc0f8c608ecfdd6a4f6a875b8cd6a58ace5c8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210699903 From duke at openjdk.org Thu Aug 21 14:03:02 2025 From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Thu, 21 Aug 2025 14:03:02 GMT Subject: Integrated: 8365378: Redundant code in Deoptimization::print_statistics In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com> Message-ID: <3LMWDafvRRpdpnP5iSjsoraBzAoHhBENK_lWPzQnNng=.665dbfce-05fb-470c-baf8-b4403207950a@github.com> On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner wrote: > Hi all, > > The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability. > > I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures. This pull request has now been integrated. Changeset: 1548ac4f Author: Paul H?bner Committer: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/1548ac4f54edbd370aa071fa1db4474574d2987f Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8365378: Redundant code in Deoptimization::print_statistics Reviewed-by: jsjolen, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/26744 From duke at openjdk.org Thu Aug 21 14:08:05 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 21 Aug 2025 14:08:05 GMT Subject: Integrated: 8364638: Refactor and make accumulated GC CPU time code generic In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:59:43 GMT, Jonas Norlinder wrote: > Hi all, > > This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110). > > As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports: > > CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup() > > CPUTimeUsage::GC::gc_threads() > CPUTimeUsage::GC::vm_thread() > CPUTimeUsage::GC::stringdedup() > > > I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC. > > I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table: > > > [71.425s][info][cpu ] === CPU time Statistics ============================================================= > [71.425s][info][cpu ] CPUs > [71.425s][info][cpu ] s % utilized > [71.425s][info][cpu ] Process > [71.425s][info][cpu ] Total 1616.3627 100.00 22.6 > [71.425s][info][cpu ] Garbage Collection 83.7322 5.18 1.2 > [71.425s][info][cpu ] GC Threads 82.7671 5.12 1.2 > [71.425s][info][cpu ] VM Thread 0.9651 0.06 0.0 > [71.425s][info][cpu ] ===================================================================================== This pull request has now been integrated. Changeset: fb651fd6 Author: Jonas Norlinder Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/fb651fd6d246e69b42363e050eb8d96afb633eed Stats: 281 lines in 11 files changed: 202 ins; 76 del; 3 mod 8364638: Refactor and make accumulated GC CPU time code generic Reviewed-by: ayang, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/26621 From lmesnik at openjdk.org Thu Aug 21 14:30:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Aug 2025 14:30:04 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v13] In-Reply-To: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> References: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> Message-ID: On Wed, 20 Aug 2025 16:48:56 GMT, Leonid Mesnik wrote: >> The method >> get_jvmti_thread_state() >> should be called only while thread is in vm state. >> >> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. >> >> The fix was found using jvmti stress agent and thus no additional regression test is required. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed comment. I see that that post_method_exit in the `void InterpreterMacroAssembler::notify_method_exit(..)` is called only when thread is in interp_only mode. So it is ok to call current_frame.interpreter_frame_result(&oop_result, &value); I did this, and why I trying to understand what would be result in the case of `exception_exit == true` I realized that it is still safe, because this method always exit normally. So let me split this fix into 2 separate issues and fix them separately. I filed https://bugs.openjdk.org/browse/JDK-8365937 to don't change posting because of `exception_exit` ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3210843477 From adinn at openjdk.org Thu Aug 21 14:34:53 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Aug 2025 14:34:53 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 13:18:26 GMT, Artem Semenov wrote: >>> Moreover, pos_idx is also not being checked >> >> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test. >> >> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so. >> >> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works. > > pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size. > > I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?. > > As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form. > > I certainly do not claim to understand this code as well as you or any other member of the hotspot team. Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me abut a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant. I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers. Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful. Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291265263 From kbarrett at openjdk.org Thu Aug 21 14:38:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 14:38:05 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. Withdrawing this discussion PR, in preparation for the real PR to use C++17 for building, with an update to the HotSpot Style Guide for C++17 feature usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3210870612 From kbarrett at openjdk.org Thu Aug 21 14:38:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 14:38:05 GMT Subject: Withdrawn: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett wrote: > I'm hijacking the PR mechanism as a way to discuss new C++17 features that can > be more easily structured and captured than bare email. Once discussion > settles down I'll turn the results into HotSpot Style Guide changes. I don't > intend to integrate any version of this document to the OpenJDK repository. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25992 From kbarrett at openjdk.org Thu Aug 21 14:58:31 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 14:58:31 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 Message-ID: Please review this change to use C++17 for building C++ parts of the JDK. In particular this affects HotSpot. This change also includes an update to the HotSpot Style Guide regarding C++17 features and their use in HotSpot code. Testing: mach5 tier1-8 This change includes a modification of the Style Guide. Rough consensus among the HotSpot Group members is required to make such a change. Only Group members should vote for approval (via the github PR), though reasoned objections or comments from anyone will be considered. A decision on this proposal will not be made before Friday 5-September-2025 at 12h00 UTC. Since we're piggybacking on github PRs here, please use the PR review process to approve (click on Review Changes > Approve), rather than sending a "vote: yes" email reply that would be normal for a CFV. ------------- Commit messages: - fix a couple trailing whitespace issues - update style guide for c++17 - build with c++17 Changes: https://git.openjdk.org/jdk/pull/26884/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314488 Stats: 1183 lines in 7 files changed: 1097 ins; 35 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/26884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26884/head:pull/26884 PR: https://git.openjdk.org/jdk/pull/26884 From iveresov at openjdk.org Thu Aug 21 15:01:54 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 15:01:54 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> Message-ID: <8m6eeYwRwgfqafcvuhnXo19A-HaYMBM3eS4l7cVgu6w=.00285c38-24d1-4d07-9bcf-2024cb342b74@github.com> On Thu, 21 Aug 2025 03:15:18 GMT, David Holmes wrote: >> There is an `Atomic::sub()` in `dec_init_deps_left()`. > > Okay - not obvious we actually require acquire semantics when reading a simple count, but I'm not sure what the count may imply. But please consider renaming the method. Let me think some more about this one. May we don't need it indeed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291340597 From jwaters at openjdk.org Thu Aug 21 15:21:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 21 Aug 2025 15:21:52 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 14:47:14 GMT, Kim Barrett wrote: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. There's a "CXXFLAGS := -std=c++17" in java.base Lib.gmk that's also no longer needed once the switch to C++17 is made (See https://github.com/openjdk/jdk/pull/14988/files) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3211074096 From kvn at openjdk.org Thu Aug 21 15:25:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 21 Aug 2025 15:25:57 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: Message-ID: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> On Thu, 21 Aug 2025 06:26:43 GMT, Yasumasa Suenaga wrote: >>> > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. >>> >>> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14". >>> >>> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like? >> >> I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets". > > I removed number of threads information on hybrid CPU. @dholmes-ora Can you review? > We can get following strings on hybrid CPU after this change: > > > CPU: total 14 (initial active 14) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid > CPU Model and flags from /proc/cpuinfo: > model name : Intel(R) Core(TM) Ultra 5 225U @YaSuenag Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? "( 2 P cores, 8 E cores, 2 LP cores)" in you case. I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ". It is important information when we debug issue on such CPUs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3211088436 From heidinga at openjdk.org Thu Aug 21 15:51:55 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 21 Aug 2025 15:51:55 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam wrote: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 96: > 94: // later in load_javabase_classes() and load_non_javabase_classes(). > 95: preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot1(), "boot1", Handle(), CHECK); > 96: preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot2(), "boot2", Handle(), CHECK); why do we maintain both a `boot1` and `boot2` set here when both are loaded before executing any Java code? Is the distinction meaningful for preloaded classes given both are loaded into the same classloader? src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 127: > 125: precond(ik->local_interfaces()->at(i)->is_loaded()); > 126: } > 127: }); This debugging check is duplicated in `SystemDictionary::preload_class` in the `#ifdef ASSERT` block. src/hotspot/share/cds/cdsHeapVerifier.cpp line 241: > 239: } > 240: if (field_ik == vmClasses::Boolean_klass()) { > 241: // TODO: check if is TRUE or FALSE Are we canonicalizing Boolean.TRUE & Boolean.FALSE and thus don't care if a static field points to them? And Boolean.TYPE isn't getting the same treatment? src/hotspot/share/classfile/javaClasses.cpp line 1017: > 1015: void java_lang_Class::set_mirror_module_field(JavaThread* current, Klass* k, Handle mirror, Handle module) { > 1016: if (CDSConfig::is_using_preloaded_classes()) { > 1017: oop archived_module = java_lang_Class:: module(mirror()); Suggestion: oop archived_module = java_lang_Class::module(mirror()); src/java.base/share/classes/java/net/URL.java line 1768: > 1766: > 1767: @AOTRuntimeSetup > 1768: private static void runtimeSetup() { Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto. Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run? src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 407: > 405: static class Holder { > 406: // All native libraries we've loaded. > 407: private static final Set loadedLibraryNames = I'm concerned about this causing problems if we ever AOT initialize a user class that calls `System.loadLibrary` from its static initializer. Should we add a check to the `clear()` method above to ensure that only the expected libraries have been loaded during the assembly phase? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283111220 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283328974 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283162998 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283173361 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283406179 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2291474398 From heidinga at openjdk.org Thu Aug 21 15:51:55 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 21 Aug 2025 15:51:55 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 20:33:45 GMT, Dan Heidinga wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > src/java.base/share/classes/java/net/URL.java line 1768: > >> 1766: >> 1767: @AOTRuntimeSetup >> 1768: private static void runtimeSetup() { > > Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto. > > Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run? Are there limits on the types of URLs we allow in the archived heap? ie: only file or jar? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2288785484 From lmesnik at openjdk.org Thu Aug 21 15:56:32 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Aug 2025 15:56:32 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding Message-ID: The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` to find if method exit normally or by exception. However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` where post_method_exit_inner is called directly. The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. The fix was a part of https://github.com/openjdk/jdk/pull/26713 for https://bugs.openjdk.org/browse/JDK-8365192 ------------- Commit messages: - more comments in the test - fixed ident - bugid fixed: - updated to fix 8365937 - fixed comment. - test renamed. - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred/libExceptionOccurred.cpp - Update src/hotspot/share/prims/jvmtiExport.cpp - added comments to the test - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/ExceptionOccurred.java - ... and 13 more: https://git.openjdk.org/jdk/compare/e04a3103...e8343e08 Changes: https://git.openjdk.org/jdk/pull/26886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365937 Stats: 334 lines in 5 files changed: 319 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26886/head:pull/26886 PR: https://git.openjdk.org/jdk/pull/26886 From lmesnik at openjdk.org Thu Aug 21 16:01:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Aug 2025 16:01:41 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v2] In-Reply-To: References: Message-ID: > The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates > `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` > to find if method exit normally or by exception. > However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See > `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` > where post_method_exit_inner is called directly. > > The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. > > > The fix was a part of > https://github.com/openjdk/jdk/pull/26713 > for > https://bugs.openjdk.org/browse/JDK-8365192 Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: assertion added. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26886/files - new: https://git.openjdk.org/jdk/pull/26886/files/e8343e08..d9319d90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26886/head:pull/26886 PR: https://git.openjdk.org/jdk/pull/26886 From kvn at openjdk.org Thu Aug 21 17:02:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 21 Aug 2025 17:02:55 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> On Thu, 21 Aug 2025 03:00:11 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup src/hotspot/share/compiler/compilationPolicy.cpp line 143: > 141: void CompilationPolicy::wait_replay_training_at_init(JavaThread* THREAD) { > 142: MonitorLocker locker(THREAD, TrainingReplayQueue_lock); > 143: while (!_training_replay_queue.is_empty_unlocked() || _training_replay_queue.is_processing_unlocked()) { Is this queue used in all phases? src/hotspot/share/oops/trainingData.cpp line 86: > 84: > 85: void TrainingData::verify() { > 86: if (TrainingData::have_data() && !TrainingData::assembling_data()) { Why assembly phase excluded? src/hotspot/share/oops/trainingData.cpp line 105: > 103: }); > 104: } > 105: if (TrainingData::need_data()) { I assume this is "training" run. Right? src/hotspot/share/oops/trainingData.cpp line 113: > 111: } else if (td->is_MethodTrainingData()) { > 112: MethodTrainingData* mtd = td->as_MethodTrainingData(); > 113: mtd->verify(false); Why it is `false` here? Comment please. src/hotspot/share/runtime/java.cpp line 522: > 520: if (AOTVerifyTrainingData) { > 521: EXCEPTION_MARK; > 522: CompilationPolicy::wait_replay_training_at_init(THREAD); It is called on VM exit but name is `_at_init`. May be drop that from name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291649772 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291646234 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291647689 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291642776 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291620321 From iveresov at openjdk.org Thu Aug 21 17:17:52 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 17:17:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> Message-ID: <_zLG3LFeo4k6m13wHgVdQH60i6NUftGGqRdPLgZTWAo=.6d12f710-1119-4cab-a3e8-13108ef2e0eb@github.com> On Thu, 21 Aug 2025 16:56:27 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup > > src/hotspot/share/oops/trainingData.cpp line 113: > >> 111: } else if (td->is_MethodTrainingData()) { >> 112: MethodTrainingData* mtd = td->as_MethodTrainingData(); >> 113: mtd->verify(false); > > Why it is `false` here? Comment please. I will add a comment. But this is the training run, so we don't have the dep counters setup yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291688602 From iveresov at openjdk.org Thu Aug 21 17:23:52 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 17:23:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> Message-ID: On Thu, 21 Aug 2025 16:58:08 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup > > src/hotspot/share/oops/trainingData.cpp line 86: > >> 84: >> 85: void TrainingData::verify() { >> 86: if (TrainingData::have_data() && !TrainingData::assembling_data()) { > > Why assembly phase excluded? We don't hookup the dep tracking machinery for some of the classes just yet. So the dep counter verification can fail. > src/hotspot/share/oops/trainingData.cpp line 105: > >> 103: }); >> 104: } >> 105: if (TrainingData::need_data()) { > > I assume this is "training" run. Right? Yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291704095 PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291704534 From iveresov at openjdk.org Thu Aug 21 17:28:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 17:28:55 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> Message-ID: <_5Fp5DsLJuOTEBharjk4bHiYXYNLw6waTRLVKcfZHKY=.43c6dd0d-7f58-4b46-bc78-342ad7996219@github.com> On Thu, 21 Aug 2025 16:59:54 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup > > src/hotspot/share/compiler/compilationPolicy.cpp line 143: > >> 141: void CompilationPolicy::wait_replay_training_at_init(JavaThread* THREAD) { >> 142: MonitorLocker locker(THREAD, TrainingReplayQueue_lock); >> 143: while (!_training_replay_queue.is_empty_unlocked() || _training_replay_queue.is_processing_unlocked()) { > > Is this queue used in all phases? For now just in production and assembly. During training the queue is there but is empty. But with iterative training it's going to be present during training. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291714279 From iveresov at openjdk.org Thu Aug 21 17:32:11 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 17:32:11 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v5] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <9WmlnzWGeCLGA4pUqmBw9jLDNXsOhA9JVfN7axi2ifM=.33a55a65-ab03-4f8d-8bdd-3037223fa007@github.com> > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: More cleanup and renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/289fb74c..edc8591d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=03-04 Stats: 30 lines in 4 files changed: 2 ins; 2 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From aph at openjdk.org Thu Aug 21 17:38:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 21 Aug 2025 17:38:55 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Thu, 21 Aug 2025 00:27:48 GMT, David Holmes wrote: > My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. The places where transition markers are placed may appear arbitrary, but that's not so. The process for determining the right place to put them goes as follows: Find a point where there is a write into the code cache which causes a trap. In the control-flow graph, this is a node in the dominator tree. Walk up the dominator tree (i.e. walk up the stack in GDB) towards the root until you find the highest node _N_ such that the majority of nodes dominated by _N_ also write into the code cache. Place a write-enable marker at the start of the function. Repeat this process until there are no more traps. "The majority" is a judgement call, but it's not difficult in most cases. For example, any function constructing an instance of `Assembler` is almost certain to dominate a write to the code cache, and likewise any function that patches code. While this process doesn't guarantee an optimal solution, in practice it works pretty well, and removes 99% of W^X mode switches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3211520068 From iveresov at openjdk.org Thu Aug 21 17:47:52 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 21 Aug 2025 17:47:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> Message-ID: On Thu, 21 Aug 2025 16:47:02 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup > > src/hotspot/share/runtime/java.cpp line 522: > >> 520: if (AOTVerifyTrainingData) { >> 521: EXCEPTION_MARK; >> 522: CompilationPolicy::wait_replay_training_at_init(THREAD); > > It is called on VM exit but name is `_at_init`. May be drop that from name. That's because `at_init` comes from `class initialization` events servicing. Those are enqueued after the class initialization is done. So, yes, it's at the shutdown, but the processing of class initializations is still happening. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291750973 From rcastanedalo at openjdk.org Thu Aug 21 18:26:51 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 21 Aug 2025 18:26:51 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 14:47:14 GMT, Kim Barrett wrote: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. doc/hotspot-style.html line 1544: > 1542: second members don't carry any useful information.

> 1543:

File System Library

> 1544:

The use of the File System library is forbidden. HotSpot doesn't very Suggestion:

The use of the File System library is forbidden. HotSpot doesn't do very ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2291827441 From pchilanomate at openjdk.org Thu Aug 21 18:29:52 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 21 Aug 2025 18:29:52 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v13] In-Reply-To: References: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> Message-ID: On Thu, 21 Aug 2025 01:58:23 GMT, David Holmes wrote: > To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand: > > ``` > { > ThreadInVMfromJava __tiv(thread); > state = get_jvmti_thread_state(thread); > } > ``` > > With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call: > > ``` > current_frame.interpreter_frame_result(&oop_result, &value); > current_frame.interpreter_frame_expression_stack_size() > 0 > ``` > > if we may not be in interp_only mode? > `InterpreterRuntime::post_method_exit` is only called from the interpreter, so the top frame should always be interpreted. > If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another? > I think that once we transition to vm there is no point in going back to Java to then possibly transition back to vm. The only reason to delay the transition was to have the `result` Handle be created outside of the `JRT_BLOCK` scope, so that we are able to restore the return oop (if any) after the last safepoint. That means we could move `JRT_BLOCK` even further up, right after declaring the locals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3211660186 From kvn at openjdk.org Thu Aug 21 18:32:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 21 Aug 2025 18:32:51 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> Message-ID: <122qZDRJNr0wRNgp-o6FJlmScBbsD0XWNfAw3XLaGjA=.a7b94197-9b8a-4bbc-984e-f26d1ad2e974@github.com> On Thu, 21 Aug 2025 17:45:02 GMT, Igor Veresov wrote: >> src/hotspot/share/runtime/java.cpp line 522: >> >>> 520: if (AOTVerifyTrainingData) { >>> 521: EXCEPTION_MARK; >>> 522: CompilationPolicy::wait_replay_training_at_init(THREAD); >> >> It is called on VM exit but name is `_at_init`. May be drop that from name. > > That's because `at_init` comes from `class initialization` events servicing. Those are enqueued after the class initialization is done. So, yes, it's at the shutdown, but the processing of class initializations is still happening. This is low level knowledge nobody except you know (now I know). For other people who looks on this, it is confusing. `_at_init` gives nothing to understand what code does. I think `wait_replay_training_to_finish()` may be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2291838685 From kbarrett at openjdk.org Thu Aug 21 18:43:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Aug 2025 18:43:51 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 15:19:09 GMT, Julian Waters wrote: > There's a "CXXFLAGS := -std=c++17" in java.base Lib.gmk that's also no longer needed once the switch to C++17 is made (See https://github.com/openjdk/jdk/pull/14988/files) Perhaps. Or perhaps that configuration should be sticky, in case that specific version is still needed when we move to c++20 :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3211697923 From lmesnik at openjdk.org Thu Aug 21 22:03:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Aug 2025 22:03:57 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v13] In-Reply-To: References: <2WiNyQ1Bok9HuJTW91X_zeY9lxu2D4h7Cjo7_X9N_X4=.6f3d2730-20b9-4c19-a6c5-0b0a13958fb5@github.com> Message-ID: On Thu, 21 Aug 2025 18:27:29 GMT, Patricio Chilano Mateo wrote: >> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand: >> >> { >> ThreadInVMfromJava __tiv(thread); >> state = get_jvmti_thread_state(thread); >> } >> >> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call: >> >> current_frame.interpreter_frame_result(&oop_result, &value); >> current_frame.interpreter_frame_expression_stack_size() > 0 >> >> if we may not be in interp_only mode? >> >> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another? > >> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand: >> >> ``` >> { >> ThreadInVMfromJava __tiv(thread); >> state = get_jvmti_thread_state(thread); >> } >> ``` >> >> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call: >> >> ``` >> current_frame.interpreter_frame_result(&oop_result, &value); >> current_frame.interpreter_frame_expression_stack_size() > 0 >> ``` >> >> if we may not be in interp_only mode? >> > `InterpreterRuntime::post_method_exit` is only called from the interpreter, so the top frame should always be interpreted. > > >> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another? >> > I think that once we transition to vm there is no point in going back to Java to then possibly transition back to vm. The only reason to delay the transition was to have the `result` Handle be created outside of the `JRT_BLOCK` scope, so that we are able to restore the return oop (if any) after the last safepoint. That means we could move `JRT_BLOCK` even further up, right after declaring the locals. Agree with @pchilano, the only oop handling should be done before JRT_BLOCK. And the part dealing with with `exception_exit` will be implemented separately in the: https://github.com/openjdk/jdk/pull/26886 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3212200933 From eastigeevich at openjdk.org Thu Aug 21 23:36:51 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 21 Aug 2025 23:36:51 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 15:43:03 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Hi @coleenp, > Could you please take a look? > @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage. Hi @dholmes-ora, I checked what was happening. The reproducer from JDK-8277444 simplified: - Thread 1 does: bigClass = Class.forName(); consumer.accept(bigClass); // Puts bigClass in QUEUE final Object o = bigClass.getConstructor().newInstance(); System.out.println(o.hashCode()); - Thread 2 does: final Class aClass = QUEUE.take(); Instrumentation.retransformClasses(aClass); `Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`. Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform before we start using it and the linking process starts. So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long. I think `Class.forName` does not do linking intentionally, for performance reasons. I hope I've got everything correctly from logs and sources. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3212401838 From dholmes at openjdk.org Fri Aug 22 00:16:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Aug 2025 00:16:50 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> References: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> Message-ID: On Thu, 21 Aug 2025 15:23:25 GMT, Vladimir Kozlov wrote: >> I removed number of threads information on hybrid CPU. @dholmes-ora Can you review? >> We can get following strings on hybrid CPU after this change: >> >> >> CPU: total 14 (initial active 14) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U > > @YaSuenag Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? > > "( 2 P cores, 8 E cores, 2 LP cores)" in you case. I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ". > > It is important information when we debug issue on such CPUs. @vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212532526 From kvn at openjdk.org Fri Aug 22 00:25:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 00:25:53 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> Message-ID: On Fri, 22 Aug 2025 00:14:16 GMT, David Holmes wrote: >> @YaSuenag Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? >> >> "( 2 P cores, 8 E cores, 2 LP cores)" in you case. I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ". >> >> It is important information when we debug issue on such CPUs. > > @vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores. @dholmes-ora okay. Then we need, at least, to print "(hybrid cpu)". ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212551582 From ysuenaga at openjdk.org Fri Aug 22 00:35:52 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 22 Aug 2025 00:35:52 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> References: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> Message-ID: On Thu, 21 Aug 2025 15:23:25 GMT, Vladimir Kozlov wrote: > Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? I hope so too, but it is difficult as @dholmes-ora said unfortunately. We can use `1Ah` leaf of `CPUID` to identify whether P core or not like [this code](https://github.com/YaSuenag/garakuta/blob/ebe4c8da6ed890f6144c1c32ff02b5ed3200df14/check-hybrid-cores/hy-core-check.c#L60-L95). However we would face following problem: 1. Leaf `1Ah` returns the information for the logical processor which was issued - we need to issue `CPUID` on all of logical processors with processor affinity. 2. We can identify "Intel Core" (P core) or not ("Intel Atom") via leaf `1Ah`, however we might not distinguish whether E core or LP core. * In Core Ultra 5 225U, both E core and LP core is Crestmont, thus they have same native model ID. OS (Windows and Linux at least) cannot expose information about details of CPU cores AFAICS, thus it is difficult to show processor details to the user on `VM.info` and hs_err log. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212570100 From kvn at openjdk.org Fri Aug 22 00:40:52 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 00:40:52 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> Message-ID: On Fri, 22 Aug 2025 00:33:10 GMT, Yasumasa Suenaga wrote: >> @YaSuenag Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? >> >> "( 2 P cores, 8 E cores, 2 LP cores)" in you case. I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ". >> >> It is important information when we debug issue on such CPUs. > >> Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? > > I hope so too, but it is difficult as @dholmes-ora said unfortunately. > > We can use `1Ah` leaf of `CPUID` to identify whether P core or not like [this code](https://github.com/YaSuenag/garakuta/blob/ebe4c8da6ed890f6144c1c32ff02b5ed3200df14/check-hybrid-cores/hy-core-check.c#L60-L95). However we would face following problem: > > 1. Leaf `1Ah` returns the information for the logical processor which was issued - we need to issue `CPUID` on all of logical processors with processor affinity. > 2. We can identify "Intel Core" (P core) or not ("Intel Atom") via leaf `1Ah`, however we might not distinguish whether E core or LP core. > * In Core Ultra 5 225U, both E core and LP core is Crestmont, thus they have same native model ID. > > OS (Windows and Linux at least) cannot expose information about details of CPU cores AFAICS, thus it is difficult to show processor details to the user on `VM.info` and hs_err log. @YaSuenag Thank you for additional information. Yes, I agree with David and you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212576807 From ysuenaga at openjdk.org Fri Aug 22 00:58:26 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 22 Aug 2025 00:58:26 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4] In-Reply-To: References: Message-ID: > `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: > > > CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss > CPU Model and flags from /proc/cpuinfo: > model name : Intel(R) Core(TM) Ultra 5 225U > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd > > > It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". > https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html > > According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 > In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Indicate "(hybrid)" on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26808/files - new: https://git.openjdk.org/jdk/pull/26808/files/b1fd242c..45c85012 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26808&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26808/head:pull/26808 PR: https://git.openjdk.org/jdk/pull/26808 From ysuenaga at openjdk.org Fri Aug 22 00:58:26 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 22 Aug 2025 00:58:26 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2] In-Reply-To: References: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com> Message-ID: On Fri, 22 Aug 2025 00:14:16 GMT, David Holmes wrote: >> @YaSuenag Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration? >> >> "( 2 P cores, 8 E cores, 2 LP cores)" in you case. I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ". >> >> It is important information when we debug issue on such CPUs. > > @vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores. Thanks a lot @dholmes-ora and @vnkozlov ! I updated this PR to show `(hybrid)` as @vnkozlov commented. We can see following strings after this change. I hope this patch confortable for you. CPU: total 14 (initial active 14) (hybrid) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid CPU Model and flags from /proc/cpuinfo: model name : Intel(R) Core(TM) Ultra 5 225U ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212598807 From kvn at openjdk.org Fri Aug 22 01:09:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 01:09:51 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Indicate "(hybrid)" on hybrid CPU Good. I will run out tests and let you know results. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26808#pullrequestreview-3142699505 From iveresov at openjdk.org Fri Aug 22 03:21:36 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 22 Aug 2025 03:21:36 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v6] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: More renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/edc8591d..f7d6a4e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=04-05 Stats: 15 lines in 5 files changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From iveresov at openjdk.org Fri Aug 22 03:21:36 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 22 Aug 2025 03:21:36 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v2] In-Reply-To: <8m6eeYwRwgfqafcvuhnXo19A-HaYMBM3eS4l7cVgu6w=.00285c38-24d1-4d07-9bcf-2024cb342b74@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <871DbNrXSrdwXxEynOq_fZjvQXMP30abzW17OxgIX4E=.30cb9ca0-914a-472e-aa38-34cb6c034e0e@github.com> <8m6eeYwRwgfqafcvuhnXo19A-HaYMBM3eS4l7cVgu6w=.00285c38-24d1-4d07-9bcf-2024cb342b74@github.com> Message-ID: On Thu, 21 Aug 2025 14:58:56 GMT, Igor Veresov wrote: >> Okay - not obvious we actually require acquire semantics when reading a simple count, but I'm not sure what the count may imply. But please consider renaming the method. > > Let me think some more about this one. May we don't need it indeed. Yeah, it's needed. I did the renaming you requested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2292597504 From iveresov at openjdk.org Fri Aug 22 03:21:37 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 22 Aug 2025 03:21:37 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v4] In-Reply-To: <122qZDRJNr0wRNgp-o6FJlmScBbsD0XWNfAw3XLaGjA=.a7b94197-9b8a-4bbc-984e-f26d1ad2e974@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <4P2y8gjeUOn0hXpJ3cJumGLqrLLx9c0FsAAmIZZDTBA=.23c103b1-c9dd-45a0-9289-99f4910c5bcf@github.com> <122qZDRJNr0wRNgp-o6FJlmScBbsD0XWNfAw3XLaGjA=.a7b94197-9b8a-4bbc-984e-f26d1ad2e974@github.com> Message-ID: <1nfqdRTlejsQoXqtGRmaLj7I1wGZ4Saoh-loyUW2WTo=.1f7a13ea-5c6d-4cf3-815c-8700651b22be@github.com> On Thu, 21 Aug 2025 18:30:10 GMT, Vladimir Kozlov wrote: >> That's because `at_init` comes from `class initialization` events servicing. Those are enqueued after the class initialization is done. So, yes, it's at the shutdown, but the processing of class initializations is still happening. > > This is low level knowledge nobody except you know (now I know). For other people who looks on this, it is confusing. `_at_init` gives nothing to understand what code does. I think `wait_replay_training_to_finish()` may be better. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2292597060 From iklam at openjdk.org Fri Aug 22 04:03:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:03:19 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v6] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @vnkozlov comments -- added AOTMapTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/4cc90093..cc42967c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=04-05 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From iklam at openjdk.org Fri Aug 22 04:09:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:09:28 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v7] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added comment about why -Xlog:aot+map,...,filesize=0 is needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/cc42967c..16895a2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=05-06 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From iklam at openjdk.org Fri Aug 22 04:09:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:09:40 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v5] In-Reply-To: References: Message-ID: <08JRJXstuGLd79bvob-z-15t2bXKW1J82N9u2z9a2jE=.cee50f31-e586-47b3-b6c4-5c7ac0b50622@github.com> On Tue, 19 Aug 2025 23:53:13 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed crash with ZGC > > src/hotspot/share/cds/aotMapLogger.hpp line 54: > >> 52: // >> 53: // Because the output can be large, it's best to save it to a file >> 54: // java -XX:AOTCache=app.aot -Xlog:aot+map*=trace:file=aot.map:none:filesize=0 --version > > why `filesize=0`? The map file is very large and by default UL will break it up into multiple files, each 20MB. `filesize=0` suppresses this behavior and keeps the file in a single piece. I added comments about this. > test/hotspot/jtreg/runtime/cds/CDSMapTest.java line 94: > >> 92: vmArgs.add("-Xlog:cds=debug"); >> 93: vmArgs.add("-Xshare:on"); >> 94: vmArgs.add("-Xlog:aot+map=debug,aot+map+oops=trace:file=" + mapName + ":none:filesize=0"); > > Looks like this test is intended for old CDS archive. Do you have test for new AOTCache workflow? I added a new test case for the AOTCache workflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26514#discussion_r2292639592 PR Review Comment: https://git.openjdk.org/jdk/pull/26514#discussion_r2292639839 From iklam at openjdk.org Fri Aug 22 04:13:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:13:55 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: <-as-u0Rcw01OFd4d-huLpncQoxCv1T04qiU8ol8wCic=.9093ccfc-b316-40a8-9fb8-72c96c59536b@github.com> On Mon, 18 Aug 2025 18:11:11 GMT, Dan Heidinga wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 96: > >> 94: // later in load_javabase_classes() and load_non_javabase_classes(). >> 95: preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot1(), "boot1", Handle(), CHECK); >> 96: preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot2(), "boot2", Handle(), CHECK); > > why do we maintain both a `boot1` and `boot2` set here when both are loaded before executing any Java code? Is the distinction meaningful for preloaded classes given both are loaded into the same classloader? This is still meaningful as the `boot1` classes from the dynamic CDS archive are still loaded at the end of `vmClasses::resolve_all()`, after some bytecodes are executed. > src/hotspot/share/cds/cdsHeapVerifier.cpp line 241: > >> 239: } >> 240: if (field_ik == vmClasses::Boolean_klass()) { >> 241: // TODO: check if is TRUE or FALSE > > Are we canonicalizing Boolean.TRUE & Boolean.FALSE and thus don't care if a static field points to them? And Boolean.TYPE isn't getting the same treatment? Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292643055 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292643019 From iklam at openjdk.org Fri Aug 22 04:19:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:19:52 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 16:59:45 GMT, Dan Heidinga wrote: >> src/java.base/share/classes/java/net/URL.java line 1768: >> >>> 1766: >>> 1767: @AOTRuntimeSetup >>> 1768: private static void runtimeSetup() { >> >> Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto. >> >> Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run? > > Are there limits on the types of URLs we allow in the archived heap? ie: only file or jar? This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else. There are several other classes where we have to do the same `SharedSecrets` set-up. @AOTRuntimeSetup private static void runtimeSetup() { SharedSecrets.setJavaNetURLAccess( new JavaNetURLAccess() { @Override public URLStreamHandler getHandler(URL u) { return u.handler; } } ); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292648610 From iklam at openjdk.org Fri Aug 22 04:54:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:54:41 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v2] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/15746239..b7a191d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Aug 22 04:54:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 04:54:42 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v2] In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 20:00:40 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comments > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 127: > >> 125: precond(ik->local_interfaces()->at(i)->is_loaded()); >> 126: } >> 127: }); > > This debugging check is duplicated in `SystemDictionary::preload_class` in the `#ifdef ASSERT` block. I removed this check. > src/hotspot/share/classfile/javaClasses.cpp line 1017: > >> 1015: void java_lang_Class::set_mirror_module_field(JavaThread* current, Klass* k, Handle mirror, Handle module) { >> 1016: if (CDSConfig::is_using_preloaded_classes()) { >> 1017: oop archived_module = java_lang_Class:: module(mirror()); > > Suggestion: > > oop archived_module = java_lang_Class::module(mirror()); Fixed. > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 407: > >> 405: static class Holder { >> 406: // All native libraries we've loaded. >> 407: private static final Set loadedLibraryNames = > > I'm concerned about this causing problems if we ever AOT initialize a user class that calls `System.loadLibrary` from its static initializer. > > Should we add a check to the `clear()` method above to ensure that only the expected libraries have been loaded during the assembly phase? The assembly phase shouldn't execute any user Java code. If that happens, it can result in many undesirable side effects. Loading user native library will be just one example. I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization. Maybe I should do that in a separate RFE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292686203 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292686311 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292684206 From prr at openjdk.org Fri Aug 22 05:54:55 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 22 Aug 2025 05:54:55 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50: > 48: * @summary URL.getContent() should return SoundClip for supported formats > 49: * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers > 50: */ I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds) Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what I think (120) is the default to 480. Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292765283 From dholmes at openjdk.org Fri Aug 22 06:38:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Aug 2025 06:38:56 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50: > >> 48: * @summary URL.getContent() should return SoundClip for supported formats >> 49: * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers >> 50: */ > > I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds) > Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what I think (120) is the default to 480. > Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough. @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292836043 From dholmes at openjdk.org Fri Aug 22 06:45:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Aug 2025 06:45:56 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 23:34:13 GMT, Evgeny Astigeevich wrote: >> Hi @coleenp, >> Could you please take a look? > >> @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage. > > Hi @dholmes-ora, > > I checked what was happening. > > The reproducer from JDK-8277444 simplified: > - Thread 1 does: > > bigClass = Class.forName(); > consumer.accept(bigClass); // Puts bigClass in QUEUE > final Object o = bigClass.getConstructor().newInstance(); > System.out.println(o.hashCode()); > > > - Thread 2 does: > > final Class aClass = QUEUE.take(); > Instrumentation.retransformClasses(aClass); > > > `Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`. > Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform before we start using it and the linking process starts. > > So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long. > > I think `Class.forName` does not do linking intentionally, for performance reasons. > > I hope I've got everything correctly from logs and sources. @eastig Thank you very much for that detailed analysis. An interesting scenario. I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first, rather than trying to coordinate the two pieces of code via the use of the init_lock. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3213233511 From azafari at openjdk.org Fri Aug 22 07:42:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 22 Aug 2025 07:42:29 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v2] In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: set high and low removed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26809/files - new: https://git.openjdk.org/jdk/pull/26809/files/aeea52ad..99f291c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=00-01 Stats: 29 lines in 1 file changed: 7 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From mdoerr at openjdk.org Fri Aug 22 09:08:21 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 22 Aug 2025 09:08:21 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v4] In-Reply-To: References: Message-ID: > We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. Martin Doerr 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 remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - Move nmethod entry barrier code up in the signal handler. - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - 8334247: [PPC64] Consider trap based nmethod entry barriers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24135/files - new: https://git.openjdk.org/jdk/pull/24135/files/16f9d58e..6c70ca40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24135&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24135&range=02-03 Stats: 92166 lines in 2311 files changed: 53405 ins; 26477 del; 12284 mod Patch: https://git.openjdk.org/jdk/pull/24135.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24135/head:pull/24135 PR: https://git.openjdk.org/jdk/pull/24135 From mdoerr at openjdk.org Fri Aug 22 10:04:59 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 22 Aug 2025 10:04:59 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 09:08:21 GMT, Martin Doerr wrote: >> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. > > Martin Doerr 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 remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Move nmethod entry barrier code up in the signal handler. > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - 8334247: [PPC64] Consider trap based nmethod entry barriers Waiting for https://github.com/openjdk/jdk/pull/26399. Will need to resolve. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3213809994 From jsjolen at openjdk.org Fri Aug 22 11:00:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 22 Aug 2025 11:00:53 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v6] In-Reply-To: References: Message-ID: <-5FpG_VXK4-3PRdQMI735JSAgAlux9jJ74hbiYYbxjs=.8bf7192a-85b8-4e11-bfe8-a9cec6f388ea@github.com> On Wed, 20 Aug 2025 09:05:19 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > remove stray macro src/hotspot/share/oops/metadata.hpp line 47: > 45: static constexpr uint32_t common_prefix_mask = 0xFFFF0000; > 46: static constexpr uint32_t instance_klass_token = 0x3E7A0101; > 47: static constexpr uint32_t array_klass_token = 0x3E7A0102; Why not ```c++ enum class Token : uint32_t { /* cases */ }; src/hotspot/share/oops/metadata.hpp line 50: > 48: > 49: unsigned get_metadata_token() const { return _token; } > 50: bool is_valid() const { return (get_metadata_token() & common_prefix) == common_prefix; } This looks like you meant to use `common_prefix_mask` when extracting the bits out of the token. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2293405040 PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2293408259 From tschatzl at openjdk.org Fri Aug 22 11:08:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 11:08:27 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v48] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into pull/23739 - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 55 more: https://git.openjdk.org/jdk/compare/e1c58f85...6c88f1de ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47 Stats: 7111 lines in 112 files changed: 2587 ins; 3587 del; 937 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From jsjolen at openjdk.org Fri Aug 22 11:08:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 22 Aug 2025 11:08:58 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 14:47:14 GMT, Kim Barrett wrote: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3144083455 From tschatzl at openjdk.org Fri Aug 22 11:41:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 11:41:27 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v49] In-Reply-To: References: Message-ID: <8ed2PRthKJNDf-El4SVUWmu-FZm311FTDmgr7mcokaI=.9f9a74ee-3306-474a-8eb4-8c6b4bd3db70@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * forgot to actually save the files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/6c88f1de..e8a8282b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=47-48 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From dlong at openjdk.org Fri Aug 22 12:01:59 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 22 Aug 2025 12:01:59 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. >> >> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. > > Artem Semenov has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/c1/c1_LinearScan.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/adlc/output_h.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Most of these mitigations to guard against a possible null pointer dereference are inside `if` expressions, which means if there was a null pointer, then we will now end up in the `else` clause, changing the behavior of the code to something that was perhaps unintended, and we still don't know what caused the null pointer. So this is just silently masking potential problems, and in my experience is usually not the correct fix. Most of the time the correct fix is to tell the static analyzer that it is a false positive and move on. Sometimes it is appropriate to add an assert or guarantee, and yes sometimes it is appropriate to do something different if there is a null, for example if it is a result of an allocation that can fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3212300703 From asemenov at openjdk.org Fri Aug 22 12:02:00 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 22 Aug 2025 12:02:00 GMT Subject: RFR: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2] In-Reply-To: References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Thu, 21 Aug 2025 14:32:43 GMT, Andrew Dinn wrote: > Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me about a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant. > > I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug report that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers. > > Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful. > > Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool. I?m sorry to have taken up your time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2293532235 From asemenov at openjdk.org Fri Aug 22 12:02:01 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 22 Aug 2025 12:02:01 GMT Subject: Withdrawn: 8365604: Null pointer dereference in src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com> Message-ID: On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov wrote: > The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26798 From mli at openjdk.org Fri Aug 22 12:22:31 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 22 Aug 2025 12:22:31 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v5] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: - indent - comments & readability ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26838/files - new: https://git.openjdk.org/jdk/pull/26838/files/9eef4961..80929e94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=03-04 Stats: 36 lines in 1 file changed: 29 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From mli at openjdk.org Fri Aug 22 12:22:31 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 22 Aug 2025 12:22:31 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v4] In-Reply-To: References: Message-ID: <-odaKdDHmsw_PwChtCHwRN_zo4_G7fnSBOYrgl4UZVs=.97599ecb-df6d-484b-bd76-90fe64804f51@github.com> On Wed, 20 Aug 2025 12:35:47 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > comments I refine the code a bit to improve the readability. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26838#issuecomment-3214174011 From mli at openjdk.org Fri Aug 22 12:22:32 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 22 Aug 2025 12:22:32 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v4] In-Reply-To: References: Message-ID: <_pipGJAYt4KQI46aG0DJtnbRYMdwmrsA1yMEoey6BHo=.5a32093f-b792-4026-8a6e-ae5ce7b4609f@github.com> On Thu, 21 Aug 2025 07:25:03 GMT, Dingli Zhang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5972: > >> 5970: // Check j.l.Float.floatToFloat16 for more information. >> 5971: // 10 bits >> 5972: slli(tmp1, dst, 9+32); > > Suggestion for adding some whitespace: > Suggestion: > > slli(tmp1, dst, 9 + 32); fixed, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26838#discussion_r2293573019 From kbarrett at openjdk.org Fri Aug 22 12:36:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 22 Aug 2025 12:36:55 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v2] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Fri, 22 Aug 2025 07:42:29 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > set high and low removed. src/hotspot/share/utilities/globalDefinitions.hpp line 644: > 642: inline jint high(jlong value) { return jint(value >> 32); } > 643: > 644: inline jlong jlong_from(jint h, jint l) { pre-existing: I didn't find any tests of this function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2293610645 From heidinga at openjdk.org Fri Aug 22 14:09:51 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 14:09:51 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v2] In-Reply-To: References: Message-ID: <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com> On Fri, 22 Aug 2025 04:16:57 GMT, Ioi Lam wrote: >> Are there limits on the types of URLs we allow in the archived heap? ie: only file or jar? > > This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else. > > There are several other classes where we have to do the same `SharedSecrets` set-up. > > > @AOTRuntimeSetup > private static void runtimeSetup() { > SharedSecrets.setJavaNetURLAccess( > new JavaNetURLAccess() { > @Override > public URLStreamHandler getHandler(URL u) { > return u.handler; > } > } > ); > } I'm less worried about this particular `runtimeSetup` implementation and more with what it implies. Namely that we have URL instances - with particular URLStreamHandlers associated with them - running around in the archived heap. If in production, a different URLStreamHandler is configured for a given URL, we'll get two different sets of validation logic for assembly time URLs vs production run URLs. Are we able to limit the protocols that we create URLs for? I'm reaching for some way to contain the potential issue to something smaller that we can reason about ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2293839048 From heidinga at openjdk.org Fri Aug 22 14:12:54 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 14:12:54 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 04:49:25 GMT, Ioi Lam wrote: > I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization. That would be a good check. Do we still assembly-time initialize Enums? I thought in earlier implementations we had initialized all enum classes but I'm having trouble finding the code now. If we do, the new "no user class initialized" check may fail on Enums ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2293846625 From dzhang at openjdk.org Fri Aug 22 14:53:57 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 22 Aug 2025 14:53:57 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 12:22:31 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - indent > - comments & readability LGTM, thanks! ------------- Marked as reviewed by dzhang (Author). PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3144815276 From liach at openjdk.org Fri Aug 22 15:06:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 22 Aug 2025 15:06:46 GMT Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests [v6] In-Reply-To: References: Message-ID: > For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25 Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java Co-authored-by: Andrew Haley - Variable name improvements - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade - Move other tier 4,5, etc tests to not use ClassReader - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade - Use classfile api instead of javac setting version - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade - ... and 1 more: https://git.openjdk.org/jdk/compare/7e384ee6...a659f538 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25124/files - new: https://git.openjdk.org/jdk/pull/25124/files/020659f3..a659f538 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=04-05 Stats: 294312 lines in 5181 files changed: 174425 ins; 82083 del; 37804 mod Patch: https://git.openjdk.org/jdk/pull/25124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124 PR: https://git.openjdk.org/jdk/pull/25124 From liach at openjdk.org Fri Aug 22 15:06:47 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 22 Aug 2025 15:06:47 GMT Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests [v5] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 16:11:16 GMT, Chen Liang wrote: >> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25 > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java > > Co-authored-by: Andrew Haley Circled back and renamed confusing variables in this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3214696304 From kvn at openjdk.org Fri Aug 22 15:16:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 15:16:55 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Indicate "(hybrid)" on hybrid CPU My testing passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3214735272 From kvn at openjdk.org Fri Aug 22 15:23:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 15:23:53 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v7] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 04:09:28 GMT, Ioi Lam wrote: >> Implement `-Xlog:aot+map` in the production run: >> >> >> $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ >> -Xlog:aot+map=file=aot.map:none:filesize=0 \ >> HelloWorld >> >> >> I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: >> >> 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. >> 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added comment about why -Xlog:aot+map,...,filesize=0 is needed Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26514#pullrequestreview-3144919886 From tschatzl at openjdk.org Fri Aug 22 16:01:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Aug 2025 16:01:26 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v50] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix merge error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/e8a8282b..cc4b7a0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=48-49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ayang at openjdk.org Fri Aug 22 16:10:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 16:10:58 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text > Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. I identified some cases that doesn't follow this. Unclear whether they are intentional. test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36: > 34: * @build jdk.test.whitebox.WhiteBox > 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox > 36: * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation Why not `480` in this case? test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40: > 38: * @requires vm.cds > 39: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 40: * @run driver/timeout=8000 LotsOfSyntheticClasses I was expecting `500 * 4 = 2000`, instead of `8000` here. test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > 29: * @compile SuspendResume2.java > 30: * @run driver jdk.test.lib.FileInstaller . . > 31: * @run main/othervm/native/timeout=700 Why `700` instead of `480` in this file? test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59: > 57: public class DGCDeadLock implements Runnable { > 58: final static public int HOLD_TARGET_TIME = 25000; > 59: public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4); Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000) * 4 * TestLibrary.getTimeoutFactor()`? test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60: > 58: * @comment skip running this test on 32 bit VM > 59: * @requires vm.bits == "64" > 60: * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest Why not `480`? test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34: > 32: * @build com.foobar.Utils > 33: * com.bar.* > 34: * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest Why not `480`? test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49: > 47: * @library /test/lib /test/jdk > 48: * @modules jdk.jfr/jdk.jfr.internal.test > 49: * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription Why not `480`? test/jdk/tools/jpackage/share/InstallDirTest.java line 69: > 67: * @compile -Xlint:all -Werror InstallDirTest.java > 68: * @requires (jpackage.test.SQETest != null) > 69: * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main Why more than `4x` in this file? test/langtools/jdk/jshell/HangingRemoteAgent.java line 38: > 36: class HangingRemoteAgent extends RemoteExecutionControl { > 37: > 38: private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0"))); why not `Utils.TIMEOUT_FACTOR`? test/langtools/jdk/jshell/UITesting.java line 148: > 146: } > 147: > 148: private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0"))); Why not `Utils.TIMEOUT_FACTOR`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243 From eastigeevich at openjdk.org Fri Aug 22 16:32:55 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 22 Aug 2025 16:32:55 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 06:42:48 GMT, David Holmes wrote: >>> @eastig I am not sure about this one. Can you clarify please how you can be transforming a class that has not yet been linked? If this is possible then it seems to me we are missing a call to ensure linkage. >> >> Hi @dholmes-ora, >> >> I checked what was happening. >> >> The reproducer from JDK-8277444 simplified: >> - Thread 1 does: >> >> bigClass = Class.forName(); >> consumer.accept(bigClass); // Puts bigClass in QUEUE >> final Object o = bigClass.getConstructor().newInstance(); >> System.out.println(o.hashCode()); >> >> >> - Thread 2 does: >> >> final Class aClass = QUEUE.take(); >> Instrumentation.retransformClasses(aClass); >> >> >> `Class.forName` does not link `bigClass`. So an unlinked class is put in a queue. The linking process starts when we start using `bigClass`. >> Thread 2 gets unlinked `bigClass` from the queue. It can request to retransform before we start using it and the linking process starts. >> >> So we can have the linking process and the retransforming process running in parallel. There is no synchronization between them. We get a race condition. `bigClass` is big enough to make the linking process running long. >> >> I think `Class.forName` does not do linking intentionally, for performance reasons. >> >> I hope I've got everything correctly from logs and sources. > > @eastig Thank you very much for that detailed analysis. An interesting scenario. I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first, rather than trying to coordinate the two pieces of code via the use of the init_lock. ? @dholmes-ora According to - https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.3 - https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.4 they allow flexibility in an implementation of the linking process. If I am correct, we have a "lazy" linkage strategy in Hotspot. I don't think we want to change anything here. `copy_bytecodes` is only used by JVMTI: - `JvmtiEnv::RetransformClasses` - `JvmtiEnv::GetBytecodes` > I still find it somewhat suspect that we can transform an unlinked class and wonder if we should instead ensure it is linked first, `JvmtiEnv::RetransformClasses` does not need a class to be linked. It needs the initial class file bytes which are the bytes passed to `ClassLoader.defineClass` or `RedefineClasses`. `JvmtiEnv::GetBytecodes` returns the bytecodes that implement the method. It's not clear from the JVMTI specification whether the returned bytecodes must be the initial class bytes. The current implementation returns the initial bytecodes the same used in `JvmtiEnv::RetransformClasses`. As we don't keep the initial bytecodes (do we?), `copy_bytecodes` cannot be called during linking, linking changes bytecodes. It can only be called for a class in the unlinked and linked states. When `copy_bytecodes` is called for a linked class, it restores bytecodes to the initial ones. Linking cannot be done whilst `copy_bytecodes` is working. If we use `init_lock`, `copy_bytecodes` will never see a class in the linking state. Linking will never see `copy_bytecodes`. As linking is blocked while we are copying bytecodes, the linking time will increase. This might have negative performance impact. Retrasforming obsoletes an original version of a method, if a new version of the method is installed. So we might not notice the performance impact. What other options do we have which don't require many changes? We have two mutually exclusive processes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3214952273 From kvn at openjdk.org Fri Aug 22 16:38:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 16:38:55 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v6] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Fri, 22 Aug 2025 03:21:36 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > More renames src/hotspot/share/compiler/compilationPolicy.cpp line 192: > 190: > 191: void CompilationPolicy::replay_training_at_init_loop(JavaThread* current) { > 192: while (!CompileBroker::is_compilation_disabled_forever() || AOTVerifyTrainingData) { Will it loop forever with `+ AOTVerifyTrainingData` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2294183959 From mli at openjdk.org Fri Aug 22 17:05:11 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 22 Aug 2025 17:05:11 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v6] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26838/files - new: https://git.openjdk.org/jdk/pull/26838/files/80929e94..be81ae2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26838&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26838/head:pull/26838 PR: https://git.openjdk.org/jdk/pull/26838 From prr at openjdk.org Fri Aug 22 17:20:57 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 22 Aug 2025 17:20:57 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50: > >> 48: * @summary URL.getContent() should return SoundClip for supported formats >> 49: * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers >> 50: */ > > I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds) > Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what I think (120) is the default to 480. > Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough. > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values. I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it. I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294258341 From iklam at openjdk.org Fri Aug 22 17:24:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 17:24:18 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/b7a191d8..ecc2581d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=01-02 Stats: 117 lines in 3 files changed: 117 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Aug 22 17:24:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 17:24:18 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com> References: <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com> Message-ID: On Fri, 22 Aug 2025 14:07:43 GMT, Dan Heidinga wrote: >> This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else. >> >> There are several other classes where we have to do the same `SharedSecrets` set-up. >> >> >> @AOTRuntimeSetup >> private static void runtimeSetup() { >> SharedSecrets.setJavaNetURLAccess( >> new JavaNetURLAccess() { >> @Override >> public URLStreamHandler getHandler(URL u) { >> return u.handler; >> } >> } >> ); >> } > > I'm less worried about this particular `runtimeSetup` implementation and more with what it implies. Namely that we have URL instances - with particular URLStreamHandlers associated with them - running around in the archived heap. If in production, a different URLStreamHandler is configured for a given URL, we'll get two different sets of validation logic for assembly time URLs vs production run URLs. > > Are we able to limit the protocols that we create URLs for? I'm reaching for some way to contain the potential issue to something smaller that we can reason about I added a check that URLs can be cache only if they use the `file` and `jtr` protocols, whose `URLStreamHandlers` cannot be overridden by the application. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294262042 From iklam at openjdk.org Fri Aug 22 17:46:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 17:46:14 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v4] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comment - add test: user enum types are not initialized in assembly phase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/ecc2581d..f12ad484 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=02-03 Stats: 43 lines in 1 file changed: 43 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From heidinga at openjdk.org Fri Aug 22 18:17:54 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 18:17:54 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: References: Message-ID: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> On Fri, 22 Aug 2025 17:24:18 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run src/hotspot/share/cds/aotOopChecker.cpp line 52: > 50: // Make sure we are not caching objects with assumptions that can be violated in > 51: // the production run. > 52: void AOTOopChecker::check(oop obj) { Should this also return a `bool` to indicate if the oop failed the check? It would make it easier to bail out in the caller if the oop was bad. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294377983 From iklam at openjdk.org Fri Aug 22 18:35:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 18:35:47 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comments -- added comments and asserts about the handling of enums ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/f12ad484..62014d4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=03-04 Stats: 11 lines in 3 files changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Aug 22 18:35:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 18:35:48 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> References: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> Message-ID: On Fri, 22 Aug 2025 18:15:28 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > > src/hotspot/share/cds/aotOopChecker.cpp line 52: > >> 50: // Make sure we are not caching objects with assumptions that can be violated in >> 51: // the production run. >> 52: void AOTOopChecker::check(oop obj) { > > Should this also return a `bool` to indicate if the oop failed the check? It would make it easier to bail out in the caller if the oop was bad. The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294399425 From heidinga at openjdk.org Fri Aug 22 18:35:48 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 18:35:48 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: References: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> Message-ID: <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com> On Fri, 22 Aug 2025 18:28:19 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/aotOopChecker.cpp line 52: >> >>> 50: // Make sure we are not caching objects with assumptions that can be violated in >>> 51: // the production run. >>> 52: void AOTOopChecker::check(oop obj) { >> >> Should this also return a `bool` to indicate if the oop failed the check? It would make it easier to bail out in the caller if the oop was bad. > > The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). > > This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop. The existing error handling - to log and bail out - are 100% right. We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294404235 From iklam at openjdk.org Fri Aug 22 18:41:53 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 18:41:53 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com> References: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com> Message-ID: On Fri, 22 Aug 2025 18:31:33 GMT, Dan Heidinga wrote: >> The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). >> >> This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop. > > The existing error handling - to log and bail out - are 100% right. We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can `MetaspaceShared::unrecoverable_writing_error()` will terminate the VM. So we will never return to the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294418224 From iklam at openjdk.org Fri Aug 22 18:41:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 18:41:54 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 14:10:02 GMT, Dan Heidinga wrote: >> The assembly phase shouldn't execute any user Java code. If that happens, it can result in many undesirable side effects. Loading user native library will be just one example. >> >> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization. >> >> Maybe I should do that in a separate RFE? > >> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization. > > That would be a good check. > > Do we still assembly-time initialize Enums? I thought in earlier implementations we had initialized all enum classes but I'm having trouble finding the code now. If we do, the new "no user class initialized" check may fail on Enums With JEP 483, if we find a cached instance of an enum class, this class is automatically marked as aot-initialized. Since we never execute user code (I filed [JDK-8366020](https://bugs.openjdk.org/browse/JDK-8366020) to check this), we won't have any cached instances of user enum classes. One risky area is the handling of enums in MethodTypes, so I added a added a test case to check that user enum types used by a Lambda expression are not initialized in the assembly phase. See https://github.com/openjdk/jdk/pull/26375/commits/f12ad484639b98a2714d27a7a99ec9a48193656b I also updated the comments in `HeapShared` and `CDSEnumKlass` about how enums are handled (JEP 483 vs legacy). See https://github.com/openjdk/jdk/pull/26375/commits/62014d4ff1dec5181362ca0c3eb0d89facf10283 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294414840 From ayang at openjdk.org Fri Aug 22 18:45:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 22 Aug 2025 18:45:53 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race wrote: > or don't do it. Adding `/timeout=480` is more or less don't do anything. The default timeout (if omitting `/timeout=...`) is 120, so: master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout. patch: TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294425045 From heidinga at openjdk.org Fri Aug 22 19:16:58 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 19:16:58 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3] In-Reply-To: References: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com> <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com> Message-ID: On Fri, 22 Aug 2025 18:39:16 GMT, Ioi Lam wrote: >> The existing error handling - to log and bail out - are 100% right. We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can > > `MetaspaceShared::unrecoverable_writing_error()` will terminate the VM. So we will never return to the caller. That makes sense. Thanks for confirming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294480616 From heidinga at openjdk.org Fri Aug 22 19:20:52 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 22 Aug 2025 19:20:52 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:35:47 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comments -- added comments and asserts about the handling of enums My concerns have been addressed. Thanks Ioi ------------- Marked as reviewed by heidinga (no project role). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3145577039 From iveresov at openjdk.org Fri Aug 22 20:22:51 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 22 Aug 2025 20:22:51 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v6] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: <7zawxaIMLdnM5VraQwvZL3wcj3v8vYtzEvJpWYwQLqg=.eecc2aa6-f47e-44b8-842b-10621e83c2ae@github.com> On Fri, 22 Aug 2025 16:35:48 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> More renames > > src/hotspot/share/compiler/compilationPolicy.cpp line 192: > >> 190: >> 191: void CompilationPolicy::replay_training_at_init_loop(JavaThread* current) { >> 192: while (!CompileBroker::is_compilation_disabled_forever() || AOTVerifyTrainingData) { > > Will it loop forever with `+ AOTVerifyTrainingData` ? Yes, it runs in a dedicated thread. It doesn't need to terminate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2294648538 From iveresov at openjdk.org Fri Aug 22 20:29:10 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 22 Aug 2025 20:29:10 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v7] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: One more nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/f7d6a4e0..c33d94bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From dlong at openjdk.org Fri Aug 22 20:30:52 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 22 Aug 2025 20:30:52 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include runtime/synchronizer.hpp This seems like the correct fix. Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3215539178 From wkemper at openjdk.org Fri Aug 22 21:45:04 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Aug 2025 21:45:04 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: <7DOD0VQ9oRjzSLKrfDhFe7SvK7ewKato2pS8TaiVLJE=.d45cafcc-6a6b-4aa5-af23-c9426cd5d224@github.com> On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas wrote: > The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. > > This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. Internal testing looks good. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3146240854 From cslucas at openjdk.org Fri Aug 22 21:53:56 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 22 Aug 2025 21:53:56 GMT Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 20:56:01 GMT, William Kemper wrote: >> Looks good to me. Have we run this change through our internal CI regression pipelines? > > Looks reasonable to me. I have the same question as @kdnilsen . I reviewed the tests internally with @earthling-amzn ; He said everything looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3215770829 From cslucas at openjdk.org Fri Aug 22 21:53:57 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 22 Aug 2025 21:53:57 GMT Subject: Integrated: 8356289: Shenandoah: Clean up SATB barrier runtime entry points In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas wrote: > The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part. > > This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests. This pull request has now been integrated. Changeset: f28f6189 Author: Cesar Soares Lucas URL: https://git.openjdk.org/jdk/commit/f28f6189721a86b1a6ad0a19cc38192af55eb45a Stats: 31 lines in 9 files changed: 1 ins; 8 del; 22 mod 8356289: Shenandoah: Clean up SATB barrier runtime entry points Reviewed-by: kdnilsen, ysr, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/26850 From kbarrett at openjdk.org Fri Aug 22 22:18:46 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 22 Aug 2025 22:18:46 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v2] In-Reply-To: References: Message-ID: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: fix missing word ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26884/files - new: https://git.openjdk.org/jdk/pull/26884/files/0876cacd..cdd11cce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26884/head:pull/26884 PR: https://git.openjdk.org/jdk/pull/26884 From kvn at openjdk.org Fri Aug 22 22:37:52 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 22 Aug 2025 22:37:52 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v6] In-Reply-To: <7zawxaIMLdnM5VraQwvZL3wcj3v8vYtzEvJpWYwQLqg=.eecc2aa6-f47e-44b8-842b-10621e83c2ae@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <7zawxaIMLdnM5VraQwvZL3wcj3v8vYtzEvJpWYwQLqg=.eecc2aa6-f47e-44b8-842b-10621e83c2ae@github.com> Message-ID: On Fri, 22 Aug 2025 20:20:25 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilationPolicy.cpp line 192: >> >>> 190: >>> 191: void CompilationPolicy::replay_training_at_init_loop(JavaThread* current) { >>> 192: while (!CompileBroker::is_compilation_disabled_forever() || AOTVerifyTrainingData) { >> >> Will it loop forever with `+ AOTVerifyTrainingData` ? > > Yes, it runs in a dedicated thread. It doesn't need to terminate. Add comment about this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2294873607 From iklam at openjdk.org Fri Aug 22 23:51:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 22 Aug 2025 23:51:22 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() Message-ID: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: InstanceKlass* x = ....; Klass* s = x->super(); // should call java_super() InstanceKlass::cast(s)->xyz(); The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: - `super()` returns `[Ljava/lang/Object;` - `java_super()` returns `Ljava/lang/Object;` However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. ------------- Commit messages: - Replace Klass::superklass() with Klass::java_super() - more fixes - 8366024: Remove unnecessary InstanceKlass::cast() Changes: https://git.openjdk.org/jdk/pull/26908/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26908&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366024 Stats: 98 lines in 15 files changed: 0 ins; 16 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/26908.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26908/head:pull/26908 PR: https://git.openjdk.org/jdk/pull/26908 From ysuenaga at openjdk.org Sat Aug 23 02:49:54 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 23 Aug 2025 02:49:54 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:14:11 GMT, Vladimir Kozlov wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Indicate "(hybrid)" on hybrid CPU > > My testing passed. Thank you @vnkozlov ! @dholmes-ora , are you ok this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3216156116 From kbarrett at openjdk.org Sat Aug 23 23:08:32 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 23 Aug 2025 23:08:32 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() Message-ID: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Please review this change that removes the function oopDesc::mark_addr(). It's kind of a suspicious function, since it is casting away the volatile for a location that has concurrent reads and writes. But there isn't any code that examines the value at the obtained address. Instead, it's just used as the base address for a few prefetches. We change those places accordingly, and remove the now unused mark_addr function. Testing: mach5 tier1 ------------- Commit messages: - remove mark_addr and fix callers Changes: https://git.openjdk.org/jdk/pull/26914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366037 Stats: 11 lines in 4 files changed: 1 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26914/head:pull/26914 PR: https://git.openjdk.org/jdk/pull/26914 From duke at openjdk.org Sun Aug 24 00:58:52 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sun, 24 Aug 2025 00:58:52 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor In-Reply-To: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: On Mon, 18 Aug 2025 08:30:27 GMT, Francesco Andreuzzi wrote: > We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. > > This change fixes a build failure I'm getting with clang20: > > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 43 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning > 43 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 48 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning > 48 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > 2 errors generated. > > > Testing: > - [x] tier1 fast-debug > - [x] tier2 fast-debug Hi @kimbarrett, could you have a look at this PR? I think the solution is reasonable, removes some possibly unnecessary code, and most importantly fixes a build error which occurs on recent clang versions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3217515213 From alanb at openjdk.org Sun Aug 24 09:58:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 24 Aug 2025 09:58:52 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang wrote: >>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values. >> >> I don't agree. >> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it. >> >> I am also questioning whether such a time out was demonstrated for this test. >> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. >> I can send you my query off-line so you can check it. Maybe it is incomplete. > >> or don't do it. > > Adding `/timeout=480` is more or less don't do anything. > > The default timeout (if omitting `/timeout=...`) is 120, so: > > master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout. > patch: TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout. > If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it. There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296595504 From qpzhang at openjdk.org Sun Aug 24 16:28:18 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Sun, 24 Aug 2025 16:28:18 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false Message-ID: In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which looks like an incorrect if-cond. This PR, 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. Tests include, 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=24` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 281 ns (baseline) to 63 ns (patched), about -80%. The average call count also decreased from 350 to 220, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -wi 2 -w 30 -i 1 -r 30 -t 1 -f 1`. 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences got almost same as baseline, or only slightly updated on various low limits checking. So, this makes sense. 3. Also run Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks. ------------- Commit messages: - 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false Changes: https://git.openjdk.org/jdk/pull/26917/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365991 Stats: 152 lines in 4 files changed: 85 ins; 31 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/26917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917 PR: https://git.openjdk.org/jdk/pull/26917 From duke at openjdk.org Sun Aug 24 22:42:55 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sun, 24 Aug 2025 22:42:55 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v2] In-Reply-To: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: <8yNjYVAnr_0dXmDsyAdJHFedP7sscW75n6XhgyTWWGM=.b6070c52-1286-4d3b-a08c-3713414bdde9@github.com> > We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. > > This change fixes a build failure I'm getting with clang20: > > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 43 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning > 43 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 48 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning > 48 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > 2 errors generated. > > > Testing: > - [x] tier1 fast-debug > - [x] tier2 fast-debug Francesco Andreuzzi 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 resolved-default-cctor - use copy ctor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26818/files - new: https://git.openjdk.org/jdk/pull/26818/files/c79f43ee..ba555768 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26818&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26818&range=00-01 Stats: 9130 lines in 413 files changed: 4589 ins; 3012 del; 1529 mod Patch: https://git.openjdk.org/jdk/pull/26818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26818/head:pull/26818 PR: https://git.openjdk.org/jdk/pull/26818 From dholmes at openjdk.org Sun Aug 24 22:54:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 24 Aug 2025 22:54:03 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36: > >> 34: * @build jdk.test.whitebox.WhiteBox >> 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox >> 36: * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation > > Why not `480` in this case? Leo also states in the description: > In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296840413 From david.holmes at oracle.com Sun Aug 24 23:03:52 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Aug 2025 09:03:52 +1000 Subject: Random crashes/failures on Linux Aarch64 Message-ID: Just a heads up that in recent times (still collating data) we have noticed quite a few seemingly random crashes, and failures, on Linux Aarch64. https://bugs.openjdk.org/browse/JDK-8364557 https://bugs.openjdk.org/browse/JDK-8365783 https://bugs.openjdk.org/browse/JDK-8365873 https://bugs.openjdk.org/browse/JDK-8365928 https://bugs.openjdk.org/browse/JDK-8365170 https://bugs.openjdk.org/browse/JDK-8365840 https://bugs.openjdk.org/browse/JDK-8364968 Still collecting data and trying to see the pattern(s) here, but was wondering if other CI's have also been seeing any issues? David From fyang at openjdk.org Mon Aug 25 01:55:04 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 25 Aug 2025 01:55:04 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v6] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:05:11 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix typo That looks better. Thanks for the extra code comment! ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3149639798 From aboldtch at openjdk.org Mon Aug 25 05:13:58 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 25 Aug 2025 05:13:58 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v4] In-Reply-To: References: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> Message-ID: On Wed, 20 Aug 2025 04:53:37 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/metadata.hpp line 49: >> >>> 47: static constexpr uint32_t common_prefix_mask = BUILD_32(0xFFFF, 0); >>> 48: static constexpr uint32_t instance_klass_token = BUILD_32(0x3E7A, 0x100); >>> 49: static constexpr uint32_t array_klass_token = BUILD_32(0x3E7A, 0x101); >> >> Nit / question: Any particular reason we're building the tokens with `BUILD_32(high, low)` instead of writing out the full literal (e.g. `0x3E7A0100`)? Is it mainly for readability or are there other considerations? > > None whatsoever, apart from readability. I changed to use plain constants. You can use `'` as a digit separator. If that was the readability you were looking after. ```c++ static constexpr uint32_t common_prefix = 0x3E7A'0000; static constexpr uint32_t common_prefix_mask = 0xFFFF'0000; static constexpr uint32_t instance_klass_token = 0x3E7A'0101; static constexpr uint32_t array_klass_token = 0x3E7A'0102; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2297128203 From dholmes at openjdk.org Mon Aug 25 05:50:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 05:50:51 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: <_1EITTUXnsot8Cmplf_3ZBhDi7kpqzXyHZM_GrdF5u8=.dc770146-6eed-4a6b-8729-ce5ab5030ffd@github.com> On Fri, 22 Aug 2025 20:28:08 GMT, Dean Long wrote: > This seems like the correct fix. Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect. @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3218916859 From dholmes at openjdk.org Mon Aug 25 06:46:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 06:46:56 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 23:34:13 GMT, Evgeny Astigeevich wrote: > Class.forName does not link bigClass. Just to be clear `Class.forName(name, false, loader)` would not initialize the class; the default form would initialize and thus link the class. The `Class.forName` spec does not state whether or not it actually performs full linking in the absence of initialization, though the hotspot implementation does not. Note that the preparation phase of linking must have occurred to get the Class object. The retransformation API's are somewhat vague about the exact state of a class to be retransformed - the class must be "modifiable" but that seems to be treated as a static rather than dynamic property ie. primitives, arrays, hidden classes are not modifiable - any other type of class instance is. Bottom line is that I don't think any of the specifications help us here, so we need to look at implementation practicalities. The linking code, uses the `init_lock` and assumes it cannot be interfered with in any way. I don't know either pieces of code well enough to say whether we could devise a lock-free protocol that would handle the current case; or whether we could use a VM mutex around the critical part of the linking code? I don't like JVM TI having to know anything about the `init_lock` and I don't like seeing another place where we acquire the `init_lock` via an `ObjectLocker`, as that does not play nicely with the work to avoid pinning for virtual threads. I'd like to hear from others more knowledgeable than myself in this area, unfortunately @coleenp is on vacation and won't be back till next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3219033001 From dholmes at openjdk.org Mon Aug 25 06:53:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 06:53:54 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 22:18:46 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix missing word doc/hotspot-style.md line 1333: > 1331: ### Enhanced selection statements > 1332: > 1333: C++17 modified the _condition_ part `if` and `switch` statements, permitting Suggestion: C++17 modified the _condition_ part of `if` and `switch` statements, permitting doc/hotspot-style.md line 1367: > 1365: ``` > 1366: > 1367: C++17 also added compile-time if statements Suggestion: C++17 also added compile-time `if` statements ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2297265971 PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2297268021 From dholmes at openjdk.org Mon Aug 25 07:02:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 07:02:53 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 22:18:46 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix missing word I have no concerns about the proposed additions and exclusion. Thanks for doing this significant update. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3150170671 From dholmes at openjdk.org Mon Aug 25 07:09:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 07:09:02 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> References: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> Message-ID: On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Thanks for the Review Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3219089008 From dholmes at openjdk.org Mon Aug 25 07:09:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 07:09:02 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: References: <7b5jd5fFIzxplaqLy5TXwS-nrrppgU1XOW86QBVmth4=.c9032bd4-7db7-4652-8b8a-eba41d43eebb@github.com> Message-ID: On Thu, 21 Aug 2025 07:46:18 GMT, Dean Long wrote: >> Yes but again if that happens during testing we need to know and fix the buffer size to get the non-truncated values. > > In this case the buffer size comes from shared code. Whatever size we choose for the static buffer, we can trigger the assert by setting LIBPATH and LD_LIBRARY_PATH to very long strings. This is just the error message, so it might be OK to truncate it. Otherwise we could need to allocate the buffer using malloc. I'm inclined to keep the assert and address any future problems if they arise. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26849#discussion_r2297294080 From shade at openjdk.org Mon Aug 25 08:55:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Aug 2025 08:55:52 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() In-Reply-To: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Sat, 23 Aug 2025 23:02:33 GMT, Kim Barrett wrote: > Please review this change that removes the function oopDesc::mark_addr(). > It's kind of a suspicious function, since it is casting away the volatile for > a location that has concurrent reads and writes. But there isn't any code that > examines the value at the obtained address. Instead, it's just used as the > base address for a few prefetches. We change those places accordingly, and > remove the now unused mark_addr function. > > Testing: mach5 tier1 This looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3150498322 From duke at openjdk.org Mon Aug 25 09:02:49 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 09:02:49 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3] In-Reply-To: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: > We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. > > This change fixes a build failure I'm getting with clang20: > > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 43 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning > 43 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 48 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning > 48 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > 2 errors generated. > > > Testing: > - [x] tier1 fast-debug > - [x] tier2 fast-debug Francesco Andreuzzi 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 resolved-default-cctor - Merge branch 'master' into resolved-default-cctor - use copy ctor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26818/files - new: https://git.openjdk.org/jdk/pull/26818/files/ba555768..2b51d610 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26818&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26818&range=01-02 Stats: 619 lines in 19 files changed: 257 ins; 299 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/26818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26818/head:pull/26818 PR: https://git.openjdk.org/jdk/pull/26818 From ayang at openjdk.org Mon Aug 25 09:18:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 09:18:32 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v3] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/5df3735a..88702f07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=01-02 Stats: 14036 lines in 528 files changed: 8315 ins; 3770 del; 1951 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From duke at openjdk.org Mon Aug 25 09:26:11 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 09:26:11 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v12] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with four additional commits since the last revision: - comment - nn - conditional - time-trace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/c0b8c277..df0a71d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=10-11 Stats: 524 lines in 4 files changed: 1 ins; 509 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Mon Aug 25 09:26:12 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 09:26:12 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v11] In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> References: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com> Message-ID: On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - conditional includes > - variants ### Amazon Linux 2 x86_64 + Docker `debian:bookworm-slim` | Git Ref | Compiler | Build flavor | Average (user+sys) | StdDev | |----------|--------|--------|----------|---------| | master | gcc | server | 2962.90 | 3.04 | | master | gcc | fd | 4165.31 | 4.36 | | master | gcc | custom | 677.99 | 0.45 | | master | clang | server | 2247.31 | 4.27 | | master | clang | fd | 3054.74 | 0.23 | | master | clang | custom | 496.13 | 1.30 | | 9e0cb7e8 | gcc | server | 2552.51 | 1.44 | | 9e0cb7e8 | gcc | fd | 3650.50 | 1.68 | | 9e0cb7e8 | gcc | custom | 630.25 | 1.80 | | 9e0cb7e8 | clang | server | 1826.63 | 4.21 | | 9e0cb7e8 | clang | fd | 2514.22 | 1.16 | | 9e0cb7e8 | clang | custom | 453.29 | 0.52 | | 892ecb5a | gcc | server | 2570.87 | 0.96 | | 892ecb5a | gcc | fd | 3644.73 | 7.16 | | 892ecb5a | gcc | custom | 626.08 | 2.83 | | 892ecb5a | clang | server | 1824.21 | 2.31 | | 892ecb5a | clang | fd | 2518.37 | 1.75 | | 892ecb5a | clang | custom | 453.56 | 0.74 | ### Amazon Linux 2 aarch64 + Docker `debian:bookworm-slim` | Git Ref | Compiler | Build flavor | Average (user+sys) | StdDev | |---------|--------|--------|----------|---------| | master | gcc | server | 2248.63 | 4.49 | | master | gcc | fd | 3238.64 | 4.29 | | master | gcc | custom | 523.34 | 6.50 | | master | clang | server | 1877.40 | 3.01 | | master | clang | fd | 2516.10 | 2.95 | | master | clang | custom | 437.22 | 1.22 | | 9e0cb7e8| gcc | server | 1811.81 | 5.17 | | 9e0cb7e8| gcc | fd | 2693.76 | 7.68 | | 9e0cb7e8| gcc | custom | 440.88 | 1.81 | | 9e0cb7e8| clang | server | 1406.12 | 6.20 | | 9e0cb7e8| clang | fd | 1872.41 | 13.27 | | 9e0cb7e8| clang | custom | 354.82 | 0.65 | | 892ecb5a| gcc | server | 1774.99 | 13.02 | | 892ecb5a| gcc | fd | 2623.76 | 1.51 | | 892ecb5a| gcc | custom | 428.87 | 1.05 | | 892ecb5a| clang | server | 1363.65 | 0.61 | | 892ecb5a| clang | fd | 1842.38 | 6.90 | | 892ecb5a| clang | custom | 344.98 | 1.21 | ### Fedora 42 x86_64 | Git Ref | Compiler | Build flavor | Average (user+sys) | StdDev | |----------|--------|--------|----------|---------| | master | gcc | server | 2713.01 | 3.68 | | master | gcc | fd | 3849.04 | 18.43 | | master | gcc | custom | 650.11 | 0.51 | | master | clang | server | 2227.25 | 0.95 | | master | clang | fd | 2998.13 | 0.37 | | master | clang | custom | 499.48 | 0.15 | | 9e0cb7e8 | gcc | server | 2398.33 | 1.41 | | 9e0cb7e8 | gcc | fd | 3449.44 | 1.61 | | 9e0cb7e8 | gcc | custom | 609.89 | 0.70 | | 9e0cb7e8 | clang | server | 1781.34 | 1.05 | | 9e0cb7e8 | clang | fd | 2431.96 | 0.37 | | 9e0cb7e8 | clang | custom | 451.13 | 0.22 | | 892ecb5a | gcc | server | 2407.65 | 2.21 | | 892ecb5a | gcc | fd | 3457.53 | 0.34 | | 892ecb5a | gcc | custom | 611.44 | 0.51 | | 892ecb5a | clang | server | 1784.70 | 0.69 | | 892ecb5a | clang | fd | 2437.44 | 0.82 | | 892ecb5a | clang | custom | 452.42 | 0.20 | ### Git Ref - 9e0cb7e8: First approach in this PR, counting header inclusions - 892ecb5a: `-ftime-trace` + ClangBuildAnalyzer (last commit) ### Compiler - Clang 20 - GCC 12 ### Build flavor - `fd`: `--enable-debug` - `custom`: `--with-jvm-variants=custom --enable-jvm-feature-epsilongc` Each of the measurements above was taken three times. I got some measurements using a cutoff of **100.000ms** in ClangBuildAnalyzer, so all headers taking more than that are included in `precompiled.hpp`. Overall, 892ecb5a95695d75cef80dfdf053e50a092b0784 (last commit) seems to perform better than both `master` and the initial approach I tried in this PR. It would be nice if other compilers would provide similar metrics as `-ftime-trace`, but I couldn't find anything useful. So far GCC seems to like the new precompiled set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3219345092 PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3219373245 From azafari at openjdk.org Mon Aug 25 09:32:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 25 Aug 2025 09:32:37 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: unit test added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26809/files - new: https://git.openjdk.org/jdk/pull/26809/files/99f291c3..b525ba07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=01-02 Stats: 28 lines in 1 file changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From kbarrett at openjdk.org Mon Aug 25 09:42:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 09:42:45 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: dholmes tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26884/files - new: https://git.openjdk.org/jdk/pull/26884/files/cdd11cce..47343922 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26884/head:pull/26884 PR: https://git.openjdk.org/jdk/pull/26884 From kbarrett at openjdk.org Mon Aug 25 09:44:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 09:44:52 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Mon, 25 Aug 2025 09:32:37 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > unit test added Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3150671876 From kbarrett at openjdk.org Mon Aug 25 10:12:31 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 10:12:31 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types Message-ID: Please review this change to the HotSpot Style Guide to permit trailing return types for functions. This is a modification of the Style Guide, so rough consensus among the HotSpot Group members is required to make this change. Only Group members should vote for approval (via the github PR), though reasoned objections or comments from anyone will be considered. A decision on this proposal will not be made before Monday 8-September-2025 at 12h00 UTC. Since we're piggybacking on github PRs here, please use the PR review process to approve (click on Review Changes > Approve), rather than sending a "vote: yes" email reply that would be normal for a CFV. ------------- Commit messages: - permit trailing return types Changes: https://git.openjdk.org/jdk/pull/26923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366057 Stats: 89 lines in 2 files changed: 80 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26923/head:pull/26923 PR: https://git.openjdk.org/jdk/pull/26923 From aph at openjdk.org Mon Aug 25 10:13:56 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 25 Aug 2025 10:13:56 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Mon, 25 Aug 2025 09:32:37 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > unit test added Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3150790307 From stefank at openjdk.org Mon Aug 25 10:48:58 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 25 Aug 2025 10:48:58 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() In-Reply-To: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Sat, 23 Aug 2025 23:02:33 GMT, Kim Barrett wrote: > Please review this change that removes the function oopDesc::mark_addr(). > It's kind of a suspicious function, since it is casting away the volatile for > a location that has concurrent reads and writes. But there isn't any code that > examines the value at the obtained address. Instead, it's just used as the > base address for a few prefetches. We change those places accordingly, and > remove the now unused mark_addr function. > > Testing: mach5 tier1 Looks good. I wonder though if it would make sense to have a function, say, `void* oopDesc::base_addr()` and use that instead of the added casts? ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3150893071 From lkorinth at openjdk.org Mon Aug 25 10:52:01 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 25 Aug 2025 10:52:01 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Sun, 24 Aug 2025 22:51:05 GMT, David Holmes wrote: >> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36: >> >>> 34: * @build jdk.test.whitebox.WhiteBox >>> 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox >>> 36: * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation >> >> Why not `480` in this case? > > Leo also states in the description: > >> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. In a few places, I have got timeouts after adjusting the timeout value. This is most likely because I have used a timeout factor of 0.7 to minimise "flickering" behaviour before finally changing to a timeout factor of 1. One consequence of this is that a few test cases will have double the original timeout (those test that would not pass a reduction to 0.7). So in all the instances when the timeout factor is exactly two times the size, the reason is that I have realised that I have already adjusted the timeout and I do not want to quad it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297765975 From lkorinth at openjdk.org Mon Aug 25 10:52:09 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 25 Aug 2025 10:52:09 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:44:28 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40: > >> 38: * @requires vm.cds >> 39: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 40: * @run driver/timeout=8000 LotsOfSyntheticClasses > > I was expecting `500 * 4 = 2000`, instead of `8000` here. This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)). > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60: > >> 58: * @comment skip running this test on 32 bit VM >> 59: * @requires vm.bits == "64" >> 60: * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest > > Why not `480`? This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)). > test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34: > >> 32: * @build com.foobar.Utils >> 33: * com.bar.* >> 34: * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest > > Why not `480`? This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)). > test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49: > >> 47: * @library /test/lib /test/jdk >> 48: * @modules jdk.jfr/jdk.jfr.internal.test >> 49: * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription > > Why not `480`? This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297768577 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773391 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773648 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297774209 From duke at openjdk.org Mon Aug 25 10:53:54 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 10:53:54 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3] In-Reply-To: References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: On Mon, 25 Aug 2025 09:02:49 GMT, Francesco Andreuzzi wrote: >> We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. >> >> This change fixes a build failure I'm getting with clang20: >> >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> 2 errors generated. >> >> >> Testing: >> - [x] tier1 fast-debug >> - [x] tier2 fast-debug > > Francesco Andreuzzi 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 resolved-default-cctor > - Merge branch 'master' into resolved-default-cctor > - use copy ctor Just realized this is a dup of JDK-8357579, for which there's an apparently inactive PR #26098. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3219762984 From lkorinth at openjdk.org Mon Aug 25 11:04:00 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 25 Aug 2025 11:04:00 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 16:06:16 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/langtools/jdk/jshell/HangingRemoteAgent.java line 38: > >> 36: class HangingRemoteAgent extends RemoteExecutionControl { >> 37: >> 38: private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0"))); > > why not `Utils.TIMEOUT_FACTOR`? There are a few places where I have changed java files that are not jtreg tests themself. The code is used by a jtreg test, but is not the "entry" into a test. Those files have no way to specify `@library` annotations, as no "test annotations" are parsed. It is a pity that a jtreg "library" can not specify dependencies to other "libraries". > test/langtools/jdk/jshell/UITesting.java line 148: > >> 146: } >> 147: >> 148: private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0"))); > > Why not `Utils.TIMEOUT_FACTOR`? [see above](https://github.com/openjdk/jdk/pull/26749#discussion_r2297800775) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297800775 PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297802941 From duke at openjdk.org Mon Aug 25 11:09:19 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 11:09:19 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v13] In-Reply-To: References: Message-ID: <5MrOub-7_OZbDXlFQrVWLgKQwy-WPB6JzVAt6GW6T1o=.a6eabba6-d2a4-4d1c-b934-a6aaa164f1e0@github.com> > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: - revert - Merge branch 'master' into refresh-precompiled-hotspot - comment - nn - conditional - time-trace - conditional includes - variants - magic number: 400 - inline - ... and 15 more: https://git.openjdk.org/jdk/compare/0cc78548...aea7c793 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/df0a71d2..aea7c793 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=11-12 Stats: 26610 lines in 912 files changed: 14430 ins; 8579 del; 3601 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From lkorinth at openjdk.org Mon Aug 25 11:19:53 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 25 Aug 2025 11:19:53 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text I am awaiting Oracle internal feedback if you wonder why I have still not updated copyright and integrated. Target date for integration is second of September. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3219867507 From shade at openjdk.org Mon Aug 25 11:22:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Aug 2025 11:22:54 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 22:54:07 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Comment for aggressive. Indent. src/java.base/share/man/java.md line 2899: > 2897: > 2898: `satb` > 2899: : Snapshot-at-the-beginning concurrent GC (three pass mark-evac-update). This is a long-standing problem with the name. It kinda implies `generational` is not `satb`. It actually is. Maybe we should rename `satb` to `single` or something. A lot of bikeshedding would ensue. src/java.base/share/man/java.md line 2903: > 2901: `passive` > 2902: : Stop the world GC only (either degenerated or full). This mode is > 2903: diagnostic, and must be enabled via `-XX:+UnlockDiagnosticVMOptions`. I don't think we add diagnostic options to the generic options list. These are not for end users, and we do not surface them unnecessarily. src/java.base/share/man/java.md line 2919: > 2917: > 2918: `static` > 2919: : Trigger GC when free heap falls below the ShenandoahMinFreeThreshold. Same here: `ShenandoahMinFreeThreshold` is experimental, it is not worth mentioning here. In fact, there are tunables for `adaptive` and `compact` as well, yet we do not (correctly!) mention them. src/java.base/share/man/java.md line 2923: > 2921: `aggressive` > 2922: : Run GC continuously, try to evacuate everything. This heuristics is > 2923: diagnostic, and must be enabled via -XX:+UnlockDiagnosticVMOptions. Same here: diagnostic option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2297835685 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2297834019 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2297837196 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2297835963 From bmaillard at openjdk.org Mon Aug 25 11:25:30 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 25 Aug 2025 11:25:30 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v4] In-Reply-To: References: Message-ID: <8u_ovVt2ENWkIIFenhekQLcz7Jm0co1E21I8Qcqf06Y=.0677ef54-8b15-4847-967a-1ab31dd8203f@github.com> > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Add #ifdef COMPILER2 for runtime methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/e855caec..83dcf6cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From stefank at openjdk.org Mon Aug 25 11:30:53 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 25 Aug 2025 11:30:53 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 09:42:45 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > dholmes tweaks Thanks for taking on this task! I read through it and added a few comments, but none of them are crucial to get addressed. I haven't followed and checked the links. doc/hotspot-style.md line 1481: > 1479: ## Excluded Features > 1480: > 1481: ### Structured Bindings FWIW, there was a recent discussions about memory APIs in `os::` that returned both a size and an error code. I'm a little bit intrigued to see if Structured Bindings would have been able to give us slightly more cleaner call-site code. I'll still my curiosity after the support for C++17 is in. doc/hotspot-style.md line 1509: > 1507: with files, and already has adequate mechanisms for its needs. Rewriting in > 1508: terms of this new library would not be a good use of resources. Having a mix > 1509: of the existing usage and uses of this new library would just be confusing. I'm not sure the style guide should be opinionated about we choose to use our resources. Could this be slightly tweaked to not say that? doc/hotspot-style.md line 1567: > 1565: in HotSpot code because of the > 1566: [no implicit boolean](#avoid-implicit-conversions-to-bool) > 1567: guideline.) > (Note that conversion to `bool` isn't needed ... Pre-existing: This section sounds weird to me. It more or less says "it isn't needed because we forbid it". I think people can still feel the need to use it. Maybe this could be changed to say something like: > (Note that conversion to `bool` isn't permitted in HotSpot code because of the [no implicit boolean](#avoid-implicit-conversions-to-bool) guideline.) or something like that. (This doesn't have to be fixed in this PR if you disagree) ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3150965151 PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2297826334 PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2297814769 PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2297837433 From stefank at openjdk.org Mon Aug 25 11:33:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 25 Aug 2025 11:33:52 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:07:00 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26923#pullrequestreview-3151033654 From bmaillard at openjdk.org Mon Aug 25 11:38:31 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 25 Aug 2025 11:38:31 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v5] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Replace one more \n by print_cr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/83dcf6cd..83573def Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From stefank at openjdk.org Mon Aug 25 11:41:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 25 Aug 2025 11:41:52 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Mon, 25 Aug 2025 09:32:37 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > unit test added Do we need to consider endianess here? ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3151055705 From lkorinth at openjdk.org Mon Aug 25 11:43:54 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 25 Aug 2025 11:43:54 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:55:38 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59: > >> 57: public class DGCDeadLock implements Runnable { >> 58: final static public int HOLD_TARGET_TIME = 25000; >> 59: public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4); > > Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000) * 4 * TestLibrary.getTimeoutFactor()`? It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297876217 From bmaillard at openjdk.org Mon Aug 25 12:47:54 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 25 Aug 2025 12:47:54 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: References: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> Message-ID: On Wed, 20 Aug 2025 22:37:40 GMT, Vladimir Kozlov wrote: > What assembler is look like? > > AOT code generation may have issue with this. We need to preserve C string passed to runtime call. This is for example what we obtain with `-XX:CompileCommand=printassembly` for the `Square` example @vnkozlov. As arguments to the runtime call we pass a pointer to the `const char* str` and the value(s)/pointer(s) for the node(s) we want to print. [Disassembly] -------------------------------------------------------------------------------- [Constant Pool (empty)] -------------------------------------------------------------------------------- [Verified Entry Point] # {method} {0x00007f4d6d07c230} 'square' '(I)I' in 'Square' # parm0: rsi = int # [sp+0x20] (sp of caller) ;; N1: # out( B1 ) <- in( B1 ) Freq: 1 ;; B1: # out( N1 ) <- BLOCK HEAD IS JUNK Freq: 1 0x00007f4da0562b80: movl %eax, -0x18000(%rsp) 0x00007f4da0562b87: pushq %rbp 0x00007f4da0562b88: subq $0x10, %rsp 0x00007f4da0562b8c: cmpl $0x0, 0x20(%r15) 0x00007f4da0562b94: jne 0x4e ;*synchronization entry ; - Square::square at -1 (line 3) 0x00007f4da0562b9a: movl %esi, %ebp 0x00007f4da0562b9c: imull %esi, %ebp ;*imul {reexecute=0 rethrow=0 return_oop=0} ; - Square::square at 2 (line 3) 0x00007f4da0562b9f: movabsq $0x7f4da53eaed2, %rdi 0x00007f4da0562ba9: movl %ebp, %esi 0x00007f4da0562bab: movabsq $0x7f4da4df30f0, %r10; {runtime_call void SharedRuntime::debug_print(char const*, int)} 0x00007f4da0562bb5: callq *%r10 0x00007f4da0562bb8: nopl (%rax,%rax) ; {post_call_nop} 0x00007f4da0562bc0: movl %ebp, %eax 0x00007f4da0562bc2: addq $0x10, %rsp 0x00007f4da0562bc6: popq %rbp 0x00007f4da0562bc7: cmpq 0x28(%r15), %rsp ; {poll_return} 0x00007f4da0562bcb: ja 0x1 0x00007f4da0562bd1: retq 0x00007f4da0562bd2: movabsq $0x7f4da0562bc7, %r10; {internal_word} 0x00007f4da0562bdc: movq %r10, 0x5a8(%r15) 0x00007f4da0562be3: jmp 0xb7078 ; {runtime_call SafepointBlob} 0x00007f4da0562be8: callq 0x9c793 ; {runtime_call Stub::Stub Generator method_entry_barrier_stub} 0x00007f4da0562bed: jmp -0x58 0x00007f4da0562bf2: hlt 0x00007f4da0562bf3: hlt 0x00007f4da0562bf4: hlt 0x00007f4da0562bf5: hlt 0x00007f4da0562bf6: hlt 0x00007f4da0562bf7: hlt [Exception Handler] 0x00007f4da0562bf8: jmp 0x4f663 ; {runtime_call ExceptionBlob} [Deopt Handler Code] 0x00007f4da0562bfd: callq 0x0 0x00007f4da0562c02: subq $0x5, (%rsp) 0x00007f4da0562c07: jmp 0xb7374 ; {runtime_call DeoptimizationBlob} 0x00007f4da0562c0c: hlt 0x00007f4da0562c0d: hlt 0x00007f4da0562c0e: hlt 0x00007f4da0562c0f: hlt -------------------------------------------------------------------------------- [/Disassembly] Is AOT code generation a concern even if this is only a debug feature, and that we have to modify the code to actually use it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3220117523 From duke at openjdk.org Mon Aug 25 13:04:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 13:04:14 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - nl - move down ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/aea7c793..2f97d57b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=12-13 Stats: 18 lines in 1 file changed: 9 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From shade at openjdk.org Mon Aug 25 13:04:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Aug 2025 13:04:19 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v13] In-Reply-To: <5MrOub-7_OZbDXlFQrVWLgKQwy-WPB6JzVAt6GW6T1o=.a6eabba6-d2a4-4d1c-b934-a6aaa164f1e0@github.com> References: <5MrOub-7_OZbDXlFQrVWLgKQwy-WPB6JzVAt6GW6T1o=.a6eabba6-d2a4-4d1c-b934-a6aaa164f1e0@github.com> Message-ID: On Mon, 25 Aug 2025 11:09:19 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: > > - revert > - Merge branch 'master' into refresh-precompiled-hotspot > - comment > - nn > - conditional > - time-trace > - conditional includes > - variants > - magic number: 400 > - inline > - ... and 15 more: https://git.openjdk.org/jdk/compare/d3649fee...aea7c793 Oh, `-ftime-trace` is cute. Current PR still gives me considerable improvements on M1, I'd ballpark 15% faster Hotspot build. CONF=macosx-aarch64-server-fastdebug make clean hotspot # Before 1237.16s user 230.31s system 635% cpu 3:50.81 total 1239.11s user 233.62s system 643% cpu 3:48.88 total 1239.93s user 231.30s system 643% cpu 3:48.50 total # After 1064.64s user 206.11s system 624% cpu 3:23.34 total 1067.86s user 208.56s system 621% cpu 3:25.39 total 1065.11s user 208.03s system 597% cpu 3:33.21 total src/hotspot/share/precompiled/precompiled.hpp line 33: > 31: > 32: #include "classfile/javaClasses.inline.hpp" > 33: #if INCLUDE_SHENANDOAHGC So the common style is to move conditional includes at the end of the include block. I think the same rule applies here. ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3151331144 PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2298028288 From duke at openjdk.org Mon Aug 25 13:04:19 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 13:04:19 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v13] In-Reply-To: References: <5MrOub-7_OZbDXlFQrVWLgKQwy-WPB6JzVAt6GW6T1o=.a6eabba6-d2a4-4d1c-b934-a6aaa164f1e0@github.com> Message-ID: On Mon, 25 Aug 2025 12:54:35 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: >> >> - revert >> - Merge branch 'master' into refresh-precompiled-hotspot >> - comment >> - nn >> - conditional >> - time-trace >> - conditional includes >> - variants >> - magic number: 400 >> - inline >> - ... and 15 more: https://git.openjdk.org/jdk/compare/d3649fee...aea7c793 > > src/hotspot/share/precompiled/precompiled.hpp line 33: > >> 31: >> 32: #include "classfile/javaClasses.inline.hpp" >> 33: #if INCLUDE_SHENANDOAHGC > > So the common style is to move conditional includes at the end of the include block. I think the same rule applies here. Right, ba6f372d87765417f1bf05cd2b1a7e058c18350d ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2298044735 From ayang at openjdk.org Mon Aug 25 13:50:55 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 25 Aug 2025 13:50:55 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:40:56 GMT, Leo Korinth wrote: > while not multiplying a 10x factor with four resulting in a 40x factor. Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2298163658 From tschatzl at openjdk.org Mon Aug 25 14:37:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Aug 2025 14:37:51 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() In-Reply-To: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Sat, 23 Aug 2025 23:02:33 GMT, Kim Barrett wrote: > Please review this change that removes the function oopDesc::mark_addr(). > It's kind of a suspicious function, since it is casting away the volatile for > a location that has concurrent reads and writes. But there isn't any code that > examines the value at the obtained address. Instead, it's just used as the > base address for a few prefetches. We change those places accordingly, and > remove the now unused mark_addr function. > > Testing: mach5 tier1 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3151770315 From kvn at openjdk.org Mon Aug 25 15:04:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 25 Aug 2025 15:04:51 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:07:00 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26923#pullrequestreview-3151898576 From ihse at openjdk.org Mon Aug 25 15:15:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 25 Aug 2025 15:15:53 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 09:42:45 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > dholmes tweaks The build change looks fine. I'd like to point out that this change will apply to all C++ code in the JDK, not only Hotspot. I don't think it is a problem; most other native libraries are almost trivial compared to Hotspot, and not many cares about intricacies like C++ version. This is not a vote on the hotspot guide change. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3151936814 From ihse at openjdk.org Mon Aug 25 15:30:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 25 Aug 2025 15:30:58 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:04:14 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - nl > - move down The new PCH file is surprisingly short. But we should trust the performance measurements, and this seems to be much better than the existing file. It might be an indication that gcc/clang have improved in performance for non-PCH headers. If you are up to it, it would be interesting to have a comparison run on your test platforms for running without PCH. You don't have to retest everything you ran, but just some representative selection perhaps? It's not relevant to this PR, but more to the general discussion of how relevant it is to keep PCH at all. Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. Can you arrange to test so we at least to not have any regressions there? And also check how the performance changes if you also manually include the same set of `inline` files as is currently in the PCH. But if that looks fine, then I guess this is ready for integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220737322 From ihse at openjdk.org Mon Aug 25 15:33:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 25 Aug 2025 15:33:58 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:04:14 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - nl > - move down Also, as a side note, I think we need to look more into `-ftime-trace`. We most likely have some code that is very heavy to compile that can be simplified for the compiler without sacrificing runtime performance. If would be interesting to compile all JDK native code with that flag... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220748181 From ihse at openjdk.org Mon Aug 25 15:43:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 25 Aug 2025 15:43:58 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: <1KoBJ00jLWZvWAPJ-yeQv32vFANCRpGPyDYr8cpvmV4=.5b8113e4-3f37-4541-ba00-9e206cf94246@github.com> On Mon, 25 Aug 2025 13:04:14 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - nl > - move down There seems to be two similar arguments to `-ftime-trace` for cl.exe: `/Bt+` and `/d2cgsummary`, according to my quick web search. It is not clear to me if they list include times. (But they might be useful in trying to figure out why files are slow to compile.) There is also https://github.com/microsoft/vcperf, which at a glance seems to give a lot of information. Not sure how hard it would be to integrate it into our build process, though... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220774191 PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220779644 From duke at openjdk.org Mon Aug 25 16:23:58 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 16:23:58 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 15:27:54 GMT, Magnus Ihse Bursie wrote: > The new PCH file is surprisingly short. But we should trust the performance measurements, and this seems to be much better than the existing file. It might be an indication that gcc/clang have improved in performance for non-PCH headers. If you are up to it, it would be interesting to have a comparison run on your test platforms for running without PCH. You don't have to retest everything you ran, but just some representative selection perhaps? It's not relevant to this PR, but more to the general discussion of how relevant it is to keep PCH at all. @magicus it seems that PCH still makes quite a difference, I re-ran `server` builds: | Branch | Compiler | Build flavor | Avg | Stddev | |---------|----------|-------|---------|--------| | master | gcc | server no-pch| 3375.60 | 2.04 | | master | clang | server no-pch| 2554.08 | 6.25 | | master | gcc | server | 2962.90 | 3.04 | | master | clang | server | 2247.31 | 4.27 | | 892ecb5a | gcc | server | 2570.87 | 0.96 | | 892ecb5a | clang | server | 1824.21 | 2.31 | The platform is the first in my [comment](https://github.com/openjdk/jdk/pull/26681#issuecomment-3219345092) above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220911147 From rehn at openjdk.org Mon Aug 25 16:54:35 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 25 Aug 2025 16:54:35 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v6] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:05:11 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26838#pullrequestreview-3152297057 From duke at openjdk.org Mon Aug 25 16:54:52 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 16:54:52 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 15:31:00 GMT, Magnus Ihse Bursie wrote: > Also, as a side note, I think we need to look more into -ftime-trace. We most likely have some code that is very heavy to compile that can be simplified for the compiler without sacrificing runtime performance. If would be interesting to compile all JDK native code with that flag... I created a ticket with some details to follow up: https://bugs.openjdk.org/browse/JDK-8366111 > Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. Can you arrange to test so we at least to not have any regressions there? And also check how the performance changes if you also manually include the same set of inline files as is currently in the PCH. Might take some time as I don't really work on Windows, I'll try to set up some EC2 with the tooling in the coming days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3220964631 From kvn at openjdk.org Mon Aug 25 17:24:36 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 25 Aug 2025 17:24:36 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:38:31 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Replace one more \n by print_cr Looks like minimal and Zero VM build is broken ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3221107430 From iklam at openjdk.org Mon Aug 25 17:43:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 25 Aug 2025 17:43:35 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3] In-Reply-To: References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: <-17ZRHBJyoVIQimB5SzKiRG-9wbn22heSq-41pBpqTw=.ec032526-09e5-4cdb-9683-291ea91f575d@github.com> On Mon, 25 Aug 2025 09:02:49 GMT, Francesco Andreuzzi wrote: >> We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. >> >> This change fixes a build failure I'm getting with clang20: >> >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> 2 errors generated. >> >> >> Testing: >> - [x] tier1 fast-debug >> - [x] tier2 fast-debug > > Francesco Andreuzzi 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 resolved-default-cctor > - Merge branch 'master' into resolved-default-cctor > - use copy ctor The problem with the default copy constructor is it might copy random values from the padding bytes: InstanceKlass* _field_holder; // Field holder klass int _field_offset; // Field offset in bytes u2 _field_index; // Index into field information in holder InstanceKlass u2 _cpool_index; // Constant pool index u1 _tos_state; // TOS state u1 _flags; // Flags: [0000|00|is_final|is_volatile] u1 _get_code, _put_code; // Get and Put bytecodes of the field // 1 padding byte on 32-bit // 5 padding bytes on 64-bit This will cause failures in test/hotspot/jtreg/runtime/cds/DeterministicDump.java on certain platforms. If you want to use the copy constructor, you need to add the padding bytes fields by hand and explicitly set them to zero in ResolvedFieldEntry::remove_unshareable_info(). I am not sure if structure padding is compiler-specific or not, so it might be difficult to write portable code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3221159221 From kvn at openjdk.org Mon Aug 25 17:43:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 25 Aug 2025 17:43:40 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v3] In-Reply-To: References: <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com> Message-ID: On Mon, 25 Aug 2025 12:43:21 GMT, Beno?t Maillard wrote: > Is AOT code generation a concern even if this is only a debug feature, and that we have to modify the code to actually use it? I did not realize that you have to modify C2 compiler code to use this feature. So we are safe in AOT for now. Eventually we may want to support it with AOT to see results with AOTed nmethods. Note, there is no Relocation info (external_word) attached to string's address load which is the issue with AOT I talked about: 0x00007f4da0562b9f: movabsq $0x7f4da53eaed2, %rdi It is because you use this: ``` Node* str_node = gvn->transform(new ConPNode(TypeRawPtr::make(((address) str)))); You don't need to solve it now but please keep it in mind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3221160667 From iklam at openjdk.org Mon Aug 25 17:47:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 25 Aug 2025 17:47:39 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26870#pullrequestreview-3152454131 From kbarrett at openjdk.org Mon Aug 25 17:57:40 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 17:57:40 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:06:10 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes tweaks > > doc/hotspot-style.md line 1509: > >> 1507: with files, and already has adequate mechanisms for its needs. Rewriting in >> 1508: terms of this new library would not be a good use of resources. Having a mix >> 1509: of the existing usage and uses of this new library would just be confusing. > > I'm not sure the style guide should be opinionated about we choose to use our resources. Could this be slightly tweaked to not say that? Rewriting as "would not be a good use of resources" => "doesn't provide any obviously significant benefits". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2298742971 From erikj at openjdk.org Mon Aug 25 17:58:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 25 Aug 2025 17:58:50 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 16:39:01 GMT, Francesco Andreuzzi wrote: > Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. I did run a quick comparison on Windows with an early version of this patch and it was basically a wash compared to before (slightly slower but could just be variance). I just reran with the latest patch and saw a slight improvement. Could still just be variance, but here are the numbers for running `make hotspot` immediately after `make clean-hotspot` to really isolate just the hotspot build. I warmed up caches by first building hotspot from scratch before cleaning. Baseline (@57434c73eac9bd6557b09d4a057e3a2a18f382b4): 4m38 This branch (@2f97d57b55fc838b30cf0d730c6119bf97749c6b): 4m30, 4m33 I only did one baseline run and then 2 on the branch. It's enough to show no regression. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3221205865 From alanb at openjdk.org Mon Aug 25 18:41:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 25 Aug 2025 18:41:35 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26870#pullrequestreview-3152611996 From ihse at openjdk.org Mon Aug 25 20:12:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 25 Aug 2025 20:12:39 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: <4vS0Q35mEwamnWp0PZhQG2CxI33NCrN4xQLTCommVCI=.e54b7e8a-7e26-4bca-82a9-6c44327b00cb@github.com> On Mon, 25 Aug 2025 13:04:14 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - nl > - move down No regression is acceptable, but I am still interested in seeing if adding back the `inline` files on Windows can give even better performance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3221592403 From duke at openjdk.org Mon Aug 25 20:25:26 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 20:25:26 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v15] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: add inlin files for windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/2f97d57b..4a2ff564 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=13-14 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Mon Aug 25 20:25:39 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 25 Aug 2025 20:25:39 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: <4vS0Q35mEwamnWp0PZhQG2CxI33NCrN4xQLTCommVCI=.e54b7e8a-7e26-4bca-82a9-6c44327b00cb@github.com> References: <4vS0Q35mEwamnWp0PZhQG2CxI33NCrN4xQLTCommVCI=.e54b7e8a-7e26-4bca-82a9-6c44327b00cb@github.com> Message-ID: <5YLToYZIr7sSzV3Epatnzkfj45zQl3ZbX86bCirTXvc=.bd5f40e6-7f24-456d-bf5f-96c839a3e124@github.com> On Mon, 25 Aug 2025 20:09:57 GMT, Magnus Ihse Bursie wrote: > No regression is acceptable, but I am still interested in seeing if adding back the `inline` files on Windows can give even better performance. I added them back in 4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f, there's only two of them since the others are now always included. @erikj79 any chance you could try once again and see if 4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f has any effect on build time? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3221628242 From dholmes at openjdk.org Mon Aug 25 20:26:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 20:26:40 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include runtime/synchronizer.hpp src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1004: > 1002: // is_rewritten() returns false. So we won't restore the original bytecodes. > 1003: // We hold a lock to guarantee we are not getting bytecodes > 1004: // at the same time the linking process are rewriting them. Suggestion: // We acquire the init_lock monitor to serialize with class linking so we are not getting // bytecodes at the same time the linking process is rewriting them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2299044927 From dholmes at openjdk.org Mon Aug 25 20:30:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Aug 2025 20:30:35 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:31:22 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include runtime/synchronizer.hpp I've heard from Coleen and she seems okay with this approach; and Patricio doesn't think it will have an impact on the virtual thread work - so that eases my concerns. I have some minor requested changes whilst we wait for a serviceability review. Thanks src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1006: > 1004: // at the same time the linking process are rewriting them. > 1005: Handle h_init_lock(Thread::current(), mh->method_holder()->init_lock()); > 1006: ObjectLocker ol(h_init_lock, JavaThread::current()); Suggestion: JavaThread* current = JavaThread::current(); Handle h_init_lock(current, mh->method_holder()->init_lock()); ObjectLocker ol(h_init_lock, current); ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3152910901 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2299048252 From kbarrett at openjdk.org Mon Aug 25 21:01:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 21:01:34 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:19:22 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes tweaks > > doc/hotspot-style.md line 1567: > >> 1565: in HotSpot code because of the >> 1566: [no implicit boolean](#avoid-implicit-conversions-to-bool) >> 1567: guideline.) > >> (Note that conversion to `bool` isn't needed ... > > Pre-existing: This section sounds weird to me. It more or less says "it isn't needed because we forbid it". I think people can still feel the need to use it. Maybe this could be changed to say something like: > >> (Note that conversion to `bool` isn't permitted > in HotSpot code because of the > [no implicit boolean](#avoid-implicit-conversions-to-bool) > guideline.) > > or something like that. (This doesn't have to be fixed in this PR if you disagree) This is about the conversion operators. I'm making that more explicit. "Conversion to `bool` operators aren't needed because ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2299125800 From dlong at openjdk.org Mon Aug 25 21:14:34 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 25 Aug 2025 21:14:34 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 20:28:08 GMT, Dean Long wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include runtime/synchronizer.hpp > > This seems like the correct fix. Forcing these APIs to link the class first would be a change in behavior and I assume it could cause linking-related exceptions to be thrown that the client might not expect. > @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`. I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3221758883 From kbarrett at openjdk.org Mon Aug 25 21:15:36 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 21:15:36 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v3] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:12:53 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes tweaks > > doc/hotspot-style.md line 1481: > >> 1479: ## Excluded Features >> 1480: >> 1481: ### Structured Bindings > > FWIW, there was a recent discussions about memory APIs in `os::` that returned both a size and an error code. I'm a little bit intrigued to see if Structured Bindings would have been able to give us slightly more cleaner call-site code. I'll still my curiosity after the support for C++17 is in. I've followed that discussion. Yes, Structured Bindings would provide some syntactic concision for that use-case. I think the last paragraph in the discussion of this feature applies. That is, the syntactic concision doesn't outweigh other factors (at least in the opinion of some). Also, I think there are better approaches for error reporting, and I'm feeling motivated to work on something in that direction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2299149389 From erikj at openjdk.org Mon Aug 25 21:27:37 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 25 Aug 2025 21:27:37 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 17:56:18 GMT, Erik Joelsson wrote: >>> Also, as a side note, I think we need to look more into -ftime-trace. We most likely have some code that is very heavy to compile that can be simplified for the compiler without sacrificing runtime performance. If would be interesting to compile all JDK native code with that flag... >> >> I created a ticket with some details to follow up: https://bugs.openjdk.org/browse/JDK-8366111 >> >>> Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. Can you arrange to test so we at least to not have any regressions there? And also check how the performance changes if you also manually include the same set of inline files as is currently in the PCH. >> >> Might take a while as I don't really work on Windows, I'll try to set up some EC2 with the tooling in the coming days. > >> Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. > > I did run a quick comparison on Windows with an early version of this patch and it was basically a wash compared to before (slightly slower but could just be variance). I just reran with the latest patch and saw a slight improvement. Could still just be variance, but here are the numbers for running `make hotspot` immediately after `make clean-hotspot` to really isolate just the hotspot build. I warmed up caches by first building hotspot from scratch before cleaning. > > Baseline (@57434c73eac9bd6557b09d4a057e3a2a18f382b4): 4m38 > This branch (@2f97d57b55fc838b30cf0d730c6119bf97749c6b): 4m30, 4m33 > > I only did one baseline run and then 2 on the branch. It's enough to show no regression. > I added them back in [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f), there's only two of them since the others are now always included. @erikj79 any chance you could try once again and see if [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f) has any effect on build time? I ran two more times: This branch (@4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f): 4m37, 4m29 So basically unchanged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3221794432 From duke at openjdk.org Mon Aug 25 23:05:40 2025 From: duke at openjdk.org (Rui Li) Date: Mon, 25 Aug 2025 23:05:40 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:18:24 GMT, Aleksey Shipilev wrote: >> Rui Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment for aggressive. Indent. > > src/java.base/share/man/java.md line 2899: > >> 2897: >> 2898: `satb` >> 2899: : Snapshot-at-the-beginning concurrent GC (three pass mark-evac-update). > > This is a long-standing problem with the name. It kinda implies `generational` is not `satb`. It actually is. Maybe we should rename `satb` to `single` or something. A lot of bikeshedding would ensue. Renaming the value of an existing jvm arg sounds intrusive, unless we can add an alias link from `satb` to `single`? Alternatively, we probably can add comment in generational to indicate it's also satb? > src/java.base/share/man/java.md line 2903: > >> 2901: `passive` >> 2902: : Stop the world GC only (either degenerated or full). This mode is >> 2903: diagnostic, and must be enabled via `-XX:+UnlockDiagnosticVMOptions`. > > I don't think we add diagnostic options to the generic options list. These are not for end users, and we do not surface them unnecessarily. Will remove > src/java.base/share/man/java.md line 2923: > >> 2921: `aggressive` >> 2922: : Run GC continuously, try to evacuate everything. This heuristics is >> 2923: diagnostic, and must be enabled via -XX:+UnlockDiagnosticVMOptions. > > Same here: diagnostic option. Will remove ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299318486 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299321044 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299321354 From duke at openjdk.org Mon Aug 25 23:24:34 2025 From: duke at openjdk.org (Rui Li) Date: Mon, 25 Aug 2025 23:24:34 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 11:19:14 GMT, Aleksey Shipilev wrote: >> Rui Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment for aggressive. Indent. > > src/java.base/share/man/java.md line 2919: > >> 2917: >> 2918: `static` >> 2919: : Trigger GC when free heap falls below the ShenandoahMinFreeThreshold. > > Same here: `ShenandoahMinFreeThreshold` is experimental, it is not worth mentioning here. In fact, there are tunables for `adaptive` and `compact` as well, yet we do not (correctly!) mention them. True, other options respond to `ShenandoahMinFreeThreshold` as well. It's kinda hard to describe `static` option without mentioning the threshold. - We could make the doc vague as in the [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L147): `trigger GC when free heap falls below the threshold`. - I now wonder why `static` is a non experimental flag - it has to be used with other experimental flags. Maybe just drop static from man page as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299344865 From kbarrett at openjdk.org Mon Aug 25 23:31:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Aug 2025 23:31:03 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: - missing word - stefank suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26884/files - new: https://git.openjdk.org/jdk/pull/26884/files/47343922..2da5d58d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=02-03 Stats: 13 lines in 2 files changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26884/head:pull/26884 PR: https://git.openjdk.org/jdk/pull/26884 From dholmes at openjdk.org Tue Aug 26 00:31:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 00:31:44 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code Message-ID: This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. Thanks ------------- Commit messages: - 8366121: Hotspot Style Guide should document conventions for lock-free code Changes: https://git.openjdk.org/jdk/pull/26934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366121 Stats: 21 lines in 2 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26934/head:pull/26934 PR: https://git.openjdk.org/jdk/pull/26934 From ysr at openjdk.org Tue Aug 26 01:01:35 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 26 Aug 2025 01:01:35 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v2] In-Reply-To: References: Message-ID: <87DPlYpwSIQq65Bk-b6M0Dh8VOY7t8oiDzl6p2PkAuA=.f1478f6a-3c3a-480c-99be-303b2bdf311b@github.com> On Mon, 25 Aug 2025 23:00:07 GMT, Rui Li wrote: >> src/java.base/share/man/java.md line 2899: >> >>> 2897: >>> 2898: `satb` >>> 2899: : Snapshot-at-the-beginning concurrent GC (three pass mark-evac-update). >> >> This is a long-standing problem with the name. It kinda implies `generational` is not `satb`. It actually is. Maybe we should rename `satb` to `single` or something. A lot of bikeshedding would ensue. > > Renaming the value of an existing jvm arg sounds intrusive, unless we can add an alias link from `satb` to `single`? Alternatively, we probably can add comment in generational to indicate it's also satb? I agree. For non-experimental options, we can follow the established deprecate & rename protocol. May be we could, in the inerim, add verbage in the description to avoid the confusion in the current naming as described by Aleksey. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299461882 From ysr at openjdk.org Tue Aug 26 01:08:42 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 26 Aug 2025 01:08:42 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v2] In-Reply-To: References: Message-ID: <-ERHcEPJ4K1bKIVS6yvfFu70AmAeJDxt9jj7VgUtnBg=.2ccfe082-e492-4d57-be11-c4b7dd341692@github.com> On Mon, 25 Aug 2025 23:22:16 GMT, Rui Li wrote: >> src/java.base/share/man/java.md line 2919: >> >>> 2917: >>> 2918: `static` >>> 2919: : Trigger GC when free heap falls below the ShenandoahMinFreeThreshold. >> >> Same here: `ShenandoahMinFreeThreshold` is experimental, it is not worth mentioning here. In fact, there are tunables for `adaptive` and `compact` as well, yet we do not (correctly!) mention them. > > True, other options respond to `ShenandoahMinFreeThreshold` as well. It's kinda hard to describe `static` option without mentioning the threshold. > - We could make the doc vague as in the [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L147): `trigger GC when free heap falls below the threshold`. > - I now wonder why `static` is a non experimental flag - it has to be used with other experimental flags. Maybe just drop static from man page as well? `below a specified threshold` might sound appropriately vague and render the flag unusable unless one consulted the code, underlining the experimental nature of it. If the collector respects `static` as specified, it can be considered a good guardrail to use in anger. In fact, I know of teams that do in production. (For that matter, there are a couple who use `compact` as well.) However, I am fine with eliding all experimental options, and in turn any non-experimental options that depend on experimental options (which however seems to be an anti-pattern to be avoided, if possible). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2299472120 From kbarrett at openjdk.org Tue Aug 26 03:51:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Aug 2025 03:51:34 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: > Please review this change that removes the function oopDesc::mark_addr(). > It's kind of a suspicious function, since it is casting away the volatile for > a location that has concurrent reads and writes. But there isn't any code that > examines the value at the obtained address. Instead, it's just used as the > base address for a few prefetches. We change those places accordingly, and > remove the now unused mark_addr function. > > Testing: mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: base_addr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26914/files - new: https://git.openjdk.org/jdk/pull/26914/files/fc5f763b..15b34fcf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26914&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26914&range=00-01 Stats: 10 lines in 4 files changed: 6 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26914/head:pull/26914 PR: https://git.openjdk.org/jdk/pull/26914 From kbarrett at openjdk.org Tue Aug 26 03:51:35 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Aug 2025 03:51:35 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Mon, 25 Aug 2025 10:46:21 GMT, Stefan Karlsson wrote: > I wonder though if it would make sense to have a function, say, `void* oopDesc::base_addr()` and use that instead of the added casts? I like that better, so changed accordingly. Will need re-review from everyone. @shipilev @stefank @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/26914#issuecomment-3222479609 From iklam at openjdk.org Tue Aug 26 04:28:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 26 Aug 2025 04:28:33 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3] In-Reply-To: <-17ZRHBJyoVIQimB5SzKiRG-9wbn22heSq-41pBpqTw=.ec032526-09e5-4cdb-9683-291ea91f575d@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> <-17ZRHBJyoVIQimB5SzKiRG-9wbn22heSq-41pBpqTw=.ec032526-09e5-4cdb-9683-291ea91f575d@github.com> Message-ID: On Mon, 25 Aug 2025 17:40:41 GMT, Ioi Lam wrote: > The problem with the default copy constructor is it might copy random values from the padding bytes: > > ``` > InstanceKlass* _field_holder; // Field holder klass > int _field_offset; // Field offset in bytes > u2 _field_index; // Index into field information in holder InstanceKlass > u2 _cpool_index; // Constant pool index > u1 _tos_state; // TOS state > u1 _flags; // Flags: [0000|00|is_final|is_volatile] > u1 _get_code, _put_code; // Get and Put bytecodes of the field > // 1 padding byte on 32-bit > // 5 padding bytes on 64-bit > ``` > > This will cause failures in test/hotspot/jtreg/runtime/cds/DeterministicDump.java on certain platforms. > > If you want to use the copy constructor, you need to add the padding bytes fields by hand and explicitly set them to zero in ResolvedFieldEntry::remove_unshareable_info(). > > I am not sure if structure padding is compiler-specific or not, so it might be difficult to write portable code. I am sorry, the problem is not with `ResolvedFieldEntry::remove_unshareable_info()`, but rather the `ResolvedFieldEntries` that are *not* cleaned by this function. https://github.com/openjdk/jdk/blob/0f7c0e956e278458e3d875bbda174e3b9e143135/src/hotspot/share/oops/cpCache.cpp#L433-L438 if (resolved && AOTConstantPoolResolver::is_resolution_deterministic(src_cp, cp_index)) { rfi->mark_and_relocate(); /// <--- HERE archived = true; } else { rfi->remove_unshareable_info(); } Note that `rfi` is allocated from within the metaspace, so originally it contains all zeros. However, sometimes we read a `ResolvedFieldEntry` from a GrowableArray and store it inside `*rfi`. If we use the default copy constructor, the copy inside the GrowableArray may have junk in its gaps, and the junk will leak into `*rfi`. If I remember correctly, this problems is most prominent on Windows. It's probably because Windows likes to use aligned copies to move stack variables into the GrowableArray, taking whatever junk from the stack. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3222570091 From dholmes at openjdk.org Tue Aug 26 04:53:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 04:53:39 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 21:11:34 GMT, Dean Long wrote: > > @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`. > > I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event. To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3222609397 From dholmes at openjdk.org Tue Aug 26 05:00:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 05:00:38 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3153908442 From dholmes at openjdk.org Tue Aug 26 05:27:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 05:27:50 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v34] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 12:30:40 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8357086: Fixed method name in assert in os_windows.cpp > > Co-authored-by: Stefan Karlsson One comment below but otherwise I think everything I have been concerned about has been addressed. Thanks for your patience. src/hotspot/share/utilities/globalDefinitions.hpp line 60: > 58: > 59: // Dummy placeholder for use of [[nodiscard]] > 60: #define ATTRIBUTE_NODISCARD I think you can just use `[[nodiscard]]` directly now. We are going to allow it and the guide is just going through the official update process. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3153982860 PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2299817113 From stefank at openjdk.org Tue Aug 26 06:05:38 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Aug 2025 06:05:38 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3154053497 From stefank at openjdk.org Tue Aug 26 06:05:39 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Aug 2025 06:05:39 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Tue, 26 Aug 2025 03:51:34 GMT, Kim Barrett wrote: >> Please review this change that removes the function oopDesc::mark_addr(). >> It's kind of a suspicious function, since it is casting away the volatile for >> a location that has concurrent reads and writes. But there isn't any code that >> examines the value at the obtained address. Instead, it's just used as the >> base address for a few prefetches. We change those places accordingly, and >> remove the now unused mark_addr function. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > base_addr Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3154054884 From stefank at openjdk.org Tue Aug 26 06:07:35 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Aug 2025 06:07:35 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: <30HAP6i7v-SnD04wlwi2N6S6g9FIRkga_5_-cXTEkbM=.d53e3201-e219-4f07-aafd-8c726a5f7b08@github.com> On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3154058304 From stuefe at openjdk.org Tue Aug 26 06:21:36 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Aug 2025 06:21:36 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v6] In-Reply-To: <-5FpG_VXK4-3PRdQMI735JSAgAlux9jJ74hbiYYbxjs=.8bf7192a-85b8-4e11-bfe8-a9cec6f388ea@github.com> References: <-5FpG_VXK4-3PRdQMI735JSAgAlux9jJ74hbiYYbxjs=.8bf7192a-85b8-4e11-bfe8-a9cec6f388ea@github.com> Message-ID: <3Bmjuf9sEH2UXFIlKDp916fsq9r-49JJoeBUM-OgbEY=.56fe6a58-1094-4705-ac3b-26e4e90a5485@github.com> On Fri, 22 Aug 2025 10:55:12 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> remove stray macro > > src/hotspot/share/oops/metadata.hpp line 50: > >> 48: >> 49: unsigned get_metadata_token() const { return _token; } >> 50: bool is_valid() const { return (get_metadata_token() & common_prefix) == common_prefix; } > > This looks like you meant to use `common_prefix_mask` when extracting the bits out of the token. Good catch. Thank you. Probably means I need to re-run all tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2299901349 From dholmes at openjdk.org Tue Aug 26 06:22:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 06:22:44 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v7] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Fri, 22 Aug 2025 20:29:10 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > One more nit Thanks for updates re TRAPS etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/26866#pullrequestreview-3154091489 From stuefe at openjdk.org Tue Aug 26 06:25:35 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Aug 2025 06:25:35 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v6] In-Reply-To: <-5FpG_VXK4-3PRdQMI735JSAgAlux9jJ74hbiYYbxjs=.8bf7192a-85b8-4e11-bfe8-a9cec6f388ea@github.com> References: <-5FpG_VXK4-3PRdQMI735JSAgAlux9jJ74hbiYYbxjs=.8bf7192a-85b8-4e11-bfe8-a9cec6f388ea@github.com> Message-ID: On Fri, 22 Aug 2025 10:53:30 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> remove stray macro > > src/hotspot/share/oops/metadata.hpp line 47: > >> 45: static constexpr uint32_t common_prefix_mask = 0xFFFF0000; >> 46: static constexpr uint32_t instance_klass_token = 0x3E7A0101; >> 47: static constexpr uint32_t array_klass_token = 0x3E7A0102; > > Why not > > ```c++ > enum class Token : uint32_t { /* cases */ }; What would be the advantage, apart from having to prefix all tokens with `Metadata::Token::` now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2299906109 From stuefe at openjdk.org Tue Aug 26 06:25:37 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Aug 2025 06:25:37 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v4] In-Reply-To: References: <278wV7Qn39_9L1bzj9mhiy6s67eulGQEIeXPs4ZFlNw=.13667fac-05e6-4554-997a-8cdda70ef150@github.com> Message-ID: On Mon, 25 Aug 2025 05:11:07 GMT, Axel Boldt-Christmas wrote: > You can use `'` as a digit separator. If that was the readability you were looking after. > > ```c++ > static constexpr uint32_t common_prefix = 0x3E7A'0000; > static constexpr uint32_t common_prefix_mask = 0xFFFF'0000; > static constexpr uint32_t instance_klass_token = 0x3E7A'0101; > static constexpr uint32_t array_klass_token = 0x3E7A'0102; > ``` I did not know that, thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25891#discussion_r2299908021 From stuefe at openjdk.org Tue Aug 26 06:31:24 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Aug 2025 06:31:24 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v7] In-Reply-To: References: Message-ID: > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Feedback Johan, Axel - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - remove stray macro - feedback Caspar - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - Feedback Johan - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - merge master - copyrights - fix big-endian problem on AIX - ... and 7 more: https://git.openjdk.org/jdk/compare/e5ec4641...72954f87 ------------- Changes: https://git.openjdk.org/jdk/pull/25891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=06 Stats: 483 lines in 26 files changed: 399 ins; 27 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From dholmes at openjdk.org Tue Aug 26 06:31:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 06:31:38 GMT Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga wrote: >> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: >> >> >> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss >> CPU Model and flags from /proc/cpuinfo: >> model name : Intel(R) Core(TM) Ultra 5 225U >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd >> >> >> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". >> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html >> >> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 >> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Indicate "(hybrid)" on hybrid CPU Sorry for the delay. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26808#pullrequestreview-3154112882 From dholmes at openjdk.org Tue Aug 26 06:37:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 06:37:38 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga wrote: > `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result: > > > CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid > > > It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor") > > According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core. > > After this change, we can see correct number of cores as following on 3300X: > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor Okay now I understand. Sorry for the delay. Don't forget a second review is needed. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26819#pullrequestreview-3154129994 PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3222813047 From dholmes at openjdk.org Tue Aug 26 07:04:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Aug 2025 07:04:38 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. Wow that was such a mess! It looks like the native methods were intended to be static - hence the initial unused argument. But how did this even work when the jvm.cpp implementations reversed the arguments ?? One was an instance of `ConstantPool` and the other the VM set `constantPoolOop`. !! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3222886432 From ysuenaga at openjdk.org Tue Aug 26 07:07:45 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 26 Aug 2025 07:07:45 GMT Subject: Integrated: 8365633: Incorrect info is reported on hybrid CPU In-Reply-To: References: Message-ID: On Sat, 16 Aug 2025 14:11:27 GMT, Yasumasa Suenaga wrote: > `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result: > > > CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss > CPU Model and flags from /proc/cpuinfo: > model name : Intel(R) Core(TM) Ultra 5 225U > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd > > > It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads". > https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html > > According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597 > In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point. This pull request has now been integrated. Changeset: 5013d69d Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/5013d69d96e5052972bc04c78a060fd9296518e2 Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod 8365633: Incorrect info is reported on hybrid CPU Reviewed-by: kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26808 From tschatzl at openjdk.org Tue Aug 26 07:25:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Aug 2025 07:25:34 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Tue, 26 Aug 2025 03:51:34 GMT, Kim Barrett wrote: >> Please review this change that removes the function oopDesc::mark_addr(). >> It's kind of a suspicious function, since it is casting away the volatile for >> a location that has concurrent reads and writes. But there isn't any code that >> examines the value at the obtained address. Instead, it's just used as the >> base address for a few prefetches. We change those places accordingly, and >> remove the now unused mark_addr function. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > base_addr Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3154292570 From ayang at openjdk.org Tue Aug 26 07:56:36 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 07:56:36 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3154419849 From duke at openjdk.org Tue Aug 26 07:59:33 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 07:59:33 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v16] In-Reply-To: References: Message-ID: <3v0ViYAqvt3TgJoFHeIeowWKnsdCCcE8XLL_aYsY_EQ=.7697d981-540c-4b89-af4f-5180d10cb0bb@github.com> > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: remove ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/4a2ff564..32e7d31c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=14-15 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Tue Aug 26 07:59:34 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 07:59:34 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: <6TEXvTW4l4eoQE-k6ofhRzQ5zcqggk18xu7wvg6MYXg=.1e2a32eb-dce3-446c-95a3-348c24a58168@github.com> On Mon, 25 Aug 2025 21:24:50 GMT, Erik Joelsson wrote: > > I added them back in [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f), there's only two of them since the others are now always included. @erikj79 any chance you could try once again and see if [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f) has any effect on build time? > > I ran two more times: > > This branch (@4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f): 4m37, 4m29 > > So basically unchanged. Thanks @erikj79 ! @magicus I'll remove the special section for MSVC since it does not seem to be justified with the current set of headers, let me know if I should put it back. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3223043796 From duke at openjdk.org Tue Aug 26 08:01:59 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 26 Aug 2025 08:01:59 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v35] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > `ATTRIBUTE_NODISCARD` macro is added as a placeholder for `[[nodiscard]]`, which will be available with C++17. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Fixed method name in assert in os_windows.cpp Co-authored-by: Stefan Karlsson - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewers' comments - Merge remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs - 8357086: Addressed reviewer's comments - 8357086: Addressed reviewer's comments - 8357086: Fixed whitespace error - 8357086: Addressed reviewer's comments - ... and 27 more: https://git.openjdk.org/jdk/compare/5cc86738...678da7f6 ------------- Changes: https://git.openjdk.org/jdk/pull/25450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=34 Stats: 259 lines in 23 files changed: 97 ins; 2 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From stuefe at openjdk.org Tue Aug 26 08:02:37 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Aug 2025 08:02:37 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: <_a7bvHYlUDn0S6REAHUWOlEOq4lAiPGQLzHKrzyeogI=.91af02e1-4bfb-41d9-a646-a8d6da2fc6f2@github.com> On Wed, 20 Aug 2025 19:57:56 GMT, Robert Toyonaga wrote: >>> > You mean adding the vsize, swap etc fields to ResidentSetSize? >>> > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) >>> >>> I was thinking something like this: >>> >>> ``` >>> >>> >>> >>> >>> >>> >>> >>> ``` >> >> Hmm, yes, that would be one alternative. >> >>> >>> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. >>> >>> > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. >>> >>> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal. >>> >>> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. >> >> I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation. >> >> Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way. >> >> In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss. >> >> I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the m... > > @tstuefe > I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not changing `jdk.ResidentSetSize`) makes sense. This allows JMC to continue as normal, and it also keeps the relevant metrics together so they can be easily interpreted in relation to each other. >>These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future. > > @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go the above route (leaving all the metrics in `ProcessSize`), maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation to allow JMC time to eventually switch over to using the new event for its charts? > >> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? > > I think this new swap data is process-specific so is not already covered by `jdk.SwapSpace`, which shows the max amount available and how much is currently free to the OS. > I think it could be reasonable to leave the process' swap data in `ProcessSize` rather than the `jdk.SwapSpace` which contains data for the whole OS. The connecting thread is that this info is a "process" metric being grouped with other memory metrics for this specific process. > > Another option, in order to avoid duplication, could be to leave the RSS metrics in the `jdk.ResidentSetSize` event, not put them in the `ProcessSize` event, and correlate them by giving them the same timestamp (as Erik mentions above). > Something similar was also done with the `NativeMemoryUsagePeak` and `NativeMemoryUsageTotalPeak` events (which are GraalVM specific) to avoid having to modify `NativeMemoryUsage` and `NativeMemoryUsageTotal`. Admittedly, this is probably not as clean or convenient. > > Either way, I agree that putting all the metrics in `ProcessSize` in their own individual events is not the best way. Thank you, @roberttoyonaga ! Let's see what @egahlin writes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3223056141 From shade at openjdk.org Tue Aug 26 08:14:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Aug 2025 08:14:41 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Tue, 26 Aug 2025 03:51:34 GMT, Kim Barrett wrote: >> Please review this change that removes the function oopDesc::mark_addr(). >> It's kind of a suspicious function, since it is casting away the volatile for >> a location that has concurrent reads and writes. But there isn't any code that >> examines the value at the obtained address. Instead, it's just used as the >> base address for a few prefetches. We change those places accordingly, and >> remove the now unused mark_addr function. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > base_addr This looks fine. TIL that you can overload methods with cv-qualifiers. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26914#pullrequestreview-3154488134 From ayang at openjdk.org Tue Aug 26 08:20:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 08:20:37 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3154507961 From jsjolen at openjdk.org Tue Aug 26 08:32:37 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 26 Aug 2025 08:32:37 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3154548461 From duke at openjdk.org Tue Aug 26 08:41:03 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 26 Aug 2025 08:41:03 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > Tested in GHA and Tiers 1-5. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8357086: Removed extra empty line. - 8357086: Removed placeholder for nodiscard attribute. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25450/files - new: https://git.openjdk.org/jdk/pull/25450/files/678da7f6..6ac68400 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=34-35 Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450 PR: https://git.openjdk.org/jdk/pull/25450 From duke at openjdk.org Tue Aug 26 08:41:03 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 26 Aug 2025 08:41:03 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v34] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 05:24:16 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357086: Fixed method name in assert in os_windows.cpp >> >> Co-authored-by: Stefan Karlsson > > src/hotspot/share/utilities/globalDefinitions.hpp line 60: > >> 58: >> 59: // Dummy placeholder for use of [[nodiscard]] >> 60: #define ATTRIBUTE_NODISCARD > > I think you can just use `[[nodiscard]]` directly now. We are going to allow it and the guide is just going through the official update process. Removed as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2300240779 From stefank at openjdk.org Tue Aug 26 08:55:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Aug 2025 08:55:47 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:41:03 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8357086: Removed extra empty line. > - 8357086: Removed placeholder for nodiscard attribute. Looks good (if this still compiles with the `[[nodiscard]]` changes). ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3154630131 From duke at openjdk.org Tue Aug 26 09:00:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 26 Aug 2025 09:00:47 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: <_E9bsiCHDT-vT2jhY86eXAU0uZr85l_u25h0RiEOWYY=.729e2dab-e055-43e2-a8d2-18c6cad51023@github.com> On Tue, 26 Aug 2025 08:52:38 GMT, Stefan Karlsson wrote: > Looks good (if this still compiles with the `[[nodiscard]]` changes). I tried locally on linux-x64, GHA will have answers for other platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3223255288 From fbredberg at openjdk.org Tue Aug 26 09:41:38 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 26 Aug 2025 09:41:38 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> References: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> Message-ID: On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback A good looking PR, and a good step in the right direction. Nice! But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493). ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/26849#pullrequestreview-3154824577 From mli at openjdk.org Tue Aug 26 09:57:43 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Aug 2025 09:57:43 GMT Subject: RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 [v6] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:05:11 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. >> As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. >> As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. >> >> There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Thank you for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26838#issuecomment-3223466184 From mli at openjdk.org Tue Aug 26 09:57:45 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Aug 2025 09:57:45 GMT Subject: Integrated: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 08:22:59 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Currently implementation of conversion from float to float16 only preserve some significant bits of a NaN, which is not right in some cases. > As this (NaN conversion from float to float16) is already in the slow path, so I'll just fix it by preserving all significant bits in the same way as j.l.Float.floatToFloat16. > As current tests does not catch the issue, except of TestFloat16ScalarOperations.java, so add another test. > > There is also the similar issue in vector version of conversion from float to float16, I'll address it in another pr [JDK-8365772](https://bugs.openjdk.org/browse/JDK-8365772) > > Thanks! This pull request has now been integrated. Changeset: 28602f3d Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/28602f3d3ec15b5241a33a46ce43349e6300395d Stats: 264 lines in 6 files changed: 237 ins; 21 del; 6 mod 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 Reviewed-by: fyang, rehn, dzhang ------------- PR: https://git.openjdk.org/jdk/pull/26838 From adinn at openjdk.org Tue Aug 26 11:11:35 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Aug 2025 11:11:35 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:07:00 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Marked as reviewed by adinn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26923#pullrequestreview-3155123240 From bmaillard at openjdk.org Tue Aug 26 11:22:06 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 26 Aug 2025 11:22:06 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v6] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Fix missing candidates.size() == 0 case when constants are involved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/83573def..2769e251 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=04-05 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From stefank at openjdk.org Tue Aug 26 11:40:34 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Aug 2025 11:40:34 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Mon, 25 Aug 2025 11:39:11 GMT, Stefan Karlsson wrote: > Do we need to consider endianess here? I guess the answer is no because the changed code and tests only operators on the full sized variables and doesn't try to extract and operate on parts of the full sized variables. Did you see that the new test failed on Windows? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26809#issuecomment-3223808111 From bmaillard at openjdk.org Tue Aug 26 11:44:57 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 26 Aug 2025 11:44:57 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v7] In-Reply-To: References: Message-ID: <4q3nYAQn2of4YCpvNRJsUTLQRWYaSYhtpfBZTl-CM4c=.20d2b699-fc73-4f99-9e41-6724fe94e08f@github.com> > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Avoid having root as control candidate to prevent issue when printing a constant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/2769e251..047ababf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From ayang at openjdk.org Tue Aug 26 11:50:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 11:50:28 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold Message-ID: Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. This simplifies the allocation logic: 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation Test: tier1-3 ------------- Commit messages: - sgc-should-allocate Changes: https://git.openjdk.org/jdk/pull/26941/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366155 Stats: 86 lines in 7 files changed: 3 ins; 75 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26941/head:pull/26941 PR: https://git.openjdk.org/jdk/pull/26941 From jwaters at openjdk.org Tue Aug 26 12:29:36 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 26 Aug 2025 12:29:36 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3155405998 From azafari at openjdk.org Tue Aug 26 12:34:38 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 26 Aug 2025 12:34:38 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v3] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Tue, 26 Aug 2025 11:38:03 GMT, Stefan Karlsson wrote: > > Do we need to consider endianess here? > > I guess the answer is no because the changed code and tests only operators on the full sized variables and doesn't try to extract and operate on parts of the full sized variables. > > Did you see that the new test failed on Windows? That is right, no need to consider endianness. Windows failure is due to 'long' casting instead of 'long long'. Fixed it and is under tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26809#issuecomment-3223985684 From azafari at openjdk.org Tue Aug 26 12:44:33 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 26 Aug 2025 12:44:33 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v4] In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: explicit casting of 'long long' vs 'long' for windows compatibility. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26809/files - new: https://git.openjdk.org/jdk/pull/26809/files/b525ba07..6b02c0e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From duke at openjdk.org Tue Aug 26 12:54:34 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 12:54:34 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 src/hotspot/share/gc/serial/serialHeap.cpp line 286: > 284: > 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { > 286: HeapWord* result = _young_gen->allocate(size); The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2300894601 From liach at openjdk.org Tue Aug 26 13:04:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 26 Aug 2025 13:04:38 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. I think the old code consistently dropped the oop and used the instance despite what the jvm.h names indicate - if you call reflect_ConstantPool's function on the constantPoolOop (i.e. java.lang.Class for an IK) you get a crash. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3224087039 From egahlin at openjdk.org Tue Aug 26 13:05:42 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 26 Aug 2025 13:05:42 GMT Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics to JFR In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe wrote: > This provides the following new metrics: > - `ProcessSize` event (new, periodic) > - vsize (for analyzing address-space fragmentation issues) > - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat) > - peak RSS > - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing) > - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size) > - `LibcStatistics` (new, periodic) > - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading) > - retained malloc size (super-important for the same reason) > - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`) > - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims) > - RSS before and RSS after > - RSS recovered by this trim > - whether it was an automatic or manual trim > - duration > - `JavaThreadStatistic` > - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.) > - nonJava thread counter (new field) (needed to interprete the os thread counter) > > Notes: > - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it. > > - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue. > > I provided implementations, as far as possible, to Linux, MacOS and Windows. > > Testing: > - ran the new tests manually and as part of GHAs Events can be viewed as tables in a relational database. Duplicating information or designing tables based on the user interface is not a good idea. Correlating or grouping data from different events is not a new problem. The way we have solved it in the past is by using an explicit ID, similar to a foreign key (gcId, compilerId, safepointId etc), or by using the same timestamp (ActiveSetting, NativeMemory* etc.). In this case, I think a timestamp makes more sense. Tools can place the value on a timeline and have memory on the y-axis. An alternative design is to do something similar to the NativeMemoryUsage event. That is, to split the data per type and then emit what is supported on a specific platform and have all those event with the same timestamp. I'm not sure which of the following memory types make sense to include, there is also a maintenance aspect, or if it the list is correct or complete, but the data would be normalized, even if it differs depending on the platform. Memory Type Linux macOS Windows Description -------------------------- ------ -------- --------- ----------------------------------------------------------' Resident Set Size Yes Yes - Resident memory currently in physical RAM Private Bytes - - Yes Privately allocated memory Shared Memory Yes Yes Yes Memory shared among processes Virtual Memory Size Yes Yes Yes Total reserved address space Commit Charge - - Yes Promised/guaranteed memory for process Mapped File Memory Yes Yes Yes Memory mapped from files Page Table Size Yes - - Memory used for page tables Swap / Swapped Yes Yes Yes Memory swapped out to disk Wired Memory - Yes - Locked memory that can't be paged out Compressed Memory - Yes - Memory compressed by the system Paged Pool - - Yes Pool for pageable kernel allocations Non-paged Pool - - Yes Pool for non-pageable kernel allocations Working Set - - Yes Memory pages currently in RAM for the process Stack Yes Yes Yes Memory used by call stacks Heap / Malloc Yes Yes Yes Dynamically allocated memory (heap) Image Yes Yes - Memory used for executables and loaded libraries ------------- PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3224085095 From adinn at openjdk.org Tue Aug 26 13:29:35 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Aug 2025 13:29:35 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false In-Reply-To: References: Message-ID: <-3MopRJ8ncWyveWxD5HSZpsL84dl2aiQc53ww9Q8IxA=.7233def8-7bc6-41d0-8529-bce01af9d131@github.com> On Sun, 24 Aug 2025 16:23:19 GMT, Patrick Zhang wrote: > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. > > This PR, > 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. > 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. > 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side > 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. > 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > > These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. > > Tests include, > 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. > 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences got almost same as baseline, ... @cnqpzhang If you look back at the history of this code you will see that you are undoing a change that was made deliberately by @theRealAph. Your patch may improve the specific test case you have provided but at the cost of a significant and unacceptable increase in code cache use for all cases. The comment at the head of the code you have edited makes this point explicitly. The reasoning behind that comment is available in the JIRA history and associated review comments. The relevant issue is https://bugs.openjdk.org/browse/JDK-8179444 and the corresponding review thread starts with https://mail.openjdk.org/pipermail/hotspot-dev/2017-April/026742.html and continues with https://mail.openjdk.org/pipermail/hotspot-dev/2017-May/026766.html I don't recommend integrating this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3224177760 From kbarrett at openjdk.org Tue Aug 26 13:34:38 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Aug 2025 13:34:38 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v4] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: <2oNNP-bT-cqWIh-Il3c2V7tmQ4Sg8HDZ3ezKSDPuV_4=.8aead19f-5e08-42d1-a7a4-c72939c9f434@github.com> On Tue, 26 Aug 2025 12:44:33 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > explicit casting of 'long long' vs 'long' for windows compatibility. Changes requested by kbarrett (Reviewer). test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 307: > 305: > 306: val = jlong_from(0xFFFFFFFF, 0); > 307: EXPECT_EQ( val, (signed long long)0xFFFFFFFF00000000); Oops! Sorry I missed that these tests were previously casting to `long` variants. Never use `long` in shared code. But we also almost never use `long long` in shared code. (And a couple of the uses look a bit questionable. I'll be following up on those.) Use CONST64 and UCONST64 to form the 64 bit constants, rather than casts. test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 308: > 306: val = jlong_from(0xFFFFFFFF, 0); > 307: EXPECT_EQ( val, (signed long long)0xFFFFFFFF00000000); > 308: EXPECT_EQ((unsigned long long)val, 0xFFFFFFFF00000000); I think this should be EXPECT_EQ((julong)val, UCONST64(0xFFFFFFFF00000000)); ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3155654041 PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2301010601 PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2301011815 From ayang at openjdk.org Tue Aug 26 13:37:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 26 Aug 2025 13:37:34 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 12:51:21 GMT, Francesco Andreuzzi wrote: >> Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. >> >> This simplifies the allocation logic: >> 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation >> 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation >> >> Test: tier1-3 > > src/hotspot/share/gc/serial/serialHeap.cpp line 286: > >> 284: >> 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { >> 286: HeapWord* result = _young_gen->allocate(size); > > The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? On master, before the method is invoked, young-gen allocation is already attempted inside `attempt_allocation(size, is_tlab, false /*first_only*/);`. With this cleanup, it become clearer that we try young-gen first, then old-gen. So, yes, this is intended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2301014403 From duke at openjdk.org Tue Aug 26 13:37:35 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 13:37:35 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:32:34 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/serial/serialHeap.cpp line 286: >> >>> 284: >>> 285: HeapWord* SerialHeap::expand_heap_and_allocate(size_t size, bool is_tlab) { >>> 286: HeapWord* result = _young_gen->allocate(size); >> >> The order of `_young_gen->allocate` and `old_gen->expand_and_allocate` is reversed now. It used to be `_old_gen->expand_and_allocate == nullptr --> _young_gen->allocate`, now it's the other way around. Is that intended? > > On master, before the method is invoked, young-gen allocation is already attempted inside `attempt_allocation(size, is_tlab, false /*first_only*/);`. > > With this cleanup, it become clearer that we try young-gen first, then old-gen. So, yes, this is intended. Thanks for clarifying ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26941#discussion_r2301022598 From eastigeevich at openjdk.org Tue Aug 26 13:39:14 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 26 Aug 2025 13:39:14 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - Tier1 - tier3 passed. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Symplify comments; Get JavaThread::current in variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26863/files - new: https://git.openjdk.org/jdk/pull/26863/files/d6895181..293d81ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From eastigeevich at openjdk.org Tue Aug 26 13:39:14 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 26 Aug 2025 13:39:14 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 04:50:37 GMT, David Holmes wrote: >>> @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`. >> >> I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event. > >> > @dean-long `retransformClasses` is specified to to be able to throw `LinkageErrors`. >> >> I see that in java.lang.instrument, but the JVMTI spec says "In response to this call, no events other than the ClassFileLoadHook event will be sent." Normally during linking we send the ClassPrepare event. > > To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). @dholmes-ora Thank you for review and the suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3224210817 From eastigeevich at openjdk.org Tue Aug 26 13:39:14 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 26 Aug 2025 13:39:14 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 20:23:52 GMT, David Holmes wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include runtime/synchronizer.hpp > > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1004: > >> 1002: // is_rewritten() returns false. So we won't restore the original bytecodes. >> 1003: // We hold a lock to guarantee we are not getting bytecodes >> 1004: // at the same time the linking process are rewriting them. > > Suggestion: > > // We acquire the init_lock monitor to serialize with class linking so we are not getting > // bytecodes at the same time the linking process is rewriting them. Done > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1006: > >> 1004: // at the same time the linking process are rewriting them. >> 1005: Handle h_init_lock(Thread::current(), mh->method_holder()->init_lock()); >> 1006: ObjectLocker ol(h_init_lock, JavaThread::current()); > > Suggestion: > > JavaThread* current = JavaThread::current(); > Handle h_init_lock(current, mh->method_holder()->init_lock()); > ObjectLocker ol(h_init_lock, current); Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2301024352 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2301023827 From azafari at openjdk.org Tue Aug 26 13:51:53 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 26 Aug 2025 13:51:53 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v5] In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: CONST64 vs explicit casting. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26809/files - new: https://git.openjdk.org/jdk/pull/26809/files/6b02c0e9..e6ee02ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From ihse at openjdk.org Tue Aug 26 14:08:42 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Aug 2025 14:08:42 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: References: Message-ID: <29A0krlgdP5oNFMQSSF3pqJcMfnTguAmOAlXzL4ULog=.6366d93b-ca94-4413-a2d2-27963ab6b608@github.com> On Mon, 25 Aug 2025 21:24:50 GMT, Erik Joelsson wrote: >>> Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. >> >> I did run a quick comparison on Windows with an early version of this patch and it was basically a wash compared to before (slightly slower but could just be variance). I just reran with the latest patch and saw a slight improvement. Could still just be variance, but here are the numbers for running `make hotspot` immediately after `make clean-hotspot` to really isolate just the hotspot build. I warmed up caches by first building hotspot from scratch before cleaning. >> >> Baseline (@57434c73eac9bd6557b09d4a057e3a2a18f382b4): 4m38 >> This branch (@2f97d57b55fc838b30cf0d730c6119bf97749c6b): 4m30, 4m33 >> >> I only did one baseline run and then 2 on the branch. It's enough to show no regression. > >> I added them back in [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f), there's only two of them since the others are now always included. @erikj79 any chance you could try once again and see if [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f) has any effect on build time? > > I ran two more times: > > This branch (@4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f): 4m37, 4m29 > > So basically unchanged. Thanks @erikj79 for testing! And thanks @fandreuz for preparing the code for testing. I agree, there is no reason to keep the `inline` files if they do not improve performance. I think this is finally ready to be checked in. Thank you so much for your hard work and dedication. I have just one last request: How did you generate the last version? The script that you used to read the `.d` files has disappeared somewhere along the way, with no replacement. If you could do this with just some simple command line with pipes etc, that command line should be added as a comment to the PCH file. If you used a script, I think that script should be checked in (in `make/scripts`; even if it is a Java file). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3224320806 From bmaillard at openjdk.org Tue Aug 26 14:41:21 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 26 Aug 2025 14:41:21 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v8] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Fix mismatch with #ifdef COMPILER2 between .hpp and .cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/047ababf..233c89a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=06-07 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From cstein at openjdk.org Tue Aug 26 14:44:29 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 26 Aug 2025 14:44:29 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v3] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8 - Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/b5112c32..56006240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=01-02 Stats: 79727 lines in 2045 files changed: 46139 ins; 24474 del; 9114 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From cstein at openjdk.org Tue Aug 26 15:16:39 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 26 Aug 2025 15:16:39 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 14:44:29 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java line 2: > 1: /* > 2: * Copyright (c) 2022, 2025, Red Hat, Inc. Restore original line and insert an additional one. Suggestion: * Copyright (c) 2022, Red Hat, Inc. * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2301330477 From duke at openjdk.org Tue Aug 26 15:54:39 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 15:54:39 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14] In-Reply-To: <29A0krlgdP5oNFMQSSF3pqJcMfnTguAmOAlXzL4ULog=.6366d93b-ca94-4413-a2d2-27963ab6b608@github.com> References: <29A0krlgdP5oNFMQSSF3pqJcMfnTguAmOAlXzL4ULog=.6366d93b-ca94-4413-a2d2-27963ab6b608@github.com> Message-ID: On Tue, 26 Aug 2025 14:05:33 GMT, Magnus Ihse Bursie wrote: > I have just one last request: How did you generate the last version? The script that you used to read the `.d` files has disappeared somewhere along the way, with no replacement. If you could do this with just some simple command line with pipes etc, that command line should be added as a comment to the PCH file. If you used a script, I think that script should be checked in (in `make/scripts`; even if it is a Java file). Hi, the workflow now is something like this: - Create a new build configuration with `--with-extra-cxxflags` and `with-extra-cflags` set to `-ftime-trace -ftime-trace-granularity=500` - Make an hotspot build - Parse all the `.json` files (in `build/conf-name/hotspot/variant-server/libjvm/objs` with `ClangBuildAnalyzer --all` - Extract build information with `ClangBuildAnalyzer --analyze` - Get the top N headers with some bash scripting The last two steps are in this script: https://github.com/fandreuz/jdk-stuff/blob/master/update_precompiled I could possibly automate the whole thing, let me know if you think that would be useful. Alternatively, I can write some lines in `building.md`, or add all the steps to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3224770938 From kvn at openjdk.org Tue Aug 26 16:17:34 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 26 Aug 2025 16:17:34 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga wrote: > `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result: > > > CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid > > > It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor") > > According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core. > > After this change, we can see correct number of cores as following on 3300X: > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26819#pullrequestreview-3156397528 From ihse at openjdk.org Tue Aug 26 16:18:42 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Aug 2025 16:18:42 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v16] In-Reply-To: <3v0ViYAqvt3TgJoFHeIeowWKnsdCCcE8XLL_aYsY_EQ=.7697d981-540c-4b89-af4f-5180d10cb0bb@github.com> References: <3v0ViYAqvt3TgJoFHeIeowWKnsdCCcE8XLL_aYsY_EQ=.7697d981-540c-4b89-af4f-5180d10cb0bb@github.com> Message-ID: On Tue, 26 Aug 2025 07:59:33 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > remove The important thing is to record how this was created. But if you can spare the time to actually write it as a script, that would be the best. A runnable script is always better than a step-by-step instruction. That would allow us to rerun this with very little cost at a higher frequency (perhaps once a year, or once per release or so) to automatically keep Hotspot build time optimized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3224868516 From iklam at openjdk.org Tue Aug 26 17:03:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 26 Aug 2025 17:03:36 GMT Subject: RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3] In-Reply-To: References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: On Mon, 25 Aug 2025 09:02:49 GMT, Francesco Andreuzzi wrote: >> We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. >> >> This change fixes a build failure I'm getting with clang20: >> >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning >> 43 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning >> 48 | memset(this, 0, sizeof(*this)); >> | ^ >> | (void*) >> 2 errors generated. >> >> >> Testing: >> - [x] tier1 fast-debug >> - [x] tier2 fast-debug > > Francesco Andreuzzi 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 resolved-default-cctor > - Merge branch 'master' into resolved-default-cctor > - use copy ctor I created a PR to add comments about the need for copy_from(), etc https://github.com/openjdk/jdk/pull/26946 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3225011217 From iklam at openjdk.org Tue Aug 26 17:06:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 26 Aug 2025 17:06:04 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() Message-ID: [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. ------------- Commit messages: - Fixed whitespace - 8366193: Add comments about ResolvedFieldEntry::copy_from() Changes: https://git.openjdk.org/jdk/pull/26946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366193 Stats: 36 lines in 3 files changed: 33 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26946/head:pull/26946 PR: https://git.openjdk.org/jdk/pull/26946 From mdonovan at openjdk.org Tue Aug 26 17:08:38 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 26 Aug 2025 17:08:38 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text test/jdk/sun/security/krb5/name/Constructors.java line 28: > 26: * @summary Make PrincipalName and Realm immutable > 27: * @modules java.security.jgss/sun.security.krb5 > 28: * @run main/othervm Constructors Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2301616789 From vlivanov at openjdk.org Tue Aug 26 17:25:37 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 26 Aug 2025 17:25:37 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v7] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 04:09:28 GMT, Ioi Lam wrote: >> Implement `-Xlog:aot+map` in the production run: >> >> >> $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ >> -Xlog:aot+map=file=aot.map:none:filesize=0 \ >> HelloWorld >> >> >> I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: >> >> 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. >> 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added comment about why -Xlog:aot+map,...,filesize=0 is needed Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26514#pullrequestreview-3156618560 From kbarrett at openjdk.org Tue Aug 26 18:40:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Aug 2025 18:40:42 GMT Subject: RFR: 8366037: Remove oopDesc::mark_addr() [v2] In-Reply-To: References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Tue, 26 Aug 2025 08:12:19 GMT, Aleksey Shipilev wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> base_addr > > This looks fine. TIL that you can overload methods with cv-qualifiers. Thanks for reviews @shipilev @stefank @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/26914#issuecomment-3225291254 From kbarrett at openjdk.org Tue Aug 26 18:40:43 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Aug 2025 18:40:43 GMT Subject: Integrated: 8366037: Remove oopDesc::mark_addr() In-Reply-To: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> References: <9_Ai-S3EWmew4FPBdwTp9PcWH0inK7CzI739IeASs9M=.03a58811-9280-4e19-a654-44eba25962b9@github.com> Message-ID: On Sat, 23 Aug 2025 23:02:33 GMT, Kim Barrett wrote: > Please review this change that removes the function oopDesc::mark_addr(). > It's kind of a suspicious function, since it is casting away the volatile for > a location that has concurrent reads and writes. But there isn't any code that > examines the value at the obtained address. Instead, it's just used as the > base address for a few prefetches. We change those places accordingly, and > remove the now unused mark_addr function. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: c203e709 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/c203e7093e9b8c52cdf4ae249ab27d16d6a2c623 Stats: 16 lines in 4 files changed: 6 ins; 5 del; 5 mod 8366037: Remove oopDesc::mark_addr() Reviewed-by: shade, stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26914 From dlong at openjdk.org Tue Aug 26 19:17:35 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 26 Aug 2025 19:17:35 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v5] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: <_EnbARdkf6sV3fgUz9NPOHxnM1A55HbFqxFs-l8NAtk=.46fa85e0-d1d4-4094-9a61-553074fa2537@github.com> On Tue, 26 Aug 2025 13:51:53 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > CONST64 vs explicit casting. BTW, gcc x64 generates slightly better code using a union (which it converts into shifts anyway), but then we have to deal with endianness. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26809#issuecomment-3225420652 From dlong at openjdk.org Tue Aug 26 20:56:36 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 26 Aug 2025 20:56:36 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable (I realize this is a tangent, but maybe there is a separate bug here...) > To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced: https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064 Class.forName(name, false, loader) would result in a prepared class but without the event being sent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3225699087 From liach at openjdk.org Tue Aug 26 20:56:42 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 26 Aug 2025 20:56:42 GMT Subject: RFR: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. Thanks for the reviews! This will help my use of ConstantPool reflection for leyden prototyping. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3225698937 From liach at openjdk.org Tue Aug 26 20:56:43 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 26 Aug 2025 20:56:43 GMT Subject: Integrated: 8365885: Clean up constant pool reflection native code In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion. This pull request has now been integrated. Changeset: b426151a Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/b426151a33158637eb04c07a5133d95cbb8bf04c Stats: 142 lines in 6 files changed: 18 ins; 3 del; 121 mod 8365885: Clean up constant pool reflection native code Reviewed-by: iklam, alanb ------------- PR: https://git.openjdk.org/jdk/pull/26870 From amenkov at openjdk.org Tue Aug 26 21:36:36 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 26 Aug 2025 21:36:36 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <49qk6MM99RlDuhksM3pPOjGXWm6fy8av7JPoAn4N2n8=.729ed685-2abd-4571-bc83-a421f026fde5@github.com> On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable The fix looks good from serviceability perspective ------------- Marked as reviewed by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3157377855 From duke at openjdk.org Tue Aug 26 21:39:25 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 21:39:25 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v17] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - comment - script ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/32e7d31c..64c6db93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=15-16 Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Tue Aug 26 21:39:25 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 21:39:25 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v16] In-Reply-To: References: <3v0ViYAqvt3TgJoFHeIeowWKnsdCCcE8XLL_aYsY_EQ=.7697d981-540c-4b89-af4f-5180d10cb0bb@github.com> Message-ID: On Tue, 26 Aug 2025 16:16:25 GMT, Magnus Ihse Bursie wrote: > The important thing is to record how this was created. But if you can spare the time to actually write it as a script, that would be the best. A runnable script is always better than a step-by-step instruction. That would allow us to rerun this with very little cost at a higher frequency (perhaps once a year, or once per release or so) to automatically keep Hotspot build time optimized. Added in e5029bfa1c311eee88a16ed02dcdf2c816854cc7, it contains all the steps I listed above ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3225803676 From ihse at openjdk.org Tue Aug 26 22:23:27 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Aug 2025 22:23:27 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v17] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 21:39:25 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - comment > - script Super duper! Thank you so much for your work on this PR. ?? ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3157470771 From duke at openjdk.org Tue Aug 26 22:34:39 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 22:34:39 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: no executable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/64c6db93..cad12390 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=16-17 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Tue Aug 26 22:34:40 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 26 Aug 2025 22:34:40 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v16] In-Reply-To: References: <3v0ViYAqvt3TgJoFHeIeowWKnsdCCcE8XLL_aYsY_EQ=.7697d981-540c-4b89-af4f-5180d10cb0bb@github.com> Message-ID: On Tue, 26 Aug 2025 16:16:25 GMT, Magnus Ihse Bursie wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> remove > > The important thing is to record how this was created. But if you can spare the time to actually write it as a script, that would be the best. A runnable script is always better than a step-by-step instruction. That would allow us to rerun this with very little cost at a higher frequency (perhaps once a year, or once per release or so) to automatically keep Hotspot build time optimized. @magicus Thank you for all the feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3225932799 From jrose at openjdk.org Tue Aug 26 22:45:41 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 26 Aug 2025 22:45:41 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam wrote: > We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: > > > InstanceKlass* x = ....; > Klass* s = x->super(); // should call java_super() > InstanceKlass::cast(s)->xyz(); > > > The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: > > - `super()` returns `[Ljava/lang/Object;` > - `java_super()` returns `Ljava/lang/Object;` > > However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. > > See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 > > Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. > > I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. > > I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. > > To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. Not necessarily for this PR, but I nominate `jvm_super` as the "true name" for `super`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3225953172 From duke at openjdk.org Tue Aug 26 22:53:07 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 26 Aug 2025 22:53:07 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: References: Message-ID: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` Rui Li has updated the pull request incrementally with one additional commit since the last revision: Update for comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26907/files - new: https://git.openjdk.org/jdk/pull/26907/files/a9d1f6a3..18758749 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26907/head:pull/26907 PR: https://git.openjdk.org/jdk/pull/26907 From iveresov at openjdk.org Tue Aug 26 22:59:54 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 26 Aug 2025 22:59:54 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Relax verification invariant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26866/files - new: https://git.openjdk.org/jdk/pull/26866/files/c33d94bc..3b6dc806 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26866&range=06-07 Stats: 32 lines in 4 files changed: 1 ins; 26 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26866/head:pull/26866 PR: https://git.openjdk.org/jdk/pull/26866 From iveresov at openjdk.org Tue Aug 26 23:00:44 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 26 Aug 2025 23:00:44 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v6] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> <7zawxaIMLdnM5VraQwvZL3wcj3v8vYtzEvJpWYwQLqg=.eecc2aa6-f47e-44b8-842b-10621e83c2ae@github.com> Message-ID: On Fri, 22 Aug 2025 22:35:08 GMT, Vladimir Kozlov wrote: >> Yes, it runs in a dedicated thread. It doesn't need to terminate. > > Add comment about this. I removed this with the last update, so it's not necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2302328711 From iveresov at openjdk.org Tue Aug 26 23:00:44 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 26 Aug 2025 23:00:44 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v7] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Fri, 22 Aug 2025 20:29:10 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > One more nit I decided to relax the verification invariant a bit since it's very hard to ensure that the only thread running is the thread doing the vm exit. Hopefully that's the last change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26866#issuecomment-3225988539 From sviswanathan at openjdk.org Tue Aug 26 23:03:49 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 26 Aug 2025 23:03:49 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays In-Reply-To: References: Message-ID: <3POpSVvfIfpk3E7z3h2CnoqpTx7TaNgzHO94zlFeFZ0=.d7b3222f-b439-4f97-89d1-541d479978c5@github.com> On Tue, 12 Aug 2025 14:54:22 GMT, Vladimir Ivanov wrote: > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... @IvaVladimir Thanks for looking into this. It would be good to make this intrinsic (via OptimizeFill) available by default for ECore platforms by making the following change in vm_versions_x86.cpp: - if (MaxVectorSize < 32 || !VM_Version::supports_avx512vlbw()) { + if (MaxVectorSize < 32 || (!EnableX86ECoreOpts && !VM_Version::supports_avx512vlbw())) { OptimizeFill = false; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3225994364 From sviswanathan at openjdk.org Tue Aug 26 23:16:41 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 26 Aug 2025 23:16:41 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 14:54:22 GMT, Vladimir Ivanov wrote: > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5887: > 5885: cmpptr(count, 256< 5886: jcc(Assembler::below, L_fill_32_bytes); > 5887: I see you have an overhead for small sizes, may be we could do a check for small sizes before line 5885 something like below: movdl(xtmp, value); vpbroadcastd(xtmp, xtmp, Assembler::AVX_256bit); subptr(count, 16 << shift); jcc(Assembler::less, L_check_fill_32_bytes); Or alternatively move the entire if (EnableX86ECoreOpts) { } block of code to line 5933 adjusting the jump labels accordingly. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5888: > 5886: jcc(Assembler::below, L_fill_32_bytes); > 5887: > 5888: BIND(L_align_64_bytes); Need to add an align(16) before BIND(L_align_64_bytes); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2302349708 PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2302351365 From ysuenaga at openjdk.org Wed Aug 27 00:00:48 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 27 Aug 2025 00:00:48 GMT Subject: Integrated: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga wrote: > `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result: > > > CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid > > > It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor") > > According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core. > > After this change, we can see correct number of cores as following on 3300X: > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor This pull request has now been integrated. Changeset: 1aca920f Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/1aca920f5987399dbd114fd5e62b26b363363e64 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod 8365673: Incorrect number of cores are reported on Ryzen CPU Reviewed-by: dholmes, kvn ------------- PR: https://git.openjdk.org/jdk/pull/26819 From ysuenaga at openjdk.org Wed Aug 27 00:00:48 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 27 Aug 2025 00:00:48 GMT Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga wrote: > `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result: > > > CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid > > > It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor") > > According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core. > > After this change, we can see correct number of cores as following on 3300X: > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c > CPU Model and flags from /proc/cpuinfo: > model name : AMD Ryzen 3 3300X 4-Core Processor Thank you both! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3226151908 From kbarrett at openjdk.org Wed Aug 27 00:13:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 00:13:42 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v5] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Tue, 26 Aug 2025 13:51:53 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > CONST64 vs explicit casting. test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 301: > 299: TEST(globalDefinitions, jlong_from) { > 300: jlong val = jlong_from(0xFF, 0); > 301: EXPECT_EQ(val, 0x00000000FF00000000); Should be using `CONST64` here and elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2302451319 From iklam at openjdk.org Wed Aug 27 02:20:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 02:20:35 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v8] In-Reply-To: References: Message-ID: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. 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 25 additional commits since the last revision: - Added test for -Xlog:aot+map with dynamic archive - Merge branch 'master' into 8362566-log-aot-map-for-existing-aot-cache - Added comment about why -Xlog:aot+map,...,filesize=0 is needed - @vnkozlov comments -- added AOTMapTest.java - Fixed crash with ZGC - Fixed Windows crashes - Fixed include order - make CDSMapTest.java flagless - Added test case for -Xlog:aot+map in production run - more clean up - ... and 15 more: https://git.openjdk.org/jdk/compare/13405606...223771b5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26514/files - new: https://git.openjdk.org/jdk/pull/26514/files/16895a2a..223771b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26514&range=06-07 Stats: 16910 lines in 642 files changed: 10104 ins; 4431 del; 2375 mod Patch: https://git.openjdk.org/jdk/pull/26514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26514/head:pull/26514 PR: https://git.openjdk.org/jdk/pull/26514 From vlivanov at openjdk.org Wed Aug 27 04:29:57 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 27 Aug 2025 04:29:57 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v8] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 02:20:35 GMT, Ioi Lam wrote: >> Implement `-Xlog:aot+map` in the production run: >> >> >> $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ >> -Xlog:aot+map=file=aot.map:none:filesize=0 \ >> HelloWorld >> >> >> I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: >> >> 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. >> 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. > > 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 25 additional commits since the last revision: > > - Added test for -Xlog:aot+map with dynamic archive > - Merge branch 'master' into 8362566-log-aot-map-for-existing-aot-cache > - Added comment about why -Xlog:aot+map,...,filesize=0 is needed > - @vnkozlov comments -- added AOTMapTest.java > - Fixed crash with ZGC > - Fixed Windows crashes > - Fixed include order > - make CDSMapTest.java flagless > - Added test case for -Xlog:aot+map in production run > - more clean up > - ... and 15 more: https://git.openjdk.org/jdk/compare/8a26ec52...223771b5 Marked as reviewed by vlivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26514#pullrequestreview-3158218513 From iklam at openjdk.org Wed Aug 27 04:29:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 04:29:57 GMT Subject: RFR: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache [v7] In-Reply-To: References: Message-ID: <9jh2zFm_a6_HqmgY2lldStuDijntITzyV_Ws2Dg4fZw=.437426a4-bf98-46ce-a5ea-988ac3f517d6@github.com> On Fri, 22 Aug 2025 15:20:30 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment about why -Xlog:aot+map,...,filesize=0 is needed > > Good. Thanks @vnkozlov and @iwanowww for the review. Passed tiers1-4 and build-tier5 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26514#issuecomment-3226696229 From iklam at openjdk.org Wed Aug 27 04:29:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 04:29:58 GMT Subject: Integrated: 8362566: Use -Xlog:aot+map to print contents of existing AOT cache In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 16:56:32 GMT, Ioi Lam wrote: > Implement `-Xlog:aot+map` in the production run: > > > $ java -cp HelloWorld.jar -XX:AOTCache=HelloWorld.aot \ > -Xlog:aot+map=file=aot.map:none:filesize=0 \ > HelloWorld > > > I moved the old logging code from archiveBuilder.cpp into a new fille, aotMapLogger.cpp. I did the following to print the map in the production run: > > 1. When dumping the AOT cache, `ArchiveBuilder` maintains a list of all the metaspace objects in the archive. However, there's no such list when we are loading from the AOT cache. Therefore, I added a new `RuntimeGatherArchivedMetaspaceObjs` class to discover all the metaspace objects that are stored in the AOT cache. > 2. A significant rewrite is needed for printing the oops (see comments around `FakeOop`) because we only have an image of the oops in the AOT cache and these aren't real heap objects. This pull request has now been integrated. Changeset: aaff9dec Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/aaff9dec241e4d8eebefd6beaf287582621f315c Stats: 1767 lines in 14 files changed: 1304 ins; 454 del; 9 mod 8362566: Use -Xlog:aot+map to print contents of existing AOT cache Reviewed-by: vlivanov, kvn ------------- PR: https://git.openjdk.org/jdk/pull/26514 From dholmes at openjdk.org Wed Aug 27 06:40:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Aug 2025 06:40:47 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> References: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> Message-ID: On Tue, 26 Aug 2025 20:53:57 GMT, Dean Long wrote: > If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3226945362 From dholmes at openjdk.org Wed Aug 27 06:50:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Aug 2025 06:50:44 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: References: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> Message-ID: On Tue, 26 Aug 2025 09:38:54 GMT, Fredrik Bredberg wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer feedback > > A good looking PR, and a good step in the right direction. Nice! > > But as @kimbarrett I also noticed there are a number of calls with `buflen - 1`, which in my case consumed too mush of the review time. So it would be nice to see a follow up that deals with code like [this](https://github.com/openjdk/jdk/blob/38003a227a55dbd6adb89dcb10dc619f08bb0187/src/hotspot/os/bsd/os_bsd.cpp#L2493). Thanks for the review @fbredber . I have added your cleanup suggestion to [JDK-8365896](https://bugs.openjdk.org/browse/JDK-8365896) as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3226972822 From ihse at openjdk.org Wed Aug 27 07:38:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 27 Aug 2025 07:38:51 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:34:39 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > no executable Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3158705848 From duke at openjdk.org Wed Aug 27 07:48:49 2025 From: duke at openjdk.org (duke) Date: Wed, 27 Aug 2025 07:48:49 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:34:39 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > no executable @fandreuz Your change (at version cad123907bf5414e4bc0901047bed828b17f7c18) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3227159087 From azafari at openjdk.org Wed Aug 27 08:24:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 27 Aug 2025 08:24:59 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: used CONST64 for all 64-bits const terms. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26809/files - new: https://git.openjdk.org/jdk/pull/26809/files/e6ee02ff..dc273d02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26809&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26809/head:pull/26809 PR: https://git.openjdk.org/jdk/pull/26809 From azafari at openjdk.org Wed Aug 27 08:24:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 27 Aug 2025 08:24:59 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v5] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: <76dQvhTWi1lycYSnqWmXp1Dj5ATd68lvCkqP0eq3e8g=.f5bf6cb5-c872-463c-a3eb-6d5de379af1b@github.com> On Wed, 27 Aug 2025 00:11:30 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> CONST64 vs explicit casting. > > test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 301: > >> 299: TEST(globalDefinitions, jlong_from) { >> 300: jlong val = jlong_from(0xFF, 0); >> 301: EXPECT_EQ(val, 0x00000000FF00000000); > > Should be using `CONST64` here and elsewhere. Done. All windows tests had been passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2303236799 From adinn at openjdk.org Wed Aug 27 08:40:49 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Aug 2025 08:40:49 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: <1uRuxv5eKEFnp3PCm8XzqqfRLbXVdijvfkkq3ljNL8A=.43aef734-8428-47d6-b7b3-898af64cca1b@github.com> On Tue, 26 Aug 2025 16:53:17 GMT, Ioi Lam wrote: > [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. > > This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. Nice explanation! ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26946#pullrequestreview-3158891261 From duke at openjdk.org Wed Aug 27 08:55:40 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 08:55:40 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 16:53:17 GMT, Ioi Lam wrote: > [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. > > This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. Hi @iklam, thanks for following up on this. I was wondering, would it be possible to explicitly set padding fields with default value zero? Something like this: u8 padding1; #ifdef _LP64 u32 padding2; #endif so we could use the default constructor, like I'm doing in #26818. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3227351623 From adinn at openjdk.org Wed Aug 27 09:19:41 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Aug 2025 09:19:41 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam wrote: > We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: > > > InstanceKlass* x = ....; > Klass* s = x->super(); // should call java_super() > InstanceKlass::cast(s)->xyz(); > > > The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: > > - `super()` returns `[Ljava/lang/Object;` > - `java_super()` returns `Ljava/lang/Object;` > > However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. > > See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 > > Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. > > I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. > > I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. > > To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. I found two more occurrences of casting super() to InstanceKlass: src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp:79 ik = (const InstanceKlass*)ik->super(); src/hotspot/share/prims/jni.cpp:209 Klass* field_klass = k; Klass* super_klass = field_klass->super(); // With compressed oops the most super class with nonstatic fields would // be the owner of fields embedded in the header. while (InstanceKlass::cast(super_klass)->has_nonstatic_fields() && InstanceKlass::cast(super_klass)->contains_field_offset(offset)) { field_klass = super_klass; // super contains the field also super_klass = field_klass->super(); } The first one ought perhaps to be using InstanceKlass::superklass()? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3227432942 From adinn at openjdk.org Wed Aug 27 09:26:43 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Aug 2025 09:26:43 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam wrote: > We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: > > > InstanceKlass* x = ....; > Klass* s = x->super(); // should call java_super() > InstanceKlass::cast(s)->xyz(); > > > The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: > > - `super()` returns `[Ljava/lang/Object;` > - `java_super()` returns `Ljava/lang/Object;` > > However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. > > See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 > > Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. > > I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. > > I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. > > To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. src/hotspot/share/runtime/deoptimization.cpp line 1479: > 1477: // Gets the fields of `klass` that are eliminated by escape analysis and need to be reassigned > 1478: static GrowableArray* get_reassigned_fields(InstanceKlass* klass, GrowableArray* fields, bool is_jvmci) { > 1479: InstanceKlass* super = klass->java_super(); What is wrong with using `superklass()` here? We already know that `klass` is an `InstanceKlass*` so we don't need to make a virtual call to `java_super()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26908#discussion_r2303382149 From duke at openjdk.org Wed Aug 27 09:51:59 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 27 Aug 2025 09:51:59 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:41:03 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8357086: Removed extra empty line. > - 8357086: Removed placeholder for nodiscard attribute. I have re-run tests in tiers 1-3 on all available platforms, no problems detected after the latest changes on this branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3227534780 From shade at openjdk.org Wed Aug 27 10:47:48 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 27 Aug 2025 10:47:48 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:34:39 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > no executable Ran the script locally, and noticed that on my Mac this was the difference: -#include "oops/oopHandle.inline.hpp" #include "oops/oop.inline.hpp" +#include "oops/oopHandle.inline.hpp" Something is a bit off with sorting, I think. Indeed, this fails: $ diff --git a/test/hotspot/jtreg/sources/TestIncludesAreSorted.java b/test/hotspot/jtreg/sources/TestIncludesAreSorted.java index 1a304a44944..287aad01b78 100644 --- a/test/hotspot/jtreg/sources/TestIncludesAreSorted.java +++ b/test/hotspot/jtreg/sources/TestIncludesAreSorted.java @@ -58,6 +58,7 @@ public class TestIncludesAreSorted { "share/metaprogramming", "share/oops", "share/opto", + "share/precompiled", "share/services", "share/utilities" }; $ CONF=macosx-aarch64-server-fastdebug make images test TEST=sources/ STDERR: java.lang.RuntimeException: 1 files with unsorted headers found: /Users/shipilev/Work/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp This is a minor thing, and we can technically deal with it once we sort the includes in `precompiled.hpp` in the constellation of issues that are dedicated to include sorting. But it would also be great to do this right from the get-go. See if there is anything easy missing in the script? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3227683555 From eastigeevich at openjdk.org Wed Aug 27 11:20:42 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 11:20:42 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable MacOS test failures are known: - https://bugs.openjdk.org/browse/JDK-8344577 - https://bugs.openjdk.org/browse/JDK-8215245 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3227792198 From eastigeevich at openjdk.org Wed Aug 27 11:23:44 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 11:23:44 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> Message-ID: <1p2Lq9aw48jkG5BjxHT0GrrJ-94WkPZ77YMBaARuxf4=.8795152e-d3f0-421a-8cc3-ee075cfa6d2d@github.com> On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes wrote: >> (I realize this is a tangent, but maybe there is a separate bug here...) >> >>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). >> >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced: >> >> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064 >> >> Class.forName(name, false, loader) would result in a prepared class but without the event being sent. > >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced > > @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed. Hi @dholmes-ora, Are there any other action items/changes required? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3227799271 From azafari at openjdk.org Wed Aug 27 11:31:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 27 Aug 2025 11:31:02 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer Message-ID: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. The acceptable value is changed to 64K. Tests: linux tier1 is in progress.. ------------- Commit messages: - 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer Changes: https://git.openjdk.org/jdk/pull/26955/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351334 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From jpai at openjdk.org Wed Aug 27 11:30:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 27 Aug 2025 11:30:44 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 11:17:50 GMT, Evgeny Astigeevich wrote: > MacOS test failures are known The virtual thread test that is failing in this PR's GitHub actions job is `java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking#id0` It has this: javatestOS=Mac OS X 14.7.6 (aarch64) javatestVersion=6.0-ea+b24-2025-08-18-${BUILT_FROM_COMMIT} jtregVersion=jtreg 7.5.2 dev 0 ... #section:main ----------messages:(10/424)---------- command: main GetStackTraceALotWhenBlocking 100000 reason: User specified action: run main/othervm/timeout=300 GetStackTraceALotWhenBlocking 100000 started: Tue Aug 26 14:24:40 UTC 2025 Mode: othervm [/othervm specified] Additional options from @modules: --add-modules jdk.management Process id: 21219 Timeout information: --- Timeout information end. finished: Tue Aug 26 14:47:22 UTC 2025 elapsed time (seconds): 1361.83 ----------configuration:(3/42)---------- Boot Layer add modules: jdk.management ----------System.out:(1190/56017)---------- 2025-08-26T14:24:41.601528Z => 48 of 100000 ... 2025-08-26T14:44:37.436452Z => 99703 of 100000 2025-08-26T14:44:38.451885Z => 99752 of 100000 2025-08-26T14:44:39.474953Z => 99787 of 100000 Timeout signalled after 1200 seconds 2025-08-26T14:44:40.477403Z => 99833 of 100000 2025-08-26T14:44:41.478976Z => 99886 of 100000 2025-08-26T14:44:42.487173Z => 99931 of 100000 2025-08-26T14:44:43.495950Z => 99975 of 100000 2025-08-26T14:44:44.055060Z => 100000 of 100000 2025-08-26T14:44:44.055248Z VirtualThread[#27]/runnable at ForkJoinPool-1-worker-3 => 3904532796 loops 2025-08-26T14:44:44.055381Z VirtualThread[#23]/runnable at ForkJoinPool-1-worker-1 => 3293339644 loops ----------System.err:(1/15)---------- STATUS:Passed. ... test result: Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-26.jdk/Contents/Home/bin/java' timed out (timeout set to 1200000ms, elapsed time including timeout handling was 1361819ms). It looks like it's taking long to complete and that's causing the test timeout. I recollect that this test failure was addressed some time back, so this appears to be a new occurrence. In any case, this failure doesn't look related to the changes in this PR because I see some other PRs having failed with this same issue. I'll check and file an issue later today/tomorrow (unless anyone else gets to it first). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3227818072 From jbechberger at openjdk.org Wed Aug 27 12:16:01 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 27 Aug 2025 12:16:01 GMT Subject: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning Message-ID: Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. ------------- Commit messages: - Fix startup message printing Changes: https://git.openjdk.org/jdk/pull/26957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366232 Stats: 66 lines in 8 files changed: 54 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26957/head:pull/26957 PR: https://git.openjdk.org/jdk/pull/26957 From mli at openjdk.org Wed Aug 27 12:33:10 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 27 Aug 2025 12:33:10 GMT Subject: [jdk25] RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 Message-ID: <8DrCRTabQbu5m_B2x2nYfyIwo7EvSgxAo3rm0o8WqlI=.33d89c01-6202-42f1-af21-4f6626f05d09@github.com> 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 ------------- Commit messages: - Backport 28602f3d3ec15b5241a33a46ce43349e6300395d Changes: https://git.openjdk.org/jdk/pull/26958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365206 Stats: 264 lines in 6 files changed: 237 ins; 21 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26958/head:pull/26958 PR: https://git.openjdk.org/jdk/pull/26958 From coleenp at openjdk.org Wed Aug 27 12:42:42 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 12:42:42 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: <-3ubfdrNYgRkPEQqxDEcQ3bawHZxFdskhQ4YgNSEgPg=.d6760842-0aa3-45a3-9140-d27067a3800d@github.com> On Tue, 26 Aug 2025 16:53:17 GMT, Ioi Lam wrote: > [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. > > This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. This comment is helpful. At one point, I made Metaspace::allocate not zero memory and several things broke. This would have been one of them it if existed. I don't know if there's a better solution to to ensuring alignment gaps in fields always zeroed. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26946#pullrequestreview-3159621546 From mli at openjdk.org Wed Aug 27 13:08:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 27 Aug 2025 13:08:52 GMT Subject: [jdk25] RFR: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 In-Reply-To: <8DrCRTabQbu5m_B2x2nYfyIwo7EvSgxAo3rm0o8WqlI=.33d89c01-6202-42f1-af21-4f6626f05d09@github.com> References: <8DrCRTabQbu5m_B2x2nYfyIwo7EvSgxAo3rm0o8WqlI=.33d89c01-6202-42f1-af21-4f6626f05d09@github.com> Message-ID: On Wed, 27 Aug 2025 12:24:48 GMT, Hamlin Li wrote: > 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 this needs to go into 25u instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26958#issuecomment-3228134125 From mli at openjdk.org Wed Aug 27 13:08:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 27 Aug 2025 13:08:52 GMT Subject: [jdk25] Withdrawn: 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 In-Reply-To: <8DrCRTabQbu5m_B2x2nYfyIwo7EvSgxAo3rm0o8WqlI=.33d89c01-6202-42f1-af21-4f6626f05d09@github.com> References: <8DrCRTabQbu5m_B2x2nYfyIwo7EvSgxAo3rm0o8WqlI=.33d89c01-6202-42f1-af21-4f6626f05d09@github.com> Message-ID: On Wed, 27 Aug 2025 12:24:48 GMT, Hamlin Li wrote: > 8365206: RISC-V: compiler/c2/irTests/TestFloat16ScalarOperations.java is failing on riscv64 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26958 From erikj at openjdk.org Wed Aug 27 13:09:49 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Aug 2025 13:09:49 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 10:44:45 GMT, Aleksey Shipilev wrote: > Ran the script locally, and noticed that on my Mac this was the difference: > > ``` > -#include "oops/oopHandle.inline.hpp" > #include "oops/oop.inline.hpp" > +#include "oops/oopHandle.inline.hpp" > ``` > > Something is a bit off with sorting, I think. Mac file systems are case insensitive by default, so I figured that must be the issue, but looking at the script it uses `sort` which should not be case insensitive by default. Not seeing anything that sticks out here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3228137603 From erikj at openjdk.org Wed Aug 27 13:09:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Aug 2025 13:09:51 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:34:39 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > no executable make/scripts/update_pch.sh line 69: > 67: > 68: make clean CONF_NAME="$RUN_NAME" > 69: make -j hotspot CONF_NAME="$RUN_NAME" There is no need to set `-j` with the OpenJDK build system. Configure detects a suitable amount of parallellism and our bootstrap makefile adds it to the relevant make command line. This `-j` flag becomes a noop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2303865006 From coleenp at openjdk.org Wed Aug 27 13:15:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 13:15:45 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable The problem might be higher in the call stack than here. I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race. The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them. Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3159740645 From eastigeevich at openjdk.org Wed Aug 27 13:21:50 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 13:21:50 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <2CINkZVwp01VVT58M9eehT3rziuu52neYgAlDqGNung=.122b252d-7ede-4081-8ef7-d5baae927bc0@github.com> On Wed, 27 Aug 2025 13:12:47 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > The problem might be higher in the call stack than here. I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race. The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them. Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking. Hi @coleenp, > The problem might be higher in the call stack than here. I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race. The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them. Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking. Should we have a separate JBS issue to cover `JvmtiEnv::GetBytecodes`? [JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444) covers the issue with `JvmtiEnv::RetransformClasses`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228175667 From coleenp at openjdk.org Wed Aug 27 13:26:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 13:26:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable I think both should link the class first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228199368 From coleenp at openjdk.org Wed Aug 27 13:31:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 13:31:45 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable Also sorry, I was reviewing this on my phone earlier this week and am just back from being away. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228217405 From asmehra at openjdk.org Wed Aug 27 13:47:05 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 27 Aug 2025 13:47:05 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v2] In-Reply-To: References: Message-ID: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. Ashutosh Mehra 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 remove-abstract_method_handler - 8365501: Remove speical AdapterHandlerEntry for abstract methods Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26764/files - new: https://git.openjdk.org/jdk/pull/26764/files/b0cf055a..cd8b85f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26764&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26764&range=00-01 Stats: 27063 lines in 851 files changed: 15250 ins; 8209 del; 3604 mod Patch: https://git.openjdk.org/jdk/pull/26764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26764/head:pull/26764 PR: https://git.openjdk.org/jdk/pull/26764 From eastigeevich at openjdk.org Wed Aug 27 13:54:46 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 13:54:46 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <1KLcFmF-jeGWzU8EETPPY_JTI5Kq36FHIMdnX0FOiAU=.af70c9a2-ac30-46bf-8ce3-e6040d971167@github.com> On Wed, 27 Aug 2025 13:23:58 GMT, Coleen Phillimore wrote: > I think both should link the class first. It's because I don't like the init-lock exposed this way, and I'm concerned with JVMTI getting and saving unverified bytecodes. In logs I see we do class verification: [0.962s][debug][class,link ] JvmtiEnv::RetransformClasses [0.970s][debug][redefine,class,load ] loading name=BigClass kind=101 (avail_mem=252818288K) [0.970s][debug][class,preorder ] BigClass source: __VM_RedefineClasses__ [0.971s][debug][class,load,placeholders ] entry BigClass : find_and_add DETECT_CIRCULARITY , next_klass_name 'java/lang/Object' [0.971s][debug][class,load,placeholders ] loadInstanceThreadQ threads: [0.971s][debug][class,load,placeholders ] circularityThreadQ threads:0x0000ffff903953b0, [0.971s][debug][class,load,placeholders ] defineThreadQ threads: [0.971s][debug][class,load,placeholders ] entry BigClass : find_and_remove DETECT_CIRCULARITY , next_klass_name 'java/lang/Object' [0.971s][debug][class,load,placeholders ] loadInstanceThreadQ threads: [0.971s][debug][class,load,placeholders ] circularityThreadQ threads:0x0000ffff903953b0, [0.971s][debug][class,load,placeholders ] defineThreadQ threads: [0.971s][debug][class,load ] set_secondary_supers: hash_slot: 45; klass: BigClass [0.971s][debug][class,load ] - 0 elements; bitmap: 0x0000000000000000 [0.973s][info ][class,load ] BigClass source: __VM_RedefineClasses__ [0.973s][debug][class,load ] klass: 0x000000001a088000 super: 0x000000001a001200 loader: [loader data: 0x0000ffff903fc510 for instance a 'Main$AsmClassLoader'{0x00000000ff1a3d28}] bytes: 1403966 checksum: 4f2e199f [0.973s][debug][class,resolve ] BigClass java.lang.Object (super) [0.973s][debug][class,link ] VM_RedefineClasses::load_new_class_versions 0x000000001a086800 [0.973s][info ][class,init ] Start class verification for: BigClass [1.005s][info ][class,init ] End class verification for: BigClass [1.005s][debug][class,link ] rewrite_class 0x000000001a086800 [1.016s][debug][class,link ] done rewrite_class 0x000000001a086800 [1.016s][info ][class,init ] Start class verification for: BigClass [1.048s][info ][class,init ] End class verification for: BigClass [1.048s][info ][redefine,class,constantpool] old_cp_len=116, scratch_cp_len=116 [1.048s][debug][redefine,class,constantpool] after pass 0: merge_cp_len=116 [1.048s][debug][redefine,class,constantpool] after pass 1a: merge_cp_len=116, scratch_i=116, index_map_len=0 [1.048s][info ][redefine,class,constantpool] merge_cp_len=116, index_map_len=0 [1.048s][debug][class,loader,data ] deallocate added for constant pool [232] {0x0000ffff30947748} [1.059s][debug][redefine,class,load ] loaded name=BigClass (avail_mem=252817012K) [1.079s][debug][class,loader,data ] deallocate added for 'BigClass' [1.079s][info ][redefine,class,load ] redefined name=BigClass, count=1 (avail_mem=252817012K) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228303222 From kbarrett at openjdk.org Wed Aug 27 13:59:44 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 13:59:44 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 08:24:59 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > used CONST64 for all 64-bits const terms. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3159922281 From eastigeevich at openjdk.org Wed Aug 27 14:09:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 14:09:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable Looking into `JvmtiEnv::RetransformClasses` code, it does the following: - Gets the original bytecodes. - Requests `VM_RedefineClasses` op. `VM_RedefineClasses` calls `load_new_class_versions()` in `VM_RedefineClasses::doit_prologue`. `load_new_class_versions()` does the following: - Calls `link_class`. - Calls `Verifier::verify`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228354891 From eastigeevich at openjdk.org Wed Aug 27 14:09:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 14:09:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <1qCUkGAZTjWhP-Se3s7e5zNx4UXhHCHJZm8qOMMpYNI=.0a5795d0-b6ad-4682-827f-e6e54196bdea@github.com> On Wed, 27 Aug 2025 13:28:53 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > Also sorry, I was reviewing this on my phone earlier this week and am just back from being away. @coleenp, > I'm concerned with JVMTI getting and saving unverified bytecodes. Based on the log and the sources, I don't see how this might happen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228362525 From jsjolen at openjdk.org Wed Aug 27 14:21:43 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 27 Aug 2025 14:21:43 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> On Wed, 27 Aug 2025 11:24:07 GMT, Afshin Zafari wrote: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. For example ```c++ size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. release(reserved); reserved = {}; } } The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3228406340 From stefank at openjdk.org Wed Aug 27 14:45:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Aug 2025 14:45:44 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 08:24:59 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > used CONST64 for all 64-bits const terms. test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 306: > 304: EXPECT_EQ(val, CONST64(0x00000000000000FF)); > 305: > 306: val = jlong_from(0xFFFFFFFF, 0); Note that this passes the unsigned int value of 0xFFFFFFFF when the expected type is signed int (jint). If you run with -Wsign-conversion I think you will get a warning. Do we care about that here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2304170713 From eastigeevich at openjdk.org Wed Aug 27 14:57:45 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 14:57:45 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 13:28:53 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > Also sorry, I was reviewing this on my phone earlier this week and am just back from being away. @coleenp, > It's because I don't like the init-lock exposed this way If we don't want to expose the init-lock to JVMTI, we can move `copy_bytecodes` to `InstanceKlass`. IMO having `InstanceKlass::copy_bytecodes` sounds logical to me. Also I think `copy_bytecodes` should use `Rewriter::restore_bytecodes` instead of restoring bytecodes itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228548477 From eastigeevich at openjdk.org Wed Aug 27 15:01:50 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 15:01:50 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable Another thought, we need the fix in 11, 17 and 21, maybe in 8. As the current change is very small, it will be easy to backport it. Additional enhancements can address 26 only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228563705 From coleenp at openjdk.org Wed Aug 27 15:17:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 15:17:44 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <9fG31ThANkObW-DQ3r426pXIGj2DL-aIi34dnFFtcT4=.07336d08-32a2-46b3-877e-01e771876350@github.com> On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable I don't want this in InstanceKlass. Let me work on my suggested change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228626469 From kbarrett at openjdk.org Wed Aug 27 15:50:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Aug 2025 15:50:45 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 14:43:12 GMT, Stefan Karlsson wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> used CONST64 for all 64-bits const terms. > > test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 306: > >> 304: EXPECT_EQ(val, CONST64(0x00000000000000FF)); >> 305: >> 306: val = jlong_from(0xFFFFFFFF, 0); > > Note that this passes the unsigned int value of 0xFFFFFFFF when the expected type is signed int (jint). If you run with -Wsign-conversion I think you will get a warning. Do we care about that here? I hope we will eventually. I'm fine with deferring that to then though, assuming that day ever comes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2304428648 From coleenp at openjdk.org Wed Aug 27 16:13:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 16:13:43 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 15:48:27 GMT, Kim Barrett wrote: >> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 306: >> >>> 304: EXPECT_EQ(val, CONST64(0x00000000000000FF)); >>> 305: >>> 306: val = jlong_from(0xFFFFFFFF, 0); >> >> Note that this passes the unsigned int value of 0xFFFFFFFF when the expected type is signed int (jint). If you run with -Wsign-conversion I think you will get a warning. Do we care about that here? > > I hope we will eventually. I'm fine with deferring that to then though, assuming that day ever comes. It'd be nice not to have a (another?) -Wsign-conversion error in the file that every file includes though :( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2304519374 From asmehra at openjdk.org Wed Aug 27 16:31:43 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 27 Aug 2025 16:31:43 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 13:47:05 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra 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 remove-abstract_method_handler > - 8365501: Remove speical AdapterHandlerEntry for abstract methods > > Signed-off-by: Ashutosh Mehra @adinn @vnkozlov I merged the master into this PR to get the latest changes. Can you please review it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3228915896 From duke at openjdk.org Wed Aug 27 16:50:33 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 16:50:33 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v19] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - stuff - nn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/cad12390..6693cefe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=17-18 Stats: 7 lines in 3 files changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Wed Aug 27 16:50:33 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 16:50:33 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 10:44:45 GMT, Aleksey Shipilev wrote: > See if there is anything easy missing in the script? Thanks @shipilev, I addressed this in 6693cefe01e03cd05a11a93cf04d0d6af78f42bb. I use `SortIncludes.java` instead of `sort`, and I also added `precompiled` to `TestIncludesAreSorted.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3228968082 From duke at openjdk.org Wed Aug 27 16:50:33 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 16:50:33 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 13:01:28 GMT, Erik Joelsson wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> no executable > > make/scripts/update_pch.sh line 69: > >> 67: >> 68: make clean CONF_NAME="$RUN_NAME" >> 69: make -j hotspot CONF_NAME="$RUN_NAME" > > There is no need to set `-j` with the OpenJDK build system. Configure detects a suitable amount of parallellism and our bootstrap makefile adds it to the relevant make command line. This `-j` flag becomes a noop. Interesting, thanks. Fixed in b6749286cb42f657700bc4acf4048b70a042ac43 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2304639399 From duke at openjdk.org Wed Aug 27 16:53:41 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 16:53:41 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Wed, 27 Aug 2025 11:24:07 GMT, Afshin Zafari wrote: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 src/hotspot/share/memory/memoryReserver.cpp line 552: > 550: > 551: char* aligned_heap_base_min_address = align_up((char*)HeapBaseMinAddress, alignment); > 552: assert(aligned_heap_base_min_address != 0,"Should not be 0"); Suggestion: assert(aligned_heap_base_min_address != 0, "Should not be 0"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2304663375 From duke at openjdk.org Wed Aug 27 16:57:50 2025 From: duke at openjdk.org (duke) Date: Wed, 27 Aug 2025 16:57:50 GMT Subject: Withdrawn: 8360023: Add an insertion sort implementation to Hotspot In-Reply-To: <7-Pyowek_M5CSJRJQV73o6SJ8GoHKVuDz0pFjqxVjAg=.6ba9b804-39aa-4379-b689-f55fda4dd17e@github.com> References: <7-Pyowek_M5CSJRJQV73o6SJ8GoHKVuDz0pFjqxVjAg=.6ba9b804-39aa-4379-b689-f55fda4dd17e@github.com> Message-ID: On Thu, 19 Jun 2025 11:05:26 GMT, Quan Anh Mai wrote: > Hi, > > This PR adds an implementation of insertion sort to Hotspot. It is an algorithm that is inplace and stable, and it is the ideal algorithm for arrays with small numbers of elements. The motivation for this is [JDK-8357186](https://bugs.openjdk.org/browse/JDK-8357186) in which a stable sort is desired and the number of elements is small. Additionally, since insertion sort is the most efficient sorting algorithm for small arrays, it can be used in non-stable sort as well. > > In addition, I make some improvements to `GrowableArrayIterator`: > > - Make a non-const variant (our current iterator is const only). > - Add various utility operators to align with a typical iterator. > > [JDK-8360032](https://bugs.openjdk.org/browse/JDK-8360032) is a follow-up work that will build a stable merge-insertion sort on top of this PR. > > Please take a look and share your thoughts. Thanks very much. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25895 From stefank at openjdk.org Wed Aug 27 17:03:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Aug 2025 17:03:46 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 08:24:59 GMT, Afshin Zafari wrote: >> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. >> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. >> >> Tests: >> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > used CONST64 for all 64-bits const terms. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3160848966 From stefank at openjdk.org Wed Aug 27 17:03:48 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Aug 2025 17:03:48 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 16:10:40 GMT, Coleen Phillimore wrote: >> I hope we will eventually. I'm fine with deferring that to then though, assuming that day ever comes. > > It'd be nice not to have a (another?) -Wsign-conversion error in the file that every file includes though :( This problem is only in the gtest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2304696731 From erikj at openjdk.org Wed Aug 27 17:05:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Aug 2025 17:05:59 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v19] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 16:50:33 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - stuff > - nn make/scripts/update_pch.sh line 101: > 99: mv "$PRECOMPILED_HPP.tmp" "$PRECOMPILED_HPP" > 100: > 101: java /jdk/test/hotspot/jtreg/sources/SortIncludes.java --update /jdk/src/hotspot/share/precompiled This looks like an absolute path. Does that actually work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2304703773 From kvn at openjdk.org Wed Aug 27 17:54:47 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 27 Aug 2025 17:54:47 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 13:47:05 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra 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 remove-abstract_method_handler > - 8365501: Remove speical AdapterHandlerEntry for abstract methods > > Signed-off-by: Ashutosh Mehra src/hotspot/share/oops/method.cpp line 1292: > 1290: } else if (is_abstract()) { > 1291: h_method->_from_compiled_entry = SharedRuntime::get_handle_wrong_method_abstract_stub(); > 1292: } Can you swap conditions? Check is_abstract() first and then (_adapter == nullptr). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26764#discussion_r2304876519 From iveresov at openjdk.org Wed Aug 27 18:04:43 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 27 Aug 2025 18:04:43 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 26 Aug 2025 22:59:54 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Relax verification invariant May I please get approvals for this? @vnkozlov @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/26866#issuecomment-3229203388 From duke at openjdk.org Wed Aug 27 18:06:30 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 18:06:30 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v20] In-Reply-To: References: Message-ID: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: fix absolute path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26681/files - new: https://git.openjdk.org/jdk/pull/26681/files/6693cefe..ead2c779 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26681&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681 PR: https://git.openjdk.org/jdk/pull/26681 From duke at openjdk.org Wed Aug 27 18:06:30 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 27 Aug 2025 18:06:30 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v19] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 17:02:39 GMT, Erik Joelsson wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - stuff >> - nn > > make/scripts/update_pch.sh line 101: > >> 99: mv "$PRECOMPILED_HPP.tmp" "$PRECOMPILED_HPP" >> 100: >> 101: java /jdk/test/hotspot/jtreg/sources/SortIncludes.java --update /jdk/src/hotspot/share/precompiled > > This looks like an absolute path. Does that actually work? My bad, fixed in ead2c779b4481efb06b519924b5e56eeecad3674 That path is only valid in the Docker image where I tested the script, it shouldn't have been there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2304908332 From iklam at openjdk.org Wed Aug 27 18:07:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 18:07:43 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Wed, 27 Aug 2025 09:23:38 GMT, Andrew Dinn wrote: >> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: >> >> >> InstanceKlass* x = ....; >> Klass* s = x->super(); // should call java_super() >> InstanceKlass::cast(s)->xyz(); >> >> >> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: >> >> - `super()` returns `[Ljava/lang/Object;` >> - `java_super()` returns `Ljava/lang/Object;` >> >> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. >> >> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 >> >> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. >> >> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. >> >> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. >> >> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. > > src/hotspot/share/runtime/deoptimization.cpp line 1479: > >> 1477: // Gets the fields of `klass` that are eliminated by escape analysis and need to be reassigned >> 1478: static GrowableArray* get_reassigned_fields(InstanceKlass* klass, GrowableArray* fields, bool is_jvmci) { >> 1479: InstanceKlass* super = klass->java_super(); > > What is wrong with using `superklass()` here? We already know that `klass` is an `InstanceKlass*` so we don't need to make a virtual call to `java_super()`. I got rid of `superklass()` because it was yet another way of looking for a "super" that has no documentation. In this particular case, the cost of a virtual code will be negligible compared to what happens in the following loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26908#discussion_r2304917105 From iklam at openjdk.org Wed Aug 27 18:11:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 18:11:33 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: > We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: > > > InstanceKlass* x = ....; > Klass* s = x->super(); // should call java_super() > InstanceKlass::cast(s)->xyz(); > > > The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: > > - `super()` returns `[Ljava/lang/Object;` > - `java_super()` returns `Ljava/lang/Object;` > > However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. > > See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 > > Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. > > I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. > > I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. > > To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26908/files - new: https://git.openjdk.org/jdk/pull/26908/files/930d6524..074ea8b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26908&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26908&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26908.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26908/head:pull/26908 PR: https://git.openjdk.org/jdk/pull/26908 From ihse at openjdk.org Wed Aug 27 18:11:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 27 Aug 2025 18:11:49 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v20] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > fix absolute path Let's hope it works out this time! :) ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3161184585 From kvn at openjdk.org Wed Aug 27 18:12:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 27 Aug 2025 18:12:46 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 26 Aug 2025 22:59:54 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Relax verification invariant Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26866#pullrequestreview-3161190214 From coleenp at openjdk.org Wed Aug 27 18:22:42 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 18:22:42 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Wed, 27 Aug 2025 18:11:33 GMT, Ioi Lam wrote: >> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: >> >> >> InstanceKlass* x = ....; >> Klass* s = x->super(); // should call java_super() >> InstanceKlass::cast(s)->xyz(); >> >> >> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: >> >> - `super()` returns `[Ljava/lang/Object;` >> - `java_super()` returns `Ljava/lang/Object;` >> >> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. >> >> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 >> >> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. >> >> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. >> >> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. >> >> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp This looks good. We've had several passes of narrowing the Klass types to InstanceKlass so thank you for doing this one. super() is tricky because of array covariance in subtype checking. I don't see that this affects that code. Thank @adinn for finding more. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26908#pullrequestreview-3161236083 From iklam at openjdk.org Wed Aug 27 18:22:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 18:22:43 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: <2HnUt2UzQH-ItShoUc4HI8c3pyh-HJHxYMGsmf2jHHQ=.1a14101d-f662-4820-8ad1-f73d8e22045f@github.com> On Wed, 27 Aug 2025 09:17:31 GMT, Andrew Dinn wrote: > I found two more occurrences of casting super() to InstanceKlass: > > ``` > src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp:79 > > ik = (const InstanceKlass*)ik->super(); > ``` I fixed this one with `java_super()`. Similar to the case in deoptimization.cpp, the cost is dominated by the JavaFieldStream so a virtual call should be fine here. > ```src/hotspot/share/prims/jni.cpp:209 > > intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, int offset) { > if (offset <= small_offset_mask) { > Klass* field_klass = k; > Klass* super_klass = field_klass->super(); > // With compressed oops the most super class with nonstatic fields would > // be the owner of fields embedded in the header. > while (InstanceKlass::cast(super_klass)->has_nonstatic_fields() && > InstanceKlass::cast(super_klass)->contains_field_offset(offset)) { > field_klass = super_klass; // super contains the field also > super_klass = field_klass->super(); > } > ``` Here we have the same logic as in the (removed) `superklass()` function, without any explanation why the cast is safe. The code seems to assume that the incoming `k` parameter cannot be a type such as `[Ljava/lang/String;`. I am not familiar with this code, so I will leave it as is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3229259517 From erikj at openjdk.org Wed Aug 27 18:41:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Aug 2025 18:41:50 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v20] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > fix absolute path Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3161319275 From coleenp at openjdk.org Wed Aug 27 19:30:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 19:30:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com> On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable https://github.com/openjdk/jdk/pull/26971 We do link the class during redefinition, when we load the new classfile version. For the retransformer, we read the classfile from a potentially unlinked class, then link the class after when we do the redefinition/retransformation. To avoid this race, we can link the bytecodes first, I think then we would not have to redo the linking. This change is relatively small as well and does not rely on the implementation of what we lock when we link and initialize the class. I think most of the time, the class is already linked at this stage anyway so it wouldn't have any effect on performance. I didn't try this on your test yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3229490287 From asmehra at openjdk.org Wed Aug 27 19:35:04 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 27 Aug 2025 19:35:04 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Address review comment - swap conditions Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26764/files - new: https://git.openjdk.org/jdk/pull/26764/files/cd8b85f4..eb641188 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26764&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26764&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26764/head:pull/26764 PR: https://git.openjdk.org/jdk/pull/26764 From asmehra at openjdk.org Wed Aug 27 19:35:06 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 27 Aug 2025 19:35:06 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v2] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 17:51:07 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra 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 remove-abstract_method_handler >> - 8365501: Remove speical AdapterHandlerEntry for abstract methods >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/oops/method.cpp line 1292: > >> 1290: } else if (is_abstract()) { >> 1291: h_method->_from_compiled_entry = SharedRuntime::get_handle_wrong_method_abstract_stub(); >> 1292: } > > Can you swap conditions? Check is_abstract() first and then (_adapter == nullptr). Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26764#discussion_r2305119592 From eastigeevich at openjdk.org Wed Aug 27 19:59:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 19:59:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com> References: <3ToXq_Li7f7I0d9-NDZu99y2VeahZaNF2KqS3jIt2_I=.9e625a52-2300-46fc-9f56-b7907c3bfdd5@github.com> Message-ID: On Wed, 27 Aug 2025 19:28:33 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > https://github.com/openjdk/jdk/pull/26971 > > We do link the class during redefinition, when we load the new classfile version. For the retransformer, we read the classfile from a potentially unlinked class, then link the class after when we do the redefinition/retransformation. To avoid this race, we can link the bytecodes first, I think then we would not have to redo the linking. This change is relatively small as well and does not rely on the implementation of what we lock when we link and initialize the class. I think most of the time, the class is already linked at this stage anyway so it wouldn't have any effect on performance. I didn't try this on your test yet. > > This isn't that clear. Now we do: > retransform class -> class reconstitutor to get current classfile version -> VM_RedefineClasses -> load class version with this set of bytecodes -> link bytecodes -> etc. > > My change: > retransform class -> link class -> class reconstitutor to get current classfile version -> etc. Hi @coleenp, Thank you for https://github.com/openjdk/jdk/pull/26971. Don't you mind if we follow the following plan: 1. I pull changes from https://github.com/openjdk/jdk/pull/26971 which fix `RetransformClasses` into this PR. 2. I create a new JBS issues to cover `GetBytecodes`. 3. A separate PR fixing `GetBytecodes` is created. I'd like to have changes for `RetransformClasses` and `GetBytecodes` be in different PRs to simplify backporting processes. IMO fixing `GetBytecodes` is not critical because it is not available for java agents. Only JVMTI agents can use it. We have not seen any bug reports regarding `GetBytecodes`. Regarding `RetransformClasses` we've got reports of crashing 11, 17 and 21 from different customers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3229563219 From coleenp at openjdk.org Wed Aug 27 20:09:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 27 Aug 2025 20:09:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com> On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable You could separate the two if you'd like. I'm running tier1-4 testing on the PR I sent right now. Also, I haven't tried it on your test. Edit again: I don't see your test added to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3229585957 From eosterlund at openjdk.org Wed Aug 27 20:19:46 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Aug 2025 20:19:46 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> On Thu, 14 Aug 2025 20:37:51 GMT, Dean Long wrote: > @fisk , can I get you to review this? Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3229619234 From eastigeevich at openjdk.org Wed Aug 27 21:10:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 27 Aug 2025 21:10:43 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com> References: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com> Message-ID: <4BN2zeKJgyr4Okr4vX2tOqaUGmbYu-g_BmBlwHWcvBI=.e783fcdd-7c30-44ac-bc57-aa658478e170@github.com> On Wed, 27 Aug 2025 20:05:38 GMT, Coleen Phillimore wrote: > I don't see your test added to this PR. You can find a reproducer in https://bugs.openjdk.org/browse/JDK-8277444 with instructions. I don't think it is possible to create a reliable jtreg test. The data race depends on hardware very much. You need delays selected in such a way the retransforming process is going behind the linking process in terms of rewritten bytecodes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3229746413 From kvn at openjdk.org Wed Aug 27 22:57:42 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 27 Aug 2025 22:57:42 GMT Subject: RFR: 8365501: Remove speical AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26764#pullrequestreview-3162033520 From duke at openjdk.org Wed Aug 27 22:58:50 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 27 Aug 2025 22:58:50 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:53:07 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Update for comments Updated for other comments except for renaming `satb`: instead, I added additional explanation to say satb is a single generation GC, as well as generational shenandoah is also an satb gc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26907#issuecomment-3229998019 From wkemper at openjdk.org Wed Aug 27 23:27:47 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 27 Aug 2025 23:27:47 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: References: Message-ID: <2udcEOGskc4rZrFSWmH2mbe_izwpX9MpLunqG0BlVZI=.0a96a637-5726-43f4-88a5-5e56f2828c48@github.com> On Tue, 26 Aug 2025 22:53:07 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Update for comments Changes requested by wkemper (Reviewer). src/java.base/share/man/java.md line 2907: > 2905: [JEP 521](https://openjdk.org/jeps/521) for its advantages and risks. > 2906: > 2907: `-XX:ShenandoahGCHeuristics=`*heuristics* Should probably mention that the generational mode ignores (and now issues a warning) when anything other than `adaptive` is selected. ------------- PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3162122639 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2305543511 From ysr at openjdk.org Wed Aug 27 23:27:47 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 27 Aug 2025 23:27:47 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 22:53:07 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Update for comments One small comment/suggestion. Rest looks good to me. Approving modulo that suggestion. src/java.base/share/man/java.md line 2915: > 2913: `adaptive` > 2914: : To maintain the given amount of free heap at all times, even during > 2915: the GC cycle. May be this part (and in `shenandoah_globals.hpp`) could be changed so as not to repeat the description of `adaptive`, by stating that the default setting is adaptive, but replacing the current description of `adaptive` at line 2914 with the text earlier at line 2909-2911. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3162122472 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2305543383 From ysr at openjdk.org Wed Aug 27 23:27:48 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 27 Aug 2025 23:27:48 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: <2udcEOGskc4rZrFSWmH2mbe_izwpX9MpLunqG0BlVZI=.0a96a637-5726-43f4-88a5-5e56f2828c48@github.com> References: <2udcEOGskc4rZrFSWmH2mbe_izwpX9MpLunqG0BlVZI=.0a96a637-5726-43f4-88a5-5e56f2828c48@github.com> Message-ID: <5e_mdnIR4IrYDWXYGpVBPvxwHw6U3O7_IGzLGW5nmMc=.0e3a77e6-86fb-4b25-86fd-69969e034e30@github.com> On Wed, 27 Aug 2025 23:20:37 GMT, William Kemper wrote: >> Rui Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for comments > > src/java.base/share/man/java.md line 2907: > >> 2905: [JEP 521](https://openjdk.org/jeps/521) for its advantages and risks. >> 2906: >> 2907: `-XX:ShenandoahGCHeuristics=`*heuristics* > > Should probably mention that the generational mode ignores (and now issues a warning) when anything other than `adaptive` is selected. Good point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2305550427 From iklam at openjdk.org Wed Aug 27 23:31:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Aug 2025 23:31:47 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: <7tWS1j21tqFe67Vz86fdjTKNvVfJt09pbNfr2awyy6E=.4fbd1e9c-b27b-4fc7-8b8c-ef9af8a4a6bc@github.com> Message-ID: On Tue, 19 Aug 2025 23:29:46 GMT, Ioi Lam wrote: >> I don't know why you don't fix these together, ie why does this differentiate < 50 classfiles or 50 that failed over to the old verifier? Seems like is_old_class_for_verifier should be both. You might have to set a status flag in the classfile for this though. > > This PR is complicated enough, so I want to fix the `== 50` case in a separate PR. > I will add a test case in this PR to make sure this case is covered. Actually this case is already covered by an existing test that checks for the `"Skipping ...: Verified with old verifier"` log: https://github.com/openjdk/jdk/blob/c5cbcac828e1c7aa845cf16e68f6306ae49e050c/test/hotspot/jtreg/runtime/cds/appcds/aotCache/VerifierFailOver.java#L45-L47 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2305555249 From vaivanov at openjdk.org Thu Aug 28 00:01:54 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 28 Aug 2025 00:01:54 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics Message-ID: Default mode should use OptimizeFill=true option for the SRF platform. ------------- Commit messages: - 8363858 [perf] OptimizeFill may use wide set of intrinsics Changes: https://git.openjdk.org/jdk/pull/26974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26974&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363858 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26974/head:pull/26974 PR: https://git.openjdk.org/jdk/pull/26974 From ysr at openjdk.org Thu Aug 28 00:03:42 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 28 Aug 2025 00:03:42 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v3] In-Reply-To: References: Message-ID: <81sumesHGjskUvlakg0eyq9_etpUwxkqonnwwzDnRqo=.8fdf098b-22d5-4429-a3d2-9b50c8a47056@github.com> On Wed, 27 Aug 2025 23:20:33 GMT, Y. Srinivas Ramakrishna wrote: >> Rui Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for comments > > src/java.base/share/man/java.md line 2915: > >> 2913: `adaptive` >> 2914: : To maintain the given amount of free heap at all times, even during >> 2915: the GC cycle. > > May be this part (and in `shenandoah_globals.hpp`) could be changed so as not to repeat the description of `adaptive`, by stating that the default setting is adaptive, but replacing the current description of `adaptive` at line 2914 with the text earlier at line 2909-2911. @rgithubli correctly pointed out that the description at lines 2909-2911 describes the role of the option, not a description of the `adaptive` heuristic. My comment further above is withdrawn. Please go ahead with what you had (modulo suggestions from other reviewers). Sorry for my confusion! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2305634536 From duke at openjdk.org Thu Aug 28 00:15:58 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 28 Aug 2025 00:15:58 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v4] In-Reply-To: References: Message-ID: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` Rui Li has updated the pull request incrementally with one additional commit since the last revision: gen shen and heuristics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26907/files - new: https://git.openjdk.org/jdk/pull/26907/files/18758749..b319e2b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26907/head:pull/26907 PR: https://git.openjdk.org/jdk/pull/26907 From dholmes at openjdk.org Thu Aug 28 04:22:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 04:22:45 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Wed, 27 Aug 2025 18:10:04 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Relax verification invariant > > Good. > May I please get approvals for this? @vnkozlov @dholmes-ora Sorry @veresov I have no knowledge of the actual `trainingData` code. You will need someone else familiar with Leyden to approve this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26866#issuecomment-3231811527 From duke at openjdk.org Thu Aug 28 04:28:43 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 28 Aug 2025 04:28:43 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v4] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 00:15:58 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > gen shen and heuristics ~/integrate~ Need approval again ------------- PR Comment: https://git.openjdk.org/jdk/pull/26907#issuecomment-3231814685 From iklam at openjdk.org Thu Aug 28 05:03:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 28 Aug 2025 05:03:54 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. 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 five additional commits since the last revision: - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache - @coleenp comments - More bug fixes from JCK testing - Fixed bugs found in JCK testing - 8317269: Store old classes in linked state in AOT cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/e3080281..5ec12352 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=02-03 Stats: 23876 lines in 797 files changed: 14141 ins; 6675 del; 3060 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From dholmes at openjdk.org Thu Aug 28 06:02:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 06:02:47 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v2] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 16:01:41 GMT, Leonid Mesnik wrote: >> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates >> `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` >> to find if method exit normally or by exception. >> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See >> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` >> where post_method_exit_inner is called directly. >> >> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. >> >> >> The fix was a part of >> https://github.com/openjdk/jdk/pull/26713 >> for >> https://bugs.openjdk.org/browse/JDK-8365192 > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > assertion added. Looks good. A few style nits and a couple of suggestions. This will make the other PR much easier to review. Thanks src/hotspot/share/prims/jvmtiExport.cpp line 1843: > 1841: // return a flag when a method terminates by throwing an exception > 1842: // i.e. if an exception is thrown and it's not caught by the current method > 1843: bool exception_exit = state->is_exception_detected() && !state->is_exception_caught(); Can we assert this is not an exception exit please. src/hotspot/share/prims/jvmtiExport.cpp line 1851: > 1849: BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); > 1850: assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, > 1851: "Stack shouldn't be empty"); Suggestion: assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, "Stack shouldn't be empty"); src/hotspot/share/prims/jvmtiExport.cpp line 1864: > 1862: // Deferred transition to VM, so we can stash away the return oop before GC > 1863: // Note that this transition is not needed when throwing an exception, because > 1864: // there is no oop to retain. The comment on lines 1863-1864 is no longer needed. src/hotspot/share/prims/jvmtiExport.cpp line 1867: > 1865: JavaThread* current = thread; // for JRT_BLOCK > 1866: JRT_BLOCK > 1867: post_method_exit_inner(thread, mh, state, false, current_frame, value); Suggestion: post_method_exit_inner(thread, mh, state, false /* not exception exit */, current_frame, value); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/TestMethodExitWithPendingException.java line 27: > 25: * @test > 26: * @summary Test verifies that MethodExit event is correctly posted > 27: * if method is called while there is a pending exception on this thread. Suggestion: * @summary Test verifies that MethodExit event is correctly posted * if method is called while there is a pending exception on this thread. test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 33: > 31: // This method exit callback actually works only for 2 methods: > 32: // 1) for ExceptionExit it verifies that method exit > 33: // has been popped by exception and call 'upCall' mthod using JNI. Suggestion: // has been popped by exception and calls 'upCall' method using JNI. test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 40: > 38: cbMethodExit(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jmethodID method, > 39: jboolean was_popped_by_exception, jvalue return_value) { > 40: const char * mname = get_method_name(jvmti, jni, method); Style nit: please bind the `*` to the type in all pointer declarations e.g. `char* mname` not `char * mname` or `char *mname`. At present all three variants exist in the code. Thanks test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 67: > 65: } > 66: jmethodID upcall_method = jni->GetStaticMethodID(main_class, > 67: "upCall", "()Ljava/lang/String;"); Suggestion: jmethodID upcall_method = jni->GetStaticMethodID(main_class, "upCall", "()Ljava/lang/String;"); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 104: > 102: check_jvmti_error(err, "SetEventCallbacks"); > 103: jvmti_env = jvmti; > 104: return JNI_OK; Suggestion: jvmti_env = jvmti; return JNI_OK; test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 109: > 107: > 108: extern "C" { > 109: JNIEXPORT void JNICALL Suggestion: extern "C" { JNIEXPORT void JNICALL test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 125: > 123: } > 124: > 125: } Suggestion: } // extern "C" ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3163239887 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306237793 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306236038 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306244212 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306236955 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306247384 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306249362 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306260149 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306252496 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306255064 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306256945 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2306257329 From dholmes at openjdk.org Thu Aug 28 06:15:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 06:15:44 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Wed, 27 Aug 2025 18:11:33 GMT, Ioi Lam wrote: >> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: >> >> >> InstanceKlass* x = ....; >> Klass* s = x->super(); // should call java_super() >> InstanceKlass::cast(s)->xyz(); >> >> >> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: >> >> - `super()` returns `[Ljava/lang/Object;` >> - `java_super()` returns `Ljava/lang/Object;` >> >> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. >> >> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 >> >> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. >> >> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. >> >> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. >> >> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp FWIW `jfieldIDWorkaround::encode_klass_hash` does seem to end up getting called only when `k` is an `instanceKlass` but we should file a cleanup RFE to change the parameter type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3232037750 From dholmes at openjdk.org Thu Aug 28 06:30:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 06:30:44 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: <07yVlpKBMdroXvulj1FzthjyfDLTs3IVCI_eDfors1c=.7a014107-e49f-4248-aa58-4def5040cab2@github.com> On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Thanks for all the reviews. I was contemplating withdrawing this as it has inspired Kim Barrett to work on an `AtomicValue` API (name may change) which makes this precise guidance moot most of the time. However, this added section can be used to document the need to use `AtomicValue` and there may be times use of `AtomicValue` is not applicable/appropriate. @kvn could you please approve if you believe sufficient consensus exists for this. Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26934#issuecomment-3232097042 From mbaesken at openjdk.org Thu Aug 28 07:25:42 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 28 Aug 2025 07:25:42 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 19 Aug 2025 00:11:38 GMT, David Holmes wrote: > `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. > > Testing: > - tiers 1-3 sanity > > Thanks Hi David, with your PR added, I do not see the issue any more in our asan - tests (jtreg and some others) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3232262168 From azafari at openjdk.org Thu Aug 28 07:54:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 28 Aug 2025 07:54:48 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 17:00:26 GMT, Stefan Karlsson wrote: >> It'd be nice not to have a (another?) -Wsign-conversion error in the file that every file includes though :( > > This problem is only in the gtest. So, I let it be as it is now. In future the warning here reminds us where to look again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2306542487 From duke at openjdk.org Thu Aug 28 08:23:50 2025 From: duke at openjdk.org (duke) Date: Thu, 28 Aug 2025 08:23:50 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v20] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > fix absolute path @fandreuz Your change (at version ead2c779b4481efb06b519924b5e56eeecad3674) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3232453034 From aboldtch at openjdk.org Thu Aug 28 08:51:48 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 08:51:48 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> On Wed, 27 Aug 2025 11:24:07 GMT, Afshin Zafari wrote: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 I agree with Johan that we cast this to a pointer to early. I much prefer `uintptr_t` rather than `char*` when doing byte sized pointer arithmetic on values which represent address which are not supposed to be dereferenced. In this particular instance, in `HeapReserver::Instance::reserve_compressed_oops_heap` we might want to read `HeapBaseMinAddress` as: ```C++ uintptr_t aligned_heap_base_min_address = align_up(MAX2(HeapBaseMinAddress, alignment), alignment); Because `aligned_heap_base_min_address` is used later directly as an address. (We might instead want to propagate non pointer types further, but it will be a larger refactoring that is probably not suitable for this rfe). Regardless I feel like we should not change the public "API" of HeapBaseMinAddress in a bug fix, I would rather we simply treat the value of HeapBaseMinAddress as a heap base minimum address and use it as a lower bound. No OS we run on (afaik) will let us reserve an address space where 0 can be dereferenced. I also wonder how we got here with `HeapBaseMinAddress == 0` as we set the value back to the default if it is lower when using compressed oops (in `Arguments::set_heap_size()`). And I think the default is 2G on all platforms. _There seems to be a lot of pre-existing weirdness / corner cases in this code_ ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3232561871 From duke at openjdk.org Thu Aug 28 09:12:53 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 28 Aug 2025 09:12:53 GMT Subject: RFR: 8366331: Sort share/prims includes Message-ID: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. Passes `tier1`. ------------- Commit messages: - sort and delete Changes: https://git.openjdk.org/jdk/pull/26980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366331 Stats: 72 lines in 26 files changed: 31 ins; 39 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26980/head:pull/26980 PR: https://git.openjdk.org/jdk/pull/26980 From cnorrbin at openjdk.org Thu Aug 28 09:17:06 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 28 Aug 2025 09:17:06 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. Message-ID: Hi everyone, The current red-black tree can be made safer, and its inspection capabilities improved. As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. ------------- Commit messages: - rbtree better cmp and verify/print user functions Changes: https://git.openjdk.org/jdk/pull/26981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366238 Stats: 258 lines in 7 files changed: 159 ins; 8 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/26981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981 PR: https://git.openjdk.org/jdk/pull/26981 From shade at openjdk.org Thu Aug 28 09:27:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Aug 2025 09:27:53 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v20] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 18:06:30 GMT, Francesco Andreuzzi wrote: >> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. >> >> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. >> >> >> linux-x64 GCC >> master real 81.39 user 3352.15 sys 287.49 >> JDK-8365053 real 81.94 user 3030.24 sys 295.82 >> >> linux-x64 Clang >> master real 43.44 user 2082.93 sys 130.70 >> JDK-8365053 real 38.44 user 1723.80 sys 117.68 >> >> linux-aarch64 GCC >> master real 1188.08 user 2015.22 sys 175.53 >> JDK-8365053 real 1019.85 user 1667.45 sys 171.86 >> >> linux-aarch64 clang >> master real 981.77 user 1645.05 sys 118.60 >> JDK-8365053 real 791.96 user 1262.92 sys 101.50 > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > fix absolute path Marked as reviewed by shade (Reviewer). I re-ran the script locally on my Mac, and I think it works without hitches now. There seems to be a tiny bit of variability for generated `precompiled.hpp`, since timing measurements are not exactly precise or consistent across build platforms. But IMO it is not worth diving deeper into. The build times are still improving, as I tested earlier. So, great work all around here, folks. Kudos Francesco for trying multiple approaches and working out the great one! I think we are good to go. If we need any other changes, we can do them as follow-ups. ------------- PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3164025632 PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3232687434 From duke at openjdk.org Thu Aug 28 09:32:13 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 28 Aug 2025 09:32:13 GMT Subject: Integrated: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi wrote: > In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency. > > These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds. > > > linux-x64 GCC > master real 81.39 user 3352.15 sys 287.49 > JDK-8365053 real 81.94 user 3030.24 sys 295.82 > > linux-x64 Clang > master real 43.44 user 2082.93 sys 130.70 > JDK-8365053 real 38.44 user 1723.80 sys 117.68 > > linux-aarch64 GCC > master real 1188.08 user 2015.22 sys 175.53 > JDK-8365053 real 1019.85 user 1667.45 sys 171.86 > > linux-aarch64 clang > master real 981.77 user 1645.05 sys 118.60 > JDK-8365053 real 791.96 user 1262.92 sys 101.50 This pull request has now been integrated. Changeset: a5a23400 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/a5a234005414a58f66c7e646a8f9b0042e9f9eec Stats: 161 lines in 3 files changed: 115 ins; 39 del; 7 mod 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency Reviewed-by: shade, ihse, erikj, qamai ------------- PR: https://git.openjdk.org/jdk/pull/26681 From jsikstro at openjdk.org Thu Aug 28 09:32:46 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 28 Aug 2025 09:32:46 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin wrote: > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. The changes to ZGC looks OK. Thank you for this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3232716188 From duke at openjdk.org Thu Aug 28 09:35:24 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 28 Aug 2025 09:35:24 GMT Subject: RFR: 8366331: Sort share/prims includes [v2] In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: > This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes `tier1`. Francesco Andreuzzi 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 JDK-8366331 - sort and delete ------------- Changes: https://git.openjdk.org/jdk/pull/26980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=01 Stats: 72 lines in 26 files changed: 31 ins; 39 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26980/head:pull/26980 PR: https://git.openjdk.org/jdk/pull/26980 From shade at openjdk.org Thu Aug 28 09:38:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Aug 2025 09:38:43 GMT Subject: RFR: 8366331: Sort share/prims includes [v2] In-Reply-To: References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 09:35:24 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes `tier1`. > > Francesco Andreuzzi 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 JDK-8366331 > - sort and delete Looks fine with minor nit. src/hotspot/share/prims/foreignGlobals.cpp line 25: > 23: > 24: #include "classfile/javaClasses.hpp" > 25: #include "foreignGlobals.hpp" This does not look right, even in the original code. Isn't it the same as `prims/foreignGlobals.hpp`, which is subsumed by the existing `prims/foreignGlobals.inline.hpp`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3164054837 PR Review Comment: https://git.openjdk.org/jdk/pull/26980#discussion_r2306829785 From ayang at openjdk.org Thu Aug 28 09:43:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 28 Aug 2025 09:43:48 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin wrote: > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. > > Testing: > - Oracle tiers 1-3 src/hotspot/share/gc/z/zMappedCache.cpp line 121: > 119: } > 120: > 121: bool ZMappedCache::EntryCompare::less(const IntrusiveRBNode* a, const IntrusiveRBNode* b) { I feel `less_than` sounds more natural as a method name; it also avoids "conflicting" with `RBTreeOrdering::less`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306853612 From aboldtch at openjdk.org Thu Aug 28 09:46:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 28 Aug 2025 09:46:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <98TT8Dv88wv5zq2bm2mvAN80JlwICKKHZ8QVfeA414A=.87ac3000-9705-480f-aa8c-d24a27439391@github.com> Message-ID: On Thu, 28 Aug 2025 08:49:06 GMT, Axel Boldt-Christmas wrote: >I also wonder how we got here with HeapBaseMinAddress == 0 as we set the value back to the default if it is lower when using compressed oops (in Arguments::set_heap_size()). And I think the default is 2G on all platforms. I realise now that this is based on if we have set the max heap explicitly. So we can end up with 0 as the lower bound in `try_reserve_range` which will cause us to request "any address", which seems like another bug. (Making sure `aligned_heap_base_min_address != 0` fixes this here, but `try_reserve_range` should probably guard agains having an `attach_point` which is 0 or a `lowest_start` which is 0.) While experimenting with the flags I notice we do not protect against overflow in the reservation code so setting a high `HeapBaseMinAddress` will crash. And it is not captured by `TestOptionsWithRanges` because it cannot understand our constraint function and will only try SIZE_MAX, but we only allow SIZE_MAX aligned down to our alignment. Regardless seems like this code is crawling with bugs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3232761537 From cnorrbin at openjdk.org Thu Aug 28 09:58:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 28 Aug 2025 09:58:43 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: renamed less to less_than ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26981/files - new: https://git.openjdk.org/jdk/pull/26981/files/f386a71e..9dd20dbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=00-01 Stats: 16 lines in 5 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981 PR: https://git.openjdk.org/jdk/pull/26981 From cnorrbin at openjdk.org Thu Aug 28 09:58:44 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 28 Aug 2025 09:58:44 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v2] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 09:40:48 GMT, Albert Mingkun Yang wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed less to less_than > > src/hotspot/share/gc/z/zMappedCache.cpp line 121: > >> 119: } >> 120: >> 121: bool ZMappedCache::EntryCompare::less(const IntrusiveRBNode* a, const IntrusiveRBNode* b) { > > I feel `less_than` sounds more natural as a method name; it also avoids "conflicting" with `RBTreeOrdering::less`. Sounds like a good suggestion, done now in 9dd20db ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306891336 From ayang at openjdk.org Thu Aug 28 10:00:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 28 Aug 2025 10:00:46 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: <1pt62qKytUcjtapK7hlHM4cqQJ7Z0Vcy3SAvqNnkNwo=.759c5a9c-33f9-4a2e-942c-cb1011470215@github.com> On Wed, 27 Aug 2025 08:52:28 GMT, Francesco Andreuzzi wrote: > I was wondering, would it be possible to explicitly set padding fields with default value zero? I was thinking the same -- seems to me it's better to list padding explicitly as fields if its content is significant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3232813630 From ayang at openjdk.org Thu Aug 28 10:35:43 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 28 Aug 2025 10:35:43 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v2] In-Reply-To: References: Message-ID: <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com> On Thu, 28 Aug 2025 09:58:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current red-black tree can be made safer, and its inspection capabilities improved. >> >> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. >> >> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. >> >> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. >> >> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. >> >> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > renamed less to less_than I noticed that in one place (parent_cmp <= 0 && hint_cmp < 0) becomes (parent_cmp != RBTreeOrdering::greater && hint_cmp == RBTreeOrdering::less) I wonder if compare-result can have some helper apis so that the new code looks like (parent_cmp.is_less_equal() && hint_cmp.is_less()) Can't say for sure one is definitely better than the other; just throwing out some ideas. src/hotspot/share/nmt/vmatree.hpp line 56: > 54: if (a < b) return RBTreeOrdering::less; > 55: if (a == b) return RBTreeOrdering::equal; > 56: if (a > b) return RBTreeOrdering::greater; Preexisting: no need for 3 `if`s, can be identical to the impl in `printinlining.hpp`. src/hotspot/share/utilities/rbTree.hpp line 217: > 215: > 216: template > 217: static constexpr bool HasNodeVerifier = has_less_type::value; Does this need to be `has_less_than_type`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3164179820 PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306922430 PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306982476 From cnorrbin at openjdk.org Thu Aug 28 11:21:00 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 28 Aug 2025 11:21:00 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: References: Message-ID: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: albert feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26981/files - new: https://git.openjdk.org/jdk/pull/26981/files/9dd20dbe..f780a53e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981 PR: https://git.openjdk.org/jdk/pull/26981 From cnorrbin at openjdk.org Thu Aug 28 11:34:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 28 Aug 2025 11:34:43 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v2] In-Reply-To: <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com> References: <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com> Message-ID: On Thu, 28 Aug 2025 10:32:41 GMT, Albert Mingkun Yang wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed less to less_than > > I noticed that in one place > > > (parent_cmp <= 0 && hint_cmp < 0) > > becomes > > (parent_cmp != RBTreeOrdering::greater && hint_cmp == RBTreeOrdering::less) > > > I wonder if compare-result can have some helper apis so that the new code looks like > > (parent_cmp.is_less_equal() && hint_cmp.is_less()) > > > Can't say for sure one is definitely better than the other; just throwing out some ideas. Thank you for the review @albertnetymk. > I wonder if compare-result can have some helper apis so that the new code looks like > > ``` > (parent_cmp.is_less_equal() && hint_cmp.is_less()) > ``` Unfortunately, we can't add helpers directly to the `enum class`, so we'd have to either 1. Wrap it in another struct or class, or 2. Add a separate set of functions (e.g. `is_less(order)` or `is_less_equal(order)`) Either option introduces extra code for something that's only used internally in the tree in a couple of places. For now, the explicit comparisons is (to me) readable enough, so I'd prefer to keep it as is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3233127699 From roland at openjdk.org Thu Aug 28 12:01:42 2025 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 28 Aug 2025 12:01:42 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 23:56:40 GMT, Vladimir Ivanov wrote: > Default mode should use OptimizeFill=true option for the SRF platform. Looks good to me. ------------- Marked as reviewed by roland (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26974#pullrequestreview-3164557089 From adinn at openjdk.org Thu Aug 28 12:18:45 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 28 Aug 2025 12:18:45 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 08:52:28 GMT, Francesco Andreuzzi wrote: >> [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. >> >> This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. > > Hi @iklam, thanks for the explanation. I was wondering, would it be possible to explicitly set padding fields with default value zero? Something like this: > > u8 padding1; > #ifdef _LP64 > u32 padding2; > #endif > > so we could use the default constructor, like I'm doing in #26818. @fandreuz @albertnetymk The problem with requiring the use of padding fields is that it is fragile. Changing a type definition might easily reintroduce the archive comparison problem and also inadvertently increase allocation sizes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3233266473 From dfenacci at openjdk.org Thu Aug 28 12:53:50 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 28 Aug 2025 12:53:50 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <9iBtnO_hxp-QvkyRZ1niOCD3wmMnglEjnFM8Ou-SD1I=.3c932276-2f23-4e21-89b0-15fa70ae5bc0@github.com> On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks good! Thanks @ruben-arm! ------------- Marked as reviewed by dfenacci (Committer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3164727578 From duke at openjdk.org Thu Aug 28 12:53:51 2025 From: duke at openjdk.org (Ruben) Date: Thu, 28 Aug 2025 12:53:51 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <9FksTnxNMXj06CDhAxmz9x-yFbsVIRE44pMexHHnINc=.966acc2b-486a-40f5-9b2a-d7236578c92a@github.com> On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I've discovered an issue caused by the current version of the patch - at least for AArch32. Once the exception handler stub code is removed, the deoptimization handler stub code can become adjacent to the main code. Occasionally the main code ends with a `BL` which is never meant to return. That `BL` - if adjacent to the stub code - writes the address of the deoptimization stub code into `LR`, causing an issue for subsequent frame processing, as the design assumption is: if a return address points to the deoptimization stub code, then deoptimization is in progress. For this to apply, there should be no call instructions right before the deoptimization stub code. Presumably, the most straightforward fix could be to emit a `NOP` at the end of the main code if otherwise a `BL`/`BLR` would be the last instruction there. I'd appreciate feedback on whether this approach is acceptable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3233380061 From dholmes at openjdk.org Thu Aug 28 12:54:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Aug 2025 12:54:43 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Thu, 28 Aug 2025 07:23:06 GMT, Matthias Baesken wrote: >> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > Hi David, with your PR added, I do not see the issue any more in our asan - tests (jtreg and some others) . @MBaesken thanks for verifying that. Unfortunately I need to revise the fix to avoid the actual deletion ... which I think will look messy as I have to execute the destructor code without using a destructor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3233381277 From duke at openjdk.org Thu Aug 28 13:01:37 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 28 Aug 2025 13:01:37 GMT Subject: RFR: 8366331: Sort share/prims includes [v3] In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: > This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes `tier1`. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: nn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26980/files - new: https://git.openjdk.org/jdk/pull/26980/files/d80d6764..b0d16339 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26980&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26980/head:pull/26980 PR: https://git.openjdk.org/jdk/pull/26980 From duke at openjdk.org Thu Aug 28 13:01:39 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 28 Aug 2025 13:01:39 GMT Subject: RFR: 8366331: Sort share/prims includes [v3] In-Reply-To: References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 09:31:42 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> nn > > src/hotspot/share/prims/foreignGlobals.cpp line 25: > >> 23: >> 24: #include "classfile/javaClasses.hpp" >> 25: #include "foreignGlobals.hpp" > > This does not look right, even in the original code. Isn't it the same as `prims/foreignGlobals.hpp`, which is subsumed by the existing `prims/foreignGlobals.inline.hpp`? Right, removed in b0d163391270189772939ef2849e45dbf5963063 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26980#discussion_r2307338536 From adinn at openjdk.org Thu Aug 28 13:04:47 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 28 Aug 2025 13:04:47 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: <9FksTnxNMXj06CDhAxmz9x-yFbsVIRE44pMexHHnINc=.966acc2b-486a-40f5-9b2a-d7236578c92a@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <9FksTnxNMXj06CDhAxmz9x-yFbsVIRE44pMexHHnINc=.966acc2b-486a-40f5-9b2a-d7236578c92a@github.com> Message-ID: On Thu, 28 Aug 2025 12:51:27 GMT, Ruben wrote: > Presumably, the most straightforward fix could be to emit a NOP at the end of the main code if otherwise a BL/BLR would be the last instruction there. I'd appreciate feedback on whether this approach is acceptable. Wow, that's a bizarre bug. Maybe better might be to generate an illegal instruction rather than a nop but a nop would probably do. @ruben-arm BTW, what exactly do you mean by 'the main code'? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3233407524 PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3233417095 From lkorinth at openjdk.org Thu Aug 28 13:05:51 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 28 Aug 2025 13:05:51 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race wrote: > > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values. > > I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it. > > I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete. I will revert this change. Thanks for finding it. I think the timeout was found in a local run with a timeout factor of 0.5 and a local fix to "CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE". CI history tells me that the run time of the test is stable and that we have a margin. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2307351823 From lkorinth at openjdk.org Thu Aug 28 13:12:45 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 28 Aug 2025 13:12:45 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: - revert added timeout, it is not needed - feedback from Mark Sheppard ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/f24a1e72..365454d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=04-05 Stats: 62 lines in 41 files changed: 3 ins; 0 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From lkorinth at openjdk.org Thu Aug 28 13:12:46 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 28 Aug 2025 13:12:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > update testing.md, remove makefile link, fix bad text I have added some updates. I will try to merge latest, update copyrights and run tests over the weekend. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3233444166 From ayang at openjdk.org Thu Aug 28 13:21:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 28 Aug 2025 13:21:47 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> References: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> Message-ID: On Thu, 28 Aug 2025 11:21:00 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current red-black tree can be made safer, and its inspection capabilities improved. >> >> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. >> >> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. >> >> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. >> >> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. >> >> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > albert feedback Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3164838757 From duke at openjdk.org Thu Aug 28 13:34:44 2025 From: duke at openjdk.org (Ruben) Date: Thu, 28 Aug 2025 13:34:44 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <9FksTnxNMXj06CDhAxmz9x-yFbsVIRE44pMexHHnINc=.966acc2b-486a-40f5-9b2a-d7236578c92a@github.com> Message-ID: On Thu, 28 Aug 2025 13:02:33 GMT, Andrew Dinn wrote: >>> Looks good! Thanks @ruben-arm! >> >> Thank you @dafedafe. >> >> In the meantime, I realized the AArch32 tests weren't run during my testing earlier - and attempted running them. I found that many of the tests are failing without this patch. Nevertheless, I noticed that more tests are failing with this patch. I've just identified the root cause - described below. This issue is caused by the current version of the patch - at least for AArch32. >> >> Once the exception handler stub code is removed, the deoptimization handler stub code can become adjacent to the main code. Occasionally the main code ends with a `BL` which is never meant to return. That `BL` - if adjacent to the stub code - writes the address of the deoptimization stub code into `LR`, causing an issue for subsequent frame processing, as the design assumption is: if a return address points to the deoptimization stub code, then deoptimization is in progress. >> For this to apply, there should be no call instructions right before the deoptimization stub code. >> >> Presumably, the most straightforward fix could be to emit a `NOP` at the end of the main code if otherwise a `BL`/`BLR` would be the last instruction there. I'd appreciate feedback on whether this approach is acceptable. > > @ruben-arm BTW, what exactly do you mean by 'the main code'? @adinn By the "main code" I mean the region of an `nmethod` between the entry point and the `nmethod`'s stub code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3233523971 From kvn at openjdk.org Thu Aug 28 14:33:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 28 Aug 2025 14:33:46 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: <4a1tuJAWRWPM-QXXL7bW0mAJspq02ii8d2TcNhWicy4=.a6c0709d-8b2c-4686-a73d-77c53f85299e@github.com> On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3165128716 From shade at openjdk.org Thu Aug 28 14:50:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Aug 2025 14:50:44 GMT Subject: RFR: 8366331: Sort share/prims includes [v3] In-Reply-To: References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes `tier1`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > nn This looks fine to me, thanks. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3165215879 From asmehra at openjdk.org Thu Aug 28 15:00:45 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 28 Aug 2025 15:00:45 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra New test failure java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java#id0 on macos-aarch64: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000103bf9bbc, pid=12937, tid=29447 # # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-ashu-mehra-eb641188b3a0c241d95292a834404958c3e4e5dd) # Java VM: OpenJDK 64-Bit Server VM (26-internal-ashu-mehra-eb641188b3a0c241d95292a834404958c3e4e5dd, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # V [libjvm.dylib+0x2f5bbc] void StackChunkFrameStream<(ChunkFrames)1>::next(RegisterMap*, bool)+0xbc # ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3233848145 From ayang at openjdk.org Thu Aug 28 15:33:50 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 28 Aug 2025 15:33:50 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 12:16:34 GMT, Andrew Dinn wrote: > ... that it is fragile. Currently, an instance allocated on the stack can contain random bit and one needs to use copy-constructor/`coping_from` to clean it up seems also fragile, or even confusing that these two instances are not identical. > Changing a type definition might easily reintroduce the archive comparison problem You mean adding/removing fields can cause the `sizeof(ResolvedFieldEntry)` != sum of `sizeof(field)`? If so, how about having an static_assert to verify there is no padding? Since the bitwise memory content of this instance is significant, I think it's critical that we express that intention in the code -- there should not be any hole/padding inside `ResolvedFieldEntry`. > also inadvertently increase allocation sizes Since the padding is meant to fill the holes needed for alignment, I don't think it will/should change `sizeof(ResolvedFieldEntry)`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3233539064 From adinn at openjdk.org Thu Aug 28 15:33:51 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 28 Aug 2025 15:33:51 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 13:36:36 GMT, Albert Mingkun Yang wrote: >> @fandreuz @albertnetymk The problem with requiring the use of padding fields is that it is fragile. Changing a type definition might easily reintroduce the archive comparison problem and also inadvertently increase allocation sizes. > >> ... that it is fragile. > > Currently, an instance allocated on the stack can contain random bit and one needs to use copy-constructor/`coping_from` to clean it up seems also fragile, or even confusing that these two instances are not identical. > >> Changing a type definition might easily reintroduce the archive comparison problem > > You mean adding/removing fields can cause the `sizeof(ResolvedFieldEntry)` != sum of `sizeof(field)`? If so, how about having an static_assert to verify there is no padding? Since the bitwise memory content of this instance is significant, I think it's critical that we express that intention in the code -- there should not be any hole/padding inside > `ResolvedFieldEntry`. > >> also inadvertently increase allocation sizes > > Since the padding is meant to fill the holes needed for alignment, I don't think it will/should change `sizeof(ResolvedFieldEntry)`. @albertnetymk Perhaps I was not very clear but I think you may have misunderstood what I was trying to say. You are suggesting that we add padding bytes, shorts and/or words to structs in order to ensure that the 'payload size' (i.e. the storage needed to accommodate all the fields in declared order) is equal to the allocation size (i.e. some multiple of 4 bytes on 32 bit or 8 bytes on 64 bit). Depending on the mismatch between those two sizes we may need one or more such pad fields. The problem I foresee is that it is very easy for a developer to make changes to the structure content or layout and either forget to adjust the padding size or adjust it incorrectly. That is what I am describing as fragile. The consequences of getting it wrong could be 1) to recreate the archive reproduceability issue when dumping objects into CDS archives and/or 2) to end up with padding that crosses rather than runs up to a 4/8 byte boundary (which would unnecessarily increase the allocation size). In the worst case we could get both. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3233988746 From duke at openjdk.org Thu Aug 28 15:35:56 2025 From: duke at openjdk.org (duke) Date: Thu, 28 Aug 2025 15:35:56 GMT Subject: Withdrawn: 8357579: Compilation error: first argument in call to 'memset' is a pointer to non-trivially copyable type In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 16:29:27 GMT, Jan Kratochvil wrote: > With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like: > > src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall] > 49 | memset(this, 0, sizeof(*this)); > | ^ > src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning > 49 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > > The patch follows the suggested fix. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26098 From adinn at openjdk.org Thu Aug 28 15:55:44 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 28 Aug 2025 15:55:44 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <9FksTnxNMXj06CDhAxmz9x-yFbsVIRE44pMexHHnINc=.966acc2b-486a-40f5-9b2a-d7236578c92a@github.com> Message-ID: On Thu, 28 Aug 2025 13:32:18 GMT, Ruben wrote: >> @ruben-arm BTW, what exactly do you mean by 'the main code'? > > @adinn By the "main code" I mean the region of an `nmethod` between the entry point and the `nmethod`'s stub code. @ruben-arm Ok, so the problem you are describing is when the nmethod code section ends with a `br` that is not supposed to return. By accident `lr` is left pointing to the first instruction in the stubs section. Some code checks `lr` and decides we are doing a deopt even though this is really just some other type of call. Where is the code that checks the address in lr? I'd like to understand what it is that the checking code dislikes just in case there is a wider problem here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3234057765 From duke at openjdk.org Thu Aug 28 16:29:44 2025 From: duke at openjdk.org (Ruben) Date: Thu, 28 Aug 2025 16:29:44 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments One of these checks is at `frame::get_deopt_original_pc` - based on the result `frame::setup` determines whether a deoptimization is in progress. - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/share/runtime/frame.inline.hpp#L74-L82 - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.inline.hpp#L114-L130 There is also a similar check - specifically for AArch32 - to determine value of `SP` at `frame::adjust_unextended_sp` which wouldn't be affected by the specific issue (at least in `release` build) because it compares with the special case of deoptimization handler stub code used for `MethodHandle` call sites. - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.cpp#L356-L381 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3234169197 From lmesnik at openjdk.org Thu Aug 28 16:41:56 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 28 Aug 2025 16:41:56 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v3] In-Reply-To: References: Message-ID: <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com> > The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates > `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` > to find if method exit normally or by exception. > However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See > `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` > where post_method_exit_inner is called directly. > > The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. > > > The fix was a part of > https://github.com/openjdk/jdk/pull/26713 > for > https://bugs.openjdk.org/browse/JDK-8365192 Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: - Apply suggestions from code review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - comment fixed - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937 - assertion added. - more comments in the test - fixed ident - bugid fixed: - updated to fix 8365937 - fixed comment. - test renamed. - ... and 17 more: https://git.openjdk.org/jdk/compare/dad9fd8a...4e05639a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26886/files - new: https://git.openjdk.org/jdk/pull/26886/files/d9319d90..4e05639a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=01-02 Stats: 6761 lines in 321 files changed: 3177 ins; 2467 del; 1117 mod Patch: https://git.openjdk.org/jdk/pull/26886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26886/head:pull/26886 PR: https://git.openjdk.org/jdk/pull/26886 From lmesnik at openjdk.org Thu Aug 28 16:41:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 28 Aug 2025 16:41:57 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v3] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 05:41:20 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: >> >> - Apply suggestions from code review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - comment fixed >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937 >> - assertion added. >> - more comments in the test >> - fixed ident >> - bugid fixed: >> - updated to fix 8365937 >> - fixed comment. >> - test renamed. >> - ... and 17 more: https://git.openjdk.org/jdk/compare/dad9fd8a...4e05639a > > src/hotspot/share/prims/jvmtiExport.cpp line 1843: > >> 1841: // return a flag when a method terminates by throwing an exception >> 1842: // i.e. if an exception is thrown and it's not caught by the current method >> 1843: bool exception_exit = state->is_exception_detected() && !state->is_exception_caught(); > > Can we assert this is not an exception exit please. I am not sure what to check here. The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2307942708 From adinn at openjdk.org Thu Aug 28 17:05:53 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 28 Aug 2025 17:05:53 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <4BedMjEytXAf_-uB-OKbrIPT_WqmIb7wIrrxZIPUerU=.6827b5d3-2b32-4046-b74e-417f4f47f7e9@github.com> On Thu, 28 Aug 2025 16:27:15 GMT, Ruben wrote: >> Ruben has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > One of these checks is at `frame::get_deopt_original_pc` - based on the result `frame::setup` determines whether a deoptimization is in progress. > - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/share/runtime/frame.inline.hpp#L74-L82 > - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.inline.hpp#L114-L130 > > There is also a similar check - specifically for AArch32 - to determine value of `SP` at `frame::adjust_unextended_sp` which wouldn't be affected by the specific issue (at least in `release` build) because it compares with the special case of deoptimization handler stub code used for `MethodHandle` call sites. > - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.cpp#L356-L381 @ruben-arm Ah ok, so I guess that's not really just an arm bug then. Previously we always had an exception handler between the end of the code and the deopt handler so the latter could never immediately follow an end-of-code-section call. However, now that we are omitting the exception handler this could happen on any architecture. Which means that shared method `frame::get_deopt_original_pc()` is now no longer reliable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3234269135 From ysr at openjdk.org Thu Aug 28 17:48:43 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 28 Aug 2025 17:48:43 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v4] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 00:15:58 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > gen shen and heuristics Approved modulo a comment. I also think we should to the extent possible make the listing of text common to man page and options list consistent. An example is the recent improvement you made in your most recent update to the man page for the heuristics option. There may be other changes to the man page that came about as a result of this review. It would make sense to make those changes, where applicable, also to shenandoah_globals. This latter need not hold up this ticket but can be addressed separately in a follow up. src/java.base/share/man/java.md line 2914: > 2912: > 2913: Possible heuristics are the following (when `-XX:ShenandoahGCMode` is > 2914: `generational`, the only supported option is the default, `adaptive`): Move the parenthetic part to the previous paragraph and out of parentheses. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3165915632 PR Review Comment: https://git.openjdk.org/jdk/pull/26907#discussion_r2308123862 From shade at openjdk.org Thu Aug 28 18:08:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Aug 2025 18:08:46 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v4] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 00:15:58 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > gen shen and heuristics Make sure that someone outside Shenandoah devs looks at this patch to sanity check how it reads. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26907#issuecomment-3234456656 From iklam at openjdk.org Thu Aug 28 18:11:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 28 Aug 2025 18:11:51 GMT Subject: RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: <-3ubfdrNYgRkPEQqxDEcQ3bawHZxFdskhQ4YgNSEgPg=.d6760842-0aa3-45a3-9140-d27067a3800d@github.com> References: <-3ubfdrNYgRkPEQqxDEcQ3bawHZxFdskhQ4YgNSEgPg=.d6760842-0aa3-45a3-9140-d27067a3800d@github.com> Message-ID: On Wed, 27 Aug 2025 12:40:02 GMT, Coleen Phillimore wrote: >> [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. >> >> This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. > > This comment is helpful. At one point, I made Metaspace::allocate not zero memory and several things broke. This would have been one of them it if existed. I don't know if there's a better solution to to ensuring alignment gaps in fields always zeroed. Thanks @coleenp and @adinn for the review. I am pushing this PR to add comments on the existing code. Please continue discussion about any potential improvements (but perhaps in a different PR/email?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3234462302 From iklam at openjdk.org Thu Aug 28 18:11:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 28 Aug 2025 18:11:51 GMT Subject: Integrated: 8366193: Add comments about ResolvedFieldEntry::copy_from() In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 16:53:17 GMT, Ioi Lam wrote: > [JDK-8293980](https://bugs.openjdk.org/browse/JDK-8293980) added `ResolvedFieldEntry::copy_from()` to prevent random bits in the CDS archive. However, I forgot to add a comment to explain why this is necessary. > > This PR adds the missing comment, which will be useful if we consider alternative solutions (using `memset()` in constructor??) in the future. This pull request has now been integrated. Changeset: 9f70965b Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/9f70965bb9ead2268c02c688c79ec0d80574c725 Stats: 36 lines in 3 files changed: 33 ins; 0 del; 3 mod 8366193: Add comments about ResolvedFieldEntry::copy_from() Reviewed-by: adinn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/26946 From lmesnik at openjdk.org Thu Aug 28 18:35:43 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 28 Aug 2025 18:35:43 GMT Subject: RFR: 8366331: Sort share/prims includes [v3] In-Reply-To: References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes `tier1`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > nn Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26980#pullrequestreview-3166072469 From duke at openjdk.org Thu Aug 28 18:44:26 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 28 Aug 2025 18:44:26 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v5] In-Reply-To: References: Message-ID: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` Rui Li has updated the pull request incrementally with one additional commit since the last revision: Add shen hpp changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26907/files - new: https://git.openjdk.org/jdk/pull/26907/files/b319e2b9..cbf1819a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=03-04 Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26907/head:pull/26907 PR: https://git.openjdk.org/jdk/pull/26907 From duke at openjdk.org Thu Aug 28 19:08:45 2025 From: duke at openjdk.org (duke) Date: Thu, 28 Aug 2025 19:08:45 GMT Subject: RFR: 8366331: Sort share/prims includes [v3] In-Reply-To: References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 13:01:37 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes `tier1`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > nn @fandreuz Your change (at version b0d163391270189772939ef2849e45dbf5963063) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26980#issuecomment-3234629431 From wkemper at openjdk.org Thu Aug 28 19:13:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 28 Aug 2025 19:13:58 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v5] In-Reply-To: References: Message-ID: <_rKk-r34my2_ZEQQjyGlDeitw522D1qJam7UouvwPj4=.a5839fdb-d323-4e55-9eaf-d8fa6a3e7366@github.com> On Thu, 28 Aug 2025 18:44:26 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add shen hpp changes Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3166176399 From asmehra at openjdk.org Thu Aug 28 19:42:43 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 28 Aug 2025 19:42:43 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: <6QMa3qlnRqJbBEwEAqzBBXrCddNA31i1uMRGQNHlqkg=.713dc318-07e0-4758-bff1-f624466bf884@github.com> On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra I haven't been able to reproduce it locally after running the test 1000 times. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3234722967 From dlong at openjdk.org Thu Aug 28 20:21:59 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 28 Aug 2025 20:21:59 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> References: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> Message-ID: On Wed, 27 Aug 2025 20:17:07 GMT, Erik ?sterlund wrote: >> @fisk , can I get you to review this? > >> @fisk , can I get you to review this? > > Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. > > My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. > > The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. > > Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. Thanks @fisk, that's a good theory, but it is not what I am seeing. For G1, lock contention does seem to explain the issue, and this PR fixes the regression. (Also the lock overhead I measured seemed to agree with the regression in GC phase time and benchmark scores.) For ZGC, I am not seeing an increase in calls to BarrierSetAssembler::increment_patching_epoch(). And increment_patching_epoch() is only called when disarming -- that part hasn't changed. I think the suspected ZGC regression is just noise in the benchmark, as the benchmark can show a regression across multiple runs even with the same build, flags, and host. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3234822398 From iklam at openjdk.org Thu Aug 28 21:17:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 28 Aug 2025 21:17:42 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run - @DanHeidinga comments - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - more clean up - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=05 Stats: 712 lines in 44 files changed: 597 ins; 13 del; 102 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From duke at openjdk.org Thu Aug 28 21:35:26 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 28 Aug 2025 21:35:26 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v6] In-Reply-To: References: Message-ID: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` Rui Li has updated the pull request incrementally with one additional commit since the last revision: shen hpp changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26907/files - new: https://git.openjdk.org/jdk/pull/26907/files/cbf1819a..1c8d334a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26907/head:pull/26907 PR: https://git.openjdk.org/jdk/pull/26907 From kvn at openjdk.org Thu Aug 28 22:02:41 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 28 Aug 2025 22:02:41 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: <6QMa3qlnRqJbBEwEAqzBBXrCddNA31i1uMRGQNHlqkg=.713dc318-07e0-4758-bff1-f624466bf884@github.com> References: <6QMa3qlnRqJbBEwEAqzBBXrCddNA31i1uMRGQNHlqkg=.713dc318-07e0-4758-bff1-f624466bf884@github.com> Message-ID: On Thu, 28 Aug 2025 19:39:55 GMT, Ashutosh Mehra wrote: > I haven't been able to reproduce it locally after running the test 1000 times. And I did not see such failure in our testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3235074556 From eastigeevich at openjdk.org Thu Aug 28 22:09:45 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 28 Aug 2025 22:09:45 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com> References: <17ZyoGne01VbBd_HgtB8tTnSPGkCnQhHM3JwsDcGO-4=.22f8ae51-1100-4ae9-b2f5-c5cd93d6c3bf@github.com> Message-ID: <-rvuOLCVGMSDH-z_T310KDk6R39Qw0xSZlXDwd-6R6k=.55328043-0e2e-47d4-85d1-b08e21c9314d@github.com> On Wed, 27 Aug 2025 20:05:38 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > You could separate the two if you'd like. I'm running tier1-4 testing on the PR I sent right now. Also, I haven't tried it on your test. > Edit again: I don't see your test added to this PR. @coleenp, I managed to write a jtreg test. Unfortunately it fails intermittently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3235095804 From dlong at openjdk.org Thu Aug 28 22:27:46 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 28 Aug 2025 22:27:46 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 14 Aug 2025 08:56:19 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments If we end up adding a nop or illegal instruction, then we can also undo the work-around that we did in JDK-8172844 for a similar problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3235129423 From cslucas at openjdk.org Fri Aug 29 00:08:16 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 29 Aug 2025 00:08:16 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch Message-ID: Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. ------------- Commit messages: - Change shenandoah nmethod entry barrier fence. Changes: https://git.openjdk.org/jdk/pull/26999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364936 Stats: 16 lines in 6 files changed: 0 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26999/head:pull/26999 PR: https://git.openjdk.org/jdk/pull/26999 From dholmes at openjdk.org Fri Aug 29 01:02:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Aug 2025 01:02:43 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: > `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. > > Testing: > - tiers 1-3 sanity > > 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 8364735-xtty - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26832/files - new: https://git.openjdk.org/jdk/pull/26832/files/212b6d5a..7cc72240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26832&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26832&range=00-01 Stats: 21651 lines in 625 files changed: 14641 ins; 4501 del; 2509 mod Patch: https://git.openjdk.org/jdk/pull/26832.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26832/head:pull/26832 PR: https://git.openjdk.org/jdk/pull/26832 From dholmes at openjdk.org Fri Aug 29 01:02:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Aug 2025 01:02:43 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 19 Aug 2025 00:11:38 GMT, David Holmes wrote: > `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. > > Testing: > - tiers 1-3 sanity > > Thanks @kimbarrett and @tstuefe I looked at trying to not actually delete the stream but this is far more complex than it may appear. If you look at what happens via the `defaultStream` destructor there is a lot of cleanup and deletion of other stream objects (xmlStream, fileStream). It is far from clear what exactly a shutdown "without closing or deleting" would actually look like - nor what potential bugs it may introduce. What I have proposed here is a simple fix to the use-after-free problem. I don't think a redesign of stream handling at shutdown is a reasonable request to address this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3235376630 From dholmes at openjdk.org Fri Aug 29 06:05:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Aug 2025 06:05:48 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v3] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 16:30:34 GMT, Leonid Mesnik wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1843: >> >>> 1841: // return a flag when a method terminates by throwing an exception >>> 1842: // i.e. if an exception is thrown and it's not caught by the current method >>> 1843: bool exception_exit = state->is_exception_detected() && !state->is_exception_caught(); >> >> Can we assert this is not an exception exit please. > > I am not sure what to check here. > The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown. But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2309232727 From iklam at openjdk.org Fri Aug 29 06:08:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 29 Aug 2025 06:08:42 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: <8ctJLegzZC9BnjyHMmgP4mBsrKgYjw9q29jLpQvFmuw=.9ab7631b-013d-4dc1-8178-8c76eff6f64b@github.com> On Thu, 28 Aug 2025 06:13:26 GMT, David Holmes wrote: > FWIW `jfieldIDWorkaround::encode_klass_hash` does seem to end up getting called only when `k` is an `instanceKlass` but we should file a cleanup RFE to change the parameter type. I have filed [JDK-8366417](https://bugs.openjdk.org/browse/JDK-8366417) - jfieldIDWorkaround should use InstanceKlass* instead of Klass* ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3235833281 From shade at openjdk.org Fri Aug 29 06:35:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Aug 2025 06:35:41 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas wrote: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. I see `virtual NMethodPatchingType nmethod_patching_type() { return NMethodPatchingType::conc_data_patch; }` in Shenandoah PPC64 and RISC-V barrier sets as well. Those should likely go away as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235890936 From lmesnik at openjdk.org Fri Aug 29 06:56:45 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 29 Aug 2025 06:56:45 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v3] In-Reply-To: References: Message-ID: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> On Fri, 29 Aug 2025 06:03:30 GMT, David Holmes wrote: >> I am not sure what to check here. >> The 'exception_exit' can be true here. It means that it has been thrown in this thread and not caught yet. But this method is called after exception thrown. > > But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ??? There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown and there were other upcals in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping. The test `TestMethodExitWithPendingException` simulates the same issue by calling method in the MethodExit event call back. For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called. Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing. V [libjvm.so+0x1415d6c] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c (jvmtiExport.cpp:1847) V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278) j java.lang.Object.()V+0 java.base at 26-internal j java.lang.Throwable.(Ljava/lang/String;)V+1 java.base at 26-internal j java.lang.Error.(Ljava/lang/String;)V+2 java.base at 26-internal j java.lang.LinkageError.(Ljava/lang/String;)V+2 java.base at 26-internal j java.lang.NoClassDefFoundError.(Ljava/lang/String;)V+2 java.base at 26-internal v ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd V [libjvm.so+0x1089117] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7 (javaCalls.cpp:415) V [libjvm.so+0x108ab3f] JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f (javaCalls.cpp:323) V [libjvm.so+0x108b3c6] JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116 (javaCalls.cpp:289) V [libjvm.so+0xd74f4b] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db (exceptions.cpp:320) V [libjvm.so+0xd7517f] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f (exceptions.cpp:341) V [libjvm.so+0xd7609f] Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf (exceptions.cpp:424) V [libjvm.so+0xd7b9a0] Exceptions::_throw_msg_cause(JavaThread*, char const*, int, Symbol*, char const*, Handle)+0x60 (exceptions.cpp:208) V [libjvm.so+0x1ad397b] handle_resolution_exception(Symbol*, bool, JavaThread*)+0x22b (systemDictionary.cpp:313) V [libjvm.so+0x1adef82] SystemDictionary::resolve_with_circularity_detection(Symbol*, Symbol*, Handle, bool, JavaThread*)+0x282 (systemDictionary.cpp:487) V [libjvm.so+0xa9baf2] ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x402 (systemDictionary.hpp:118) V [libjvm.so+0xaa3142] ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x192 (classFileParser.cpp:5425) V [libjvm.so+0x146d4f5] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0x195 (klassFactory.cpp:202) V [libjvm.so+0x1add90c] SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xfc (systemDictionary.cpp:869) V [libjvm.so+0x1262042] jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x322 (jvm.cpp:886) V [libjvm.so+0x12622f5] JVM_DefineClassWithSource+0xa5 (jvm.cpp:1053) C [libjava.so+0xe659] Java_java_lang_ClassLoader_defineClass1+0x1a9 (ClassLoader.c:139) j java.lang.ClassLoader.defineClass1(Ljava/lang/ClassLoader;Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class;+0 java.base at 26-internal j java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class;+27 java.base at 26-internal j java.security.SecureClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/CodeSource;)Ljava/lang/Class;+12 java.base at 26-internal j java.net.URLClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/Resource;)Ljava/lang/Class;+220 java.base at 26-internal j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+30 java.base at 26-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+69 java.base at 26-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 26-internal v ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd V [libjvm.so+0x1089117] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7 (javaCalls.cpp:415) V [libjvm.so+0x1089873] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x313 (javaCalls.cpp:323) V [libjvm.so+0x1089fba] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, JavaThread*)+0xca (javaCalls.cpp:192) V [libjvm.so+0x1adfa90] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x1e0 (systemDictionary.cpp:1269) V [libjvm.so+0x1addb3c] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x1c (systemDictionary.cpp:1300) V [libjvm.so+0x1ade768] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, JavaThread*)+0xa48 (systemDictionary.cpp:694) V [libjvm.so+0x1adec82] SystemDictionary::resolve_or_fail(Symbol*, Handle, bool, JavaThread*)+0x22 (systemDictionary.cpp:332) V [libjvm.so+0xb9d6a5] ConstantPool::klass_at_impl(constantPoolHandle const&, int, JavaThread*)+0x185 (constantPool.cpp:665) V [libjvm.so+0x106df52] InterpreterRuntime::_new(JavaThread*, ConstantPool*, int)+0xb2 (constantPool.hpp:423) j TestClassResolutionFail.test1()V+0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2309321623 From dzhang at openjdk.org Fri Aug 29 07:04:41 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 29 Aug 2025 07:04:41 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch In-Reply-To: References: Message-ID: <133lBie4di5uGvczIdenGraY_OY6vmMRIY4CFOc2xYo=.c1635af8-f715-456c-910c-a63809916179@github.com> On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas wrote: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. Thanks for this patch! I've made similar changes on RISC-V. Could you please add those as well? https://github.com/DingliZhang/jdk/commit/495b07fe690ef7e3fe828fd2be27c4259c739c23 I've tested the `hotspot_gc_shenandoah` on the SG2042 with fastdebug and found no failures. Specjbb testing on the SG2042 is ongoing. I'll update the results later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235958508 From azafari at openjdk.org Fri Aug 29 10:16:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 29 Aug 2025 10:16:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. Thanks for your comments @jdksjolen and @xmas92. The discussion here is exactly what I meant by running UBSAN checks. It seems that more bugs get discovered. To answer 'when/how does this happen?', this issue can be reproduced by running `runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java`, in which invalid values of options will be tested, particularly here `0` for `HeapBaseMinAddress`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3236511021 From ihse at openjdk.org Fri Aug 29 11:07:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 29 Aug 2025 11:07:59 GMT Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v18] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 16:45:55 GMT, Francesco Andreuzzi wrote: >> Ran the script locally, and noticed that on my Mac this was the difference: >> >> >> -#include "oops/oopHandle.inline.hpp" >> #include "oops/oop.inline.hpp" >> +#include "oops/oopHandle.inline.hpp" >> >> >> Something is a bit off with sorting, I think. >> >> Indeed, this fails: >> >> >> $ diff --git a/test/hotspot/jtreg/sources/TestIncludesAreSorted.java b/test/hotspot/jtreg/sources/TestIncludesAreSorted.java >> index 1a304a44944..287aad01b78 100644 >> --- a/test/hotspot/jtreg/sources/TestIncludesAreSorted.java >> +++ b/test/hotspot/jtreg/sources/TestIncludesAreSorted.java >> @@ -58,6 +58,7 @@ public class TestIncludesAreSorted { >> "share/metaprogramming", >> "share/oops", >> "share/opto", >> + "share/precompiled", >> "share/services", >> "share/utilities" >> }; >> >> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=sources/ >> STDERR: >> java.lang.RuntimeException: 1 files with unsorted headers found: >> /Users/shipilev/Work/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp >> >> >> This is a minor thing, and we can technically deal with it once we sort the includes in `precompiled.hpp` in the constellation of issues that are dedicated to include sorting. But it would also be great to do this right from the get-go. >> >> See if there is anything easy missing in the script? > >> See if there is anything easy missing in the script? > > Thanks @shipilev, I addressed this in 6693cefe01e03cd05a11a93cf04d0d6af78f42bb. I use `SortIncludes.java` instead of `sort`, and I also added `precompiled` to `TestIncludesAreSorted.java`. Once again thank you @fandreuz for the effort you put into this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3236658521 From qpzhang at openjdk.org Fri Aug 29 11:10:44 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 29 Aug 2025 11:10:44 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false In-Reply-To: <-3MopRJ8ncWyveWxD5HSZpsL84dl2aiQc53ww9Q8IxA=.7233def8-7bc6-41d0-8529-bce01af9d131@github.com> References: <-3MopRJ8ncWyveWxD5HSZpsL84dl2aiQc53ww9Q8IxA=.7233def8-7bc6-41d0-8529-bce01af9d131@github.com> Message-ID: On Tue, 26 Aug 2025 13:26:33 GMT, Andrew Dinn wrote: >> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. >> >> This PR, >> 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. >> 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. >> 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side >> 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. >> 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java >> >> These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. >> >> Tests include, >> 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. >> 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences g... > > @cnqpzhang If you look back at the history of this code you will see that you are undoing a change that was made deliberately by @theRealAph. Your patch may improve the specific test case you have provided but at the cost of a significant and unacceptable increase in code cache use for all cases. > > The comment at the head of the code you have edited makes this point explicitly. The reasoning behind that comment is available in the JIRA history and associated review comments. The relevant issue is > > https://bugs.openjdk.org/browse/JDK-8179444 > > and the corresponding review thread starts with > > https://mail.openjdk.org/pipermail/hotspot-dev/2017-April/026742.html > > and continues with > > https://mail.openjdk.org/pipermail/hotspot-dev/2017-May/026766.html > > I don't recommend integrating this change. Hi @adinn, thanks for your review. I have read two related JBS: 1. [JDK-8179444](https://bugs.openjdk.org/browse/JDK-8179444), Put zero_words on a diet (May 2017), https://github.com/openjdk/jdk/commit/1ce2a362524 2. [JDK-8270947](https://bugs.openjdk.org/browse/JDK-8270947), C1: use zero_words to initialize all objects (Jul 2021), https://github.com/openjdk/jdk/commit/6c68ce2d396 Particularly to two `zero_words` functions, `reg_reg` and `reg_imm`, the first patch (https://github.com/openjdk/jdk/commit/1ce2a362524) had `MacroAssembler::zero_words(Register ptr, Register cnt)` call the stub function `generate_zero_blocks()` and moved the `if (UseBlockZeroing)` condition into it, as such got a shorter instruction sequence for `ClearArray`. While the second one made `MacroAssembler::zero_words(Register base, uint64_t cnt)` route to the stub as well. My PR undoes some of the first patch (https://github.com/openjdk/jdk/commit/1ce2a362524), as described by #2 and #3 in the PR summary, but it is not all. Please see below, https://github.com/openjdk/jdk/commit/1ce2a362524 removed the `BlockZeroingLowLimit` check when dropping the call to `block_zero`. Next, https://github.com/openjdk/jdk/commit/6c68ce2d396 had `zero_words(Register base, uint64_t cnt)` call `zero_words(Register ptr, Register cnt)` then the stub func, which should have added back the `UseBlockZeroing` check but omitted it (intentionally?). https://github.com/openjdk/jdk/commit/1ce2a362524#diff-fe18bdf6585d1a0d4d510f382a568c4428334d4ad941581ecc10ec60ccafca4aL4972-L4974 } else if (UseBlockZeroing && cnt >= (u_int64_t)(BlockZeroingLowLimit >> LogBytesPerWord)) { mov(tmp, cnt); block_zero(base, tmp, true); https://github.com/openjdk/jdk/commit/6c68ce2d396#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aR4680-R4684 void MacroAssembler::zero_words(Register base, uint64_t cnt) { guarantee(zero_words_block_size < BlockZeroingLowLimit, "increase BlockZeroingLowLimit"); if (cnt <= (uint64_t)BlockZeroingLowLimit / BytesPerWord) { This looks a bit confusing when we have `-XX:-UseBlockZeroing` while the `BlockZeroingLowLimit` stil works. For example, when we have `'-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=16` and object instance size = `32`, Without the `UseBlockZeroing` check (base), we have: ;; zero_words { 0x0000400013b02e40: subs x8, x11, #0x8 0x0000400013b02e44: b.cc 0x0000400013b02e4c // b.lo, b.ul, b.last 0x0000400013b02e48: bl 0x0000400013b02f10 ; {runtime_call Stub::Stub Generator zero_blocks_stub} 0x0000400013b02e4c: tbz w11, #2, 0x0000400013b02e58 0x0000400013b02e50: stp xzr, xzr, [x10], #16 0x0000400013b02e54: stp xzr, xzr, [x10], #16 0x0000400013b02e58: tbz w11, #1, 0x0000400013b02e60 0x0000400013b02e5c: stp xzr, xzr, [x10], #16 0x0000400013b02e60: tbz w11, #0, 0x0000400013b02e68 0x0000400013b02e64: str xzr, [x10] ;; } zero_words In contrast, with the `UseBlockZeroing` check (patched), we will see: ;; zero_words (count = 2) { 0x000040003415e874: stp xzr, xzr, [x10] ;; } zero_words So, it appears that BlockZeroingLowLimit currently serves two purposes: as the lower limit for block zeroing, and as the threshold determining whether to call a stub or perform STP unrolling inline. Should we fix this, leave it as it is, or just add comments to explain it better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3236664312 From qpzhang at openjdk.org Fri Aug 29 11:10:45 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 29 Aug 2025 11:10:45 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false In-Reply-To: References: Message-ID: On Sun, 24 Aug 2025 16:23:19 GMT, Patrick Zhang wrote: > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. > > This PR, > 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. > 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. > 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side > 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. > 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > > These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. > > Tests include, > 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. > 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences got almost same as baseline, ... Regarding the impact to code caches, I measured JMH `vm.gc.RawAllocationRate.arrayTest` and `SPECjbb2015 PRESET run`. The first is not suitable for comparison because the array init code only takes a small portion of the overall space, with `-XX:+TieredCompilation` the sum of three segmented caches only showed <<1% diff. In another viewpoint, `SPECjbb2015` can be a complicated enough app that is able to demonstrate the impact on code caches, so I plot such a chart for a 20 minutes run, baseline vs patched. image We could eyeball that the profiled and non-profiled nmethods have slightly bigger sizes of used caches (patched vs baseline), tiny part of the total sizes ~6MB (profiled nm) and ~12MB (non-profiled nm). Furthermore, these diffs are relatively far smaller than the total reserved size, either 32M (C1 only), or 48M (with C2), or 240M (configured ergonomically by JVM). I manually set it as `-XX:InitialCodeCacheSize=32M -XX:ReservedCodeCacheSize=64M` for a managed range. Therefore, I have a question regarding the practical impact of the code cache in this context. Specifically, is the code cache still practically a significant concern relative to the benefits gained from reduced call counts and the modest performance improvements in code generation and execution for the generated array and object initialization code? That said, I fully understand the potential risks and concerns associated with modifying the existing logic. I would get prepared to roll back the changes related to the C2 part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3236669223 From qpzhang at openjdk.org Fri Aug 29 11:34:26 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 29 Aug 2025 11:34:26 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v2] In-Reply-To: References: Message-ID: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. > > This PR, > 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. > 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. > 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side > 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. > 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > > These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. > > Tests include, > 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. > 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences got almost same as baseline, ... Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Roll back main changes on zero_words_reg_reg and generate_zero_blocks Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26917/files - new: https://git.openjdk.org/jdk/pull/26917/files/98ee2799..14c18f7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=00-01 Stats: 74 lines in 2 files changed: 24 ins; 19 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/26917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917 PR: https://git.openjdk.org/jdk/pull/26917 From coleenp at openjdk.org Fri Aug 29 12:58:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 12:58:45 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> Message-ID: <-DYS7TMcvWFWplKvbjU4l2rrgc-qu2WyKNV0vn08yTs=.c35f5ae6-25f7-47b8-8275-26eaf23c43e0@github.com> On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes wrote: >> (I realize this is a tangent, but maybe there is a separate bug here...) >> >>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). >> >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced: >> >> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064 >> >> Class.forName(name, false, loader) would result in a prepared class but without the event being sent. > >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced > > @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed. Does it fail with the patch? Sorry for the delay. @dholmes-ora and I have been discussing how all this works offline, but with time-zone differences, we won't have any agreement until next week. I wrote a more limited version of the patch I sent and am testing it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3236952904 From asmehra at openjdk.org Fri Aug 29 13:55:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 29 Aug 2025 13:55:44 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra I filed a bug for the crash https://bugs.openjdk.org/browse/JDK-8366438 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3237120910 From coleenp at openjdk.org Fri Aug 29 14:10:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 14:10:47 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable Okay I ran the test case in the issue and I see why it wouldn't be reliable. I verified it with the new more minimalistic patch here: https://github.com/openjdk/jdk/pull/26971 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3237163963 From lkorinth at openjdk.org Fri Aug 29 14:41:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 29 Aug 2025 14:41:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 17:06:08 GMT, Matthew Donovan wrote: >> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: >> >> - revert added timeout, it is not needed >> - feedback from Mark Sheppard > > test/jdk/sun/security/krb5/name/Constructors.java line 28: > >> 26: * @summary Make PrincipalName and Realm immutable >> 27: * @modules java.security.jgss/sun.security.krb5 >> 28: * @run main/othervm Constructors > > Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second. I have not analysed why. I can see 1013 occurrences in our test history where the test takes 2 minutes or more. On different CPU platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2310355659 From eastigeevich at openjdk.org Fri Aug 29 15:34:44 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 29 Aug 2025 15:34:44 GMT Subject: RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Symplify comments; Get JavaThread::current in variable > Okay I ran the test case in the issue and I see why it wouldn't be reliable. I verified it with the new more minimalistic patch here: #26971 Thank you for the minimalistic patch. I now have a version of the jtreg test which fails more reliably. The test always passes the the previous version of #26971. BTW I have updated the title of [JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444). The issue is the data race between copy_bytecodes and class linking. So we must guarantee no data race when copy_bytecodes is used. I'll add the test to the PR soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3237447694 PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3237450933 From kbarrett at openjdk.org Fri Aug 29 16:33:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 29 Aug 2025 16:33:52 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks Marked as reviewed by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26934#pullrequestreview-3169361015 From dholmes at openjdk.org Fri Aug 29 16:33:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Aug 2025 16:33:53 GMT Subject: RFR: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: <4a1tuJAWRWPM-QXXL7bW0mAJspq02ii8d2TcNhWicy4=.a6c0709d-8b2c-4686-a73d-77c53f85299e@github.com> References: <4a1tuJAWRWPM-QXXL7bW0mAJspq02ii8d2TcNhWicy4=.a6c0709d-8b2c-4686-a73d-77c53f85299e@github.com> Message-ID: On Thu, 28 Aug 2025 14:31:20 GMT, Vladimir Kozlov wrote: >> This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. >> >> Thanks > > Approved Thanks @vnkozlov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26934#issuecomment-3235829582 From dholmes at openjdk.org Fri Aug 29 16:33:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Aug 2025 16:33:53 GMT Subject: Integrated: 8366121: Hotspot Style Guide should document conventions for lock-free code In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 00:26:59 GMT, David Holmes wrote: > This is a topic that we, at Oracle, have discussed numerous times over the years and we have some simple guidelines that never get written down properly and which we/I tend to forget and then can't locate. To remedy that I would like to capture a few very simple style rules that exist for documentation purposes not necessarily correctness. > > Thanks This pull request has now been integrated. Changeset: d594ef3a Author: David Holmes URL: https://git.openjdk.org/jdk/commit/d594ef3a3e013b84a392b6d64a54015adc8173cd Stats: 21 lines in 2 files changed: 21 ins; 0 del; 0 mod 8366121: Hotspot Style Guide should document conventions for lock-free code Reviewed-by: stefank, ayang, jsjolen, jwaters, kvn, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/26934 From matsaave at openjdk.org Fri Aug 29 17:59:46 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 29 Aug 2025 17:59:46 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 05:03:54 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache > - @coleenp comments > - More bug fixes from JCK testing > - Fixed bugs found in JCK testing > - 8317269: Store old classes in linked state in AOT cache Looks good, thanks for this! There are some typos in the comments and we had an offline discussion about the lambda. Once those are fixed I can approve src/hotspot/share/cds/cdsConfig.cpp line 939: > 937: // of the production run. This means that if a class was successfully verified > 938: // in the assembly phase, all of the verifier's assignability checks will remain > 939: // valid in the production run, so we don't need to verify aot-lined classes again. Type: aot-lined -> aot-linked src/hotspot/share/cds/dumpTimeClassInfo.cpp line 94: > 92: if (log_is_enabled(Trace, aot, verification)) { > 93: ResourceMark rm; > 94: log_trace(aot, verification)("add old verification dependency: %s: %s must be also be archived", Should this comment be "added old..."? src/hotspot/share/classfile/systemDictionaryShared.cpp line 241: > 239: } > 240: > 241: // This is a table of classes that need to be check for exclusion. Typo: check -> checked src/hotspot/share/classfile/systemDictionaryShared.cpp line 312: > 310: ResourceMark rm; > 311: > 312: // This will recursive find ik and all of its exclusion dependencies that have not yet been checked. Typo: recursively ------------- Changes requested by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3169379131 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310625223 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310647700 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310670483 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310680295 From cslucas at openjdk.org Fri Aug 29 18:41:43 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 29 Aug 2025 18:41:43 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 21:35:26 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > shen hpp changes Ship it! ------------- Marked as reviewed by cslucas (Committer). PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3169697972 From pchilanomate at openjdk.org Fri Aug 29 18:45:05 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 29 Aug 2025 18:45:05 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v3] In-Reply-To: <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com> References: <566ef980l4Ql3HYnexGwX9JKkpaY8tOtlHqt2Vi-7t4=.856dddd4-93f3-4d80-9b3c-d3a8d795dc4e@github.com> Message-ID: On Thu, 28 Aug 2025 16:41:56 GMT, Leonid Mesnik wrote: >> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates >> `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` >> to find if method exit normally or by exception. >> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See >> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` >> where post_method_exit_inner is called directly. >> >> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. >> >> >> The fix was a part of >> https://github.com/openjdk/jdk/pull/26713 >> for >> https://bugs.openjdk.org/browse/JDK-8365192 > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: > > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - comment fixed > - Merge branch 'master' of https://github.com/openjdk/jdk into 8365937 > - assertion added. > - more comments in the test > - fixed ident > - bugid fixed: > - updated to fix 8365937 > - fixed comment. > - test renamed. > - ... and 17 more: https://git.openjdk.org/jdk/compare/01e62e37...4e05639a LGTM. Thanks for fixing and adding the extra tests. test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 48: > 46: const char *str = jni->GetStringUTFChars(upcall_result, nullptr); > 47: if (str == nullptr) { > 48: fatal(jni ,"Failed to convert Java string to C string."); Suggestion: fatal(jni, "Failed to convert Java string to C string."); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 63: > 61: jclass main_class = jni->FindClass("TestMethodExitWithPendingException"); > 62: if (main_class == nullptr) { > 63: fatal(jni,"Can't find TestMethodExitWithPendingException class."); Suggestion: fatal(jni, "Can't find TestMethodExitWithPendingException class."); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 69: > 67: "upCall", "()Ljava/lang/String;"); > 68: if (upcall_method == nullptr) { > 69: fatal(jni,"Can't find upCall method."); Suggestion: fatal(jni, "Can't find upCall method."); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp line 76: > 74: const char *str = jni->GetStringUTFChars(upcall_result, nullptr); > 75: if (str == nullptr) { > 76: fatal(jni ,"Failed to convert Java string to C string."); Suggestion: fatal(jni, "Failed to convert Java string to C string."); test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PoppedByException/libTestPoppedByException.cpp line 39: > 37: } > 38: if (return_value.l != nullptr) { > 39: fatal(jni ,"return_value should be nullptr."); Suggestion: fatal(jni, "return_value should be nullptr."); ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3169698189 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310845150 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310846119 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310846950 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310847641 PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2310849997 From matsaave at openjdk.org Fri Aug 29 18:46:48 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 29 Aug 2025 18:46:48 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 14:44:29 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 Is there an ETA for integration? There are new tests for Valhalla that are disabled because they rely on some of the new features in JTREG 8. We are working to reinforce testing and are really looking forward to this patch so we can merge it from mainline to lworld. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3237899247 From lkorinth at openjdk.org Fri Aug 29 18:45:45 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 29 Aug 2025 18:45:45 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v7] In-Reply-To: References: Message-ID: <2IfOGWu0Kfw8qdRmYLkMEdF5kvlC5lcuc-USAovOTFM=.f6d2a6c9-160d-478e-aa5c-1086b40e52bd@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/365454d2..4b33904a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=05-06 Stats: 233 lines in 233 files changed: 0 ins; 0 del; 233 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From jsjolen at openjdk.org Fri Aug 29 18:56:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 29 Aug 2025 18:56:53 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock Message-ID: Hi, The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. ------------- Commit messages: - Remove now unused iterator - Use a copied VMATree instead of a LinkedList Changes: https://git.openjdk.org/jdk/pull/27003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366363 Stats: 140 lines in 10 files changed: 75 ins; 44 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Fri Aug 29 19:04:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 29 Aug 2025 19:04:41 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com> On Fri, 29 Aug 2025 12:13:57 GMT, Johan Sj?len wrote: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. src/hotspot/share/utilities/rbTree.hpp line 454: > 452: public: > 453: RBTree() : BaseType(), _allocator() {} > 454: RBTree(const RBTree& other) : BaseType(), _allocator() { @caspernorrbin , I added this. Does it look correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2310890005 From lmesnik at openjdk.org Fri Aug 29 19:11:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 29 Aug 2025 19:11:04 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: Message-ID: > The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates > `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` > to find if method exit normally or by exception. > However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See > `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` > where post_method_exit_inner is called directly. > > The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. > > > The fix was a part of > https://github.com/openjdk/jdk/pull/26713 > for > https://bugs.openjdk.org/browse/JDK-8365192 Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Apply suggestions from code review Co-authored-by: Patricio Chilano Mateo - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp Co-authored-by: Patricio Chilano Mateo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26886/files - new: https://git.openjdk.org/jdk/pull/26886/files/4e05639a..09607978 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26886&range=02-03 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26886/head:pull/26886 PR: https://git.openjdk.org/jdk/pull/26886 From iklam at openjdk.org Fri Aug 29 20:50:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 29 Aug 2025 20:50:31 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. 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 nine additional commits since the last revision: - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache - @matias9927 comments: fixed typos - clean up; removed unrelated change - Cleaned up iterate_verification_dependency_names so a return value of false from means early termination (similar to HashTable::iterate()) - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache - @coleenp comments - More bug fixes from JCK testing - Fixed bugs found in JCK testing - 8317269: Store old classes in linked state in AOT cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/5ec12352..fc9e29c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=03-04 Stats: 8068 lines in 151 files changed: 6937 ins; 462 del; 669 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From coleenp at openjdk.org Fri Aug 29 21:54:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 21:54:47 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: Message-ID: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> On Fri, 29 Aug 2025 20:50:31 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > 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 nine additional commits since the last revision: > > - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache > - @matias9927 comments: fixed typos > - clean up; removed unrelated change > - Cleaned up iterate_verification_dependency_names so a return value of false from means early termination (similar to HashTable::iterate()) > - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache > - @coleenp comments > - More bug fixes from JCK testing > - Fixed bugs found in JCK testing > - 8317269: Store old classes in linked state in AOT cache I'm making progress. This is a large somewhat complicated change and I have some questions and comments. src/hotspot/share/classfile/systemDictionaryShared.cpp line 469: > 467: > 468: // Returns true if the DumpTimeClassInfo::is_excluded() is true for at least one of k's exclusion dependencies. > 469: bool SystemDictionaryShared::check_dependencies_exclusion(InstanceKlass* k, DumpTimeClassInfo* info) { So this checks one level of InstanceKlass* k's dependencies, and the table above collects one level of k or k's subclass's dependencies and calls this for those. class K : extends B implements I, J verifies C {} - the above hashtable has B, I and J and C. This function takes B - so checks B class. class B : extends A implements intf verifies C again, why not {} So it'd check A and intf and C again. But when do we check A's super? It seems like the hashtable should be created for all levels of the hierarchy, so only one bit of code should walk the hierarchy, not two. src/hotspot/share/classfile/systemDictionaryShared.cpp line 542: > 540: } > 541: > 542: Klass* SystemDictionaryShared::find_verification_dependency_bottom_class(InstanceKlass* k, Symbol* dependency_class_name) { Why don't you have this return InstanceKlasss so that the callers don't have to check the same thing. What you want is the bottom InstanceKlass so for [Lfoo; - you want foo. Since class foo is the thing you care about. Maybe the comment about why you return nullptr from check_verification_dependency_exclusion() could be here instead. These names are a bit repetative, can you just call this find_bottom_instance_klass() and maybe it could be used for other things too. src/hotspot/share/classfile/systemDictionaryShared.cpp line 1036: > 1034: DumpTimeClassInfo* info = get_info(ik); > 1035: Handle loader(current, ik->class_loader()); > 1036: Klass* k = SystemDictionary::find_instance_or_array_klass(current, name, loader); The caller just did this, didn't it? So, you should just be able to pass in from_class (unless it's null). ------------- PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3169748899 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311370713 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311313095 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311248609 From coleenp at openjdk.org Fri Aug 29 21:54:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 21:54:49 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> References: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> Message-ID: <4CuIk4X6i570N7wUdCfCdiwla8tAKyyn9iHkj-fIR-A=.680f53c2-7d13-460f-82e6-7eb46453ef9e@github.com> On Tue, 19 Aug 2025 23:31:55 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/metaspaceShared.cpp line 636: >> >>> 634: >>> 635: void VM_PopulateDumpSharedSpace::doit() { >>> 636: CDSConfig::set_is_at_cds_safepoint(true); >> >> Can you just use SafepointSynchronize::is_at_safepoint()? Why new flag? > > We need to know if are are at the CDS safepoint, not any safepoint. I don't think we share safepoints anymore (?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311372972 From coleenp at openjdk.org Fri Aug 29 21:54:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 21:54:52 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 05:03:54 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache > - @coleenp comments > - More bug fixes from JCK testing > - Fixed bugs found in JCK testing > - 8317269: Store old classes in linked state in AOT cache src/hotspot/share/cds/runTimeClassInfo.hpp line 204: > 202: u4* old_verifier_dependencies() { > 203: assert(_num_old_verifier_dependencies > 0, "sanity"); > 204: return (u4*)(address(this) + old_verifier_dependencies_offset()); This seems like it should have a checked_cast<> around it rather than a plain cast. src/hotspot/share/prims/jvm.cpp line 854: > 852: > 853: #if INCLUDE_CDS > 854: if (CDSConfig::is_preserving_verification_dependencies() && from_class->is_instance_klass()) { It looks like from_class can be null so you have to check for null here. Which doesn't make sense because the logging doesn't have null checks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2310882759 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311133213 From coleenp at openjdk.org Fri Aug 29 21:54:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 21:54:53 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> Message-ID: On Fri, 29 Aug 2025 20:52:08 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: >> >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @matias9927 comments: fixed typos >> - clean up; removed unrelated change >> - Cleaned up iterate_verification_dependency_names so a return value of false from means early termination (similar to HashTable::iterate()) >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @coleenp comments >> - More bug fixes from JCK testing >> - Fixed bugs found in JCK testing >> - 8317269: Store old classes in linked state in AOT cache > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1036: > >> 1034: DumpTimeClassInfo* info = get_info(ik); >> 1035: Handle loader(current, ik->class_loader()); >> 1036: Klass* k = SystemDictionary::find_instance_or_array_klass(current, name, loader); > > The caller just did this, didn't it? So, you should just be able to pass in from_class (unless it's null). I would kind of prefer old_verifier_dependency rather than old_verification - the latter seems to say that we had some verification that is no longer valid. old_verifier makes it clearer it's for old classfiles and the old verifier. Also 'verification' is used for the regular verifier so it's less of a same name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311263886 From coleenp at openjdk.org Fri Aug 29 21:54:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 29 Aug 2025 21:54:54 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 20:25:34 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @coleenp comments >> - More bug fixes from JCK testing >> - Fixed bugs found in JCK testing >> - 8317269: Store old classes in linked state in AOT cache > > src/hotspot/share/prims/jvm.cpp line 854: > >> 852: >> 853: #if INCLUDE_CDS >> 854: if (CDSConfig::is_preserving_verification_dependencies() && from_class->is_instance_klass()) { > > It looks like from_class can be null so you have to check for null here. > Which doesn't make sense because the logging doesn't have null checks. This looks like something that should be cleaned up apart from this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2311378906 From kvn at openjdk.org Fri Aug 29 22:32:42 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 29 Aug 2025 22:32:42 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra @adinn, please review these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3238440040 From eastigeevich at openjdk.org Fri Aug 29 22:48:06 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 29 Aug 2025 22:48:06 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4] In-Reply-To: References: Message-ID: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds linking a class before the `copy_bytecodes` method is called. > The PR also adds a regression test. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - The regression test passed. > - Tier1 - tier3 passed. Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8277444 - Link classes before copy_bytecodes; Add regression test - Symplify comments; Get JavaThread::current in variable - Add missing include runtime/synchronizer.hpp - 8277444: Race condition on Instrumentation.retransformClasses() and class linking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26863/files - new: https://git.openjdk.org/jdk/pull/26863/files/293d81ff..f5019d97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=02-03 Stats: 21687 lines in 641 files changed: 14684 ins; 4507 del; 2496 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From vaivanov at openjdk.org Fri Aug 29 22:49:58 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 29 Aug 2025 22:49:58 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v2] In-Reply-To: References: Message-ID: <4c9zNAuQQRv_kavQx9RMqXa1_l_2uq3LNoI-rM9ZLIU=.10037d4b-a64e-4795-88c6-e5d310f58ff0@github.com> > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/f3906135..bca697c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=00-01 Stats: 35 lines in 1 file changed: 19 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From eastigeevich at openjdk.org Fri Aug 29 22:58:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 29 Aug 2025 22:58:43 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:07:51 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Symplify comments; Get JavaThread::current in variable > > Okay I ran the test case in the issue and I see why it wouldn't be reliable. I verified it with the new more minimalistic patch here: https://github.com/openjdk/jdk/pull/26971 @coleenp, I have pulled your changes. I added a `guarantee` check to `copy_bytecodes`. IMO it's better to be overcautious to prevent incorrect uses of `copy_bytes`. Because of it I had to add `link_class` to `GetBytecodes`. I don't use the macros because they rely on `THREAD`. It is a variable in your patch but it is usually used as a macro. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3238571537 From vaivanov at openjdk.org Fri Aug 29 23:24:00 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 29 Aug 2025 23:24:00 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v3] In-Reply-To: References: Message-ID: > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/bca697c3..7bc1b453 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From iklam at openjdk.org Sat Aug 30 02:18:24 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 02:18:24 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() Message-ID: Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: - tests if an object is inside the AOT cache's metaspace region. Also various forms of "shared metaspace" are updated to "aot metaspace" Please start your review with allocations.hpp ------------- Commit messages: - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() Changes: https://git.openjdk.org/jdk/pull/27016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366474 Stats: 199 lines in 56 files changed: 3 ins; 0 del; 196 mod Patch: https://git.openjdk.org/jdk/pull/27016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27016/head:pull/27016 PR: https://git.openjdk.org/jdk/pull/27016 From iklam at openjdk.org Sat Aug 30 02:27:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 02:27:25 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace Message-ID: Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. All changes are mechanical text replacement. Headers are resorted alphabetically. ------------- Depends on: https://git.openjdk.org/jdk/pull/27016 Commit messages: - Rename MetaspaceShared -> AOTMetaspace Changes: https://git.openjdk.org/jdk/pull/27017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366475 Stats: 356 lines in 56 files changed: 30 ins; 30 del; 296 mod Patch: https://git.openjdk.org/jdk/pull/27017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017 PR: https://git.openjdk.org/jdk/pull/27017 From iklam at openjdk.org Sat Aug 30 02:40:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 02:40:33 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp Message-ID: 1] Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` [2] Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. ------------- Depends on: https://git.openjdk.org/jdk/pull/27017 Commit messages: - 8366477: Refactor AOT-related flag bits in klass.hpp Changes: https://git.openjdk.org/jdk/pull/27018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27018&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366477 Stats: 54 lines in 4 files changed: 20 ins; 10 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27018/head:pull/27018 PR: https://git.openjdk.org/jdk/pull/27018 From liach at openjdk.org Sat Aug 30 04:26:41 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 30 Aug 2025 04:26:41 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:35:11 GMT, Ioi Lam wrote: > 1] Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` > > [2] Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. Looks helpful. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27018#pullrequestreview-3170864066 From cstein at openjdk.org Sat Aug 30 05:30:43 2025 From: cstein at openjdk.org (Christian Stein) Date: Sat, 30 Aug 2025 05:30:43 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 18:44:04 GMT, Matias Saavedra Silva wrote: > Is there an ETA for integration? On September, 1st. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3238964563 From lgxbslgx at gmail.com Sat Aug 30 10:40:39 2025 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 30 Aug 2025 18:40:39 +0800 Subject: [Question] The property `vm.gc` in jtreg test Message-ID: Hi all, I notice the meaning of the test property `vm.gc` is not clear. The method `VMProps::vmGCforCDS` (shown below, in directory: test/jtreg-ext/requires/VMProps.java) extracts the property `vm.gc` from the option `test.cds.runtime.options`. So the current `vm.gc` is about both CDS and GC, not only the GC. I propose changing the current test property name `vm.gc` to `vm.gc.cds` or `vm.cds.gc`. Waiting for your opinion. Any ideas will be appreciated. ```java /** * "jtreg -vmoptions:-Dtest.cds.runtime.options=..." can be used to specify * the GC type to be used when running with a CDS archive. Set "vm.gc" accordingly, * so that tests that need to explicitly choose the GC type can be excluded * with "@requires vm.gc == null". * * @param map - property-value pairs */ protected void vmGCforCDS(SafeMap map) { if (!GC.isSelectedErgonomically()) { // The GC has been explicitly specified on the command line, so // jtreg will set the "vm.gc" property. Let's not interfere with it. return; } String jtropts = System.getProperty("test.cds.runtime.options"); if (jtropts != null) { for (String opt : jtropts.split(",")) { if (opt.startsWith(GC_PREFIX) && opt.endsWith(GC_SUFFIX)) { String gc = opt.substring(GC_PREFIX.length(), opt.length() - GC_SUFFIX.length()); map.put("vm.gc", () -> gc); } } } } ``` Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Sat Aug 30 13:43:34 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sat, 30 Aug 2025 13:43:34 +0000 Subject: [Question] The property `vm.gc` in jtreg test In-Reply-To: References: Message-ID: Hello, I don't think this is as harmful as you have assumed. The way CDS tests work (taking runtime/cds/appcds/aotCache/HelloAOTCache.java for example) is that the tests themselves are just drivers to execute jar applications (because CDS only works for jar applications). test.cds.runtime.options system property is only provided when running customized runtime/cds tests so flags can be passed to child vms, and all those tests anticipate vm.gc to indicate the gc for the child vm spawned by the driver. In conclusion, I don't think a rename would be necessary, as I don't see a scenario where the driver itself would care about its own gc in addition to the child process gc. CC'ing Ioi as Ioi is the main CDS area maintainer. Chen ________________________________ From: hotspot-dev on behalf of Guoxiong Li Sent: Saturday, August 30, 2025 5:40 AM To: hotspot-gc-dev at openjdk.org ; hotspot-runtime-dev at openjdk.org ; hotspot-dev at openjdk.org Subject: [Question] The property `vm.gc` in jtreg test Hi all, I notice the meaning of the test property `vm.gc` is not clear. The method `VMProps::vmGCforCDS` (shown below, in directory: test/jtreg-ext/requires/VMProps.java) extracts the property `vm.gc` from the option `test.cds.runtime.options`. So the current `vm.gc` is about both CDS and GC, not only the GC. I propose changing the current test property name `vm.gc` to `vm.gc.cds` or `vm.cds.gc`. Waiting for your opinion. Any ideas will be appreciated. ```java /** * "jtreg -vmoptions:-Dtest.cds.runtime.options=..." can be used to specify * the GC type to be used when running with a CDS archive. Set "vm.gc" accordingly, * so that tests that need to explicitly choose the GC type can be excluded * with "@requires vm.gc == null". * * @param map - property-value pairs */ protected void vmGCforCDS(SafeMap map) { if (!GC.isSelectedErgonomically()) { // The GC has been explicitly specified on the command line, so // jtreg will set the "vm.gc" property. Let's not interfere with it. return; } String jtropts = System.getProperty("test.cds.runtime.options"); if (jtropts != null) { for (String opt : jtropts.split(",")) { if (opt.startsWith(GC_PREFIX) && opt.endsWith(GC_SUFFIX)) { String gc = opt.substring(GC_PREFIX.length(), opt.length() - GC_SUFFIX.length()); map.put("vm.gc", () -> gc); } } } } ``` Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvn at openjdk.org Sat Aug 30 14:03:47 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 14:03:47 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:13:20 GMT, Ioi Lam wrote: > Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: > - tests if an object is inside the AOT cache's metaspace region. > > Also various forms of "shared metaspace" are updated to "aot metaspace" > > Please start your review with allocations.hpp src/hotspot/share/include/cds.h line 38: > 36: // Also, this is a C header file. Do not use C++ here. > 37: > 38: #define NUM_CDS_REGIONS 5 // this must be the same as AOTMetaspace::n_regions This file changes seems belong to your other RFE JDK-8366475. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311954464 From kvn at openjdk.org Sat Aug 30 14:03:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 14:03:48 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 14:01:00 GMT, Vladimir Kozlov wrote: >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > src/hotspot/share/include/cds.h line 38: > >> 36: // Also, this is a C header file. Do not use C++ here. >> 37: >> 38: #define NUM_CDS_REGIONS 5 // this must be the same as AOTMetaspace::n_regions > > This file changes seems belong to your other RFE JDK-8366475. But I am fine to have it here - it is only in comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311954625 From kvn at openjdk.org Sat Aug 30 14:08:41 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 14:08:41 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:13:20 GMT, Ioi Lam wrote: > Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: > - tests if an object is inside the AOT cache's metaspace region. > > Also various forms of "shared metaspace" are updated to "aot metaspace" > > Please start your review with allocations.hpp Good. In few places you used `AOTMetaspace` in comments and messages. But I think it is fine. I assume you push this first. test/hotspot/jtreg/runtime/cds/SpaceUtilizationCheck.java line 62: > 60: WhiteBox wb = WhiteBox.getWhiteBox(); > 61: long reserve_alignment = wb.metaspaceSharedRegionAlignment(); > 62: System.out.println("AOTMetaspace::core_region_alignment() = " + reserve_alignment); Here too. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3171054693 PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2311956105 From kvn at openjdk.org Sat Aug 30 14:17:45 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 14:17:45 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace In-Reply-To: References: Message-ID: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com> On Sat, 30 Aug 2025 02:21:32 GMT, Ioi Lam wrote: > Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. > > All changes are mechanical text replacement. Headers are resorted alphabetically. Good. @stefank also asked about `INCLUDE_CDS` to replace it with `INCLUDE_AOT`. Should we do this? src/hotspot/share/oops/symbol.cpp line 26: > 24: > 25: #include "cds/archiveBuilder.hpp" > 26: #include "cds/metaspaceShared.hpp" Do you have usage in this file? src/hotspot/share/oops/trainingData.cpp line 26: > 24: > 25: #include "cds/cdsConfig.hpp" > 26: #include "cds/metaspaceShared.hpp" Usage? src/hotspot/share/prims/whitebox.cpp line 2887: > 2885: {CC"incMetaspaceCapacityUntilGC", CC"(J)J", (void*)&WB_IncMetaspaceCapacityUntilGC }, > 2886: {CC"metaspaceCapacityUntilGC", CC"()J", (void*)&WB_MetaspaceCapacityUntilGC }, > 2887: {CC"metaspaceSharedRegionAlignment", CC"()J", (void*)&WB_AOTMetaspaceRegionAlignment }, Should you rename `metaspaceSharedRegionAlignment` too? ------------- PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3171056781 PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3239296387 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311958757 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311958793 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2311959087 From kvn at openjdk.org Sat Aug 30 14:28:43 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 14:28:43 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:35:11 GMT, Ioi Lam wrote: > 1] Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` > > [2] Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27018#pullrequestreview-3171060093 From alanb at openjdk.org Sat Aug 30 15:15:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 30 Aug 2025 15:15:42 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v3] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 05:27:47 GMT, Christian Stein wrote: > > Is there an ETA for integration? > > On September, 1st. I had a brief discussion with Christian about maybe holding off until the TIMEOUT_FACTOR changes (pull/26749) is integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3239335012 From vaivanov at openjdk.org Sat Aug 30 16:04:00 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 30 Aug 2025 16:04:00 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/7bc1b453..a428899b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=02-03 Stats: 19 lines in 1 file changed: 7 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From iklam at openjdk.org Sat Aug 30 17:34:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 17:34:38 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: > Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: > - tests if an object is inside the AOT cache's metaspace region. > > Also various forms of "shared metaspace" are updated to "aot metaspace" > > Please start your review with allocations.hpp Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27016/files - new: https://git.openjdk.org/jdk/pull/27016/files/4c68981a..6b8a1b0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27016/head:pull/27016 PR: https://git.openjdk.org/jdk/pull/27016 From iklam at openjdk.org Sat Aug 30 17:37:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 17:37:33 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v2] In-Reply-To: References: Message-ID: > Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. > > All changes are mechanical text replacement. Headers are resorted alphabetically. 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: - Redo changes in comments and tests - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace - Rename MetaspaceShared -> AOTMetaspace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27017/files - new: https://git.openjdk.org/jdk/pull/27017/files/fc63ba0b..0a425935 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017 PR: https://git.openjdk.org/jdk/pull/27017 From iklam at openjdk.org Sat Aug 30 17:37:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 17:37:42 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: <12PZN2kyxBCAekhzGTgjG8tjTnTp_-uKGgnK6_nQJmU=.142ff531-7701-401b-9eb2-14798a60d920@github.com> On Sat, 30 Aug 2025 14:04:45 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > > test/hotspot/jtreg/runtime/cds/SpaceUtilizationCheck.java line 62: > >> 60: WhiteBox wb = WhiteBox.getWhiteBox(); >> 61: long reserve_alignment = wb.metaspaceSharedRegionAlignment(); >> 62: System.out.println("AOTMetaspace::core_region_alignment() = " + reserve_alignment); > > Here too. I removed these changes and re-applied them in https://github.com/openjdk/jdk/pull/27017 . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27016#discussion_r2312034141 From iklam at openjdk.org Sat Aug 30 18:17:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 18:17:42 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3] In-Reply-To: References: Message-ID: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. > > All changes are mechanical text replacement. Headers are resorted alphabetically. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27017/files - new: https://git.openjdk.org/jdk/pull/27017/files/0a425935..0cadae43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017 PR: https://git.openjdk.org/jdk/pull/27017 From iklam at openjdk.org Sat Aug 30 18:17:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 18:17:43 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3] In-Reply-To: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com> References: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com> Message-ID: On Sat, 30 Aug 2025 14:12:48 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> removed unnecessary includes > > src/hotspot/share/prims/whitebox.cpp line 2887: > >> 2885: {CC"incMetaspaceCapacityUntilGC", CC"(J)J", (void*)&WB_IncMetaspaceCapacityUntilGC }, >> 2886: {CC"metaspaceCapacityUntilGC", CC"()J", (void*)&WB_MetaspaceCapacityUntilGC }, >> 2887: {CC"metaspaceSharedRegionAlignment", CC"()J", (void*)&WB_AOTMetaspaceRegionAlignment }, > > Should you rename `metaspaceSharedRegionAlignment` too? I plan to do more renaming in future RFEs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2312044957 From iklam at openjdk.org Sat Aug 30 18:20:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 30 Aug 2025 18:20:15 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v2] In-Reply-To: References: Message-ID: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` > 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. 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 '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp - 8366477: Refactor AOT-related flag bits in klass.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27018/files - new: https://git.openjdk.org/jdk/pull/27018/files/709d3d23..08d02072 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27018&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27018&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27018/head:pull/27018 PR: https://git.openjdk.org/jdk/pull/27018 From kvn at openjdk.org Sat Aug 30 19:47:41 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 19:47:41 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 Update is good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3171200791 From kvn at openjdk.org Sat Aug 30 19:48:42 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 30 Aug 2025 19:48:42 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3] In-Reply-To: References: Message-ID: <_Pwid_3zsEZoZFjGZhCUZniTGzkDyYNCCKzuOfxLVd8=.2e880d87-78d6-4266-958a-caad69d2da1a@github.com> On Sat, 30 Aug 2025 18:17:42 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. >> >> All changes are mechanical text replacement. Headers are resorted alphabetically. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > removed unnecessary includes Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3171201064 From dholmes at openjdk.org Sun Aug 31 21:37:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Aug 2025 21:37:48 GMT Subject: Integrated: 8347707: Standardise the use of os::snprintf and os::snprintf_checked In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 22:02:30 GMT, David Holmes wrote: > This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) > > From: https://bugs.openjdk.org/browse/JDK-8347707 > > The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. > > To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. > > The potential errors are, generally speaking, not something we should encounter in our own well-written code: > > - encoding error: not applicable as we are not using extended character sets > - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) > - mal-formed formatting directives > - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). > > As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. > > The potential clients of this API then fall into a number of camps: > > 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. > > For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. > > 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. > > For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. > > 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. > > These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing decisions, but in product mode truncation is not an error. > ... This pull request has now been integrated. Changeset: 80ab094a Author: David Holmes URL: https://git.openjdk.org/jdk/commit/80ab094a75a6474c33214e3347e08ea7b9177ec8 Stats: 202 lines in 46 files changed: 19 ins; 7 del; 176 mod 8347707: Standardise the use of os::snprintf and os::snprintf_checked Reviewed-by: kbarrett, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/26849 From dholmes at openjdk.org Sun Aug 31 21:37:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Aug 2025 21:37:47 GMT Subject: RFR: 8347707: Standardise the use of os::snprintf and os::snprintf_checked [v2] In-Reply-To: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> References: <8CSDwu2qcx-W9VayeiF9JBkpx1a62ZqXDMdUMyEhFL8=.1e59b6d2-e30a-4af5-b088-8388ebab5217@github.com> Message-ID: On Thu, 21 Aug 2025 06:46:03 GMT, David Holmes wrote: >> This is a proposal to standardize on the use of `os::snprintf` and `os::snprintf`_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of `jio_printf` at all.) >> >> From: https://bugs.openjdk.org/browse/JDK-8347707 >> >> The platform `snprintf/vsnprintf` returns -1 on error, else if the buffer is large enough returns the number of bytes written (excluding the null byte), else (buffer is too small) the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. >> >> To provide a consistent approach to error handling and truncation management, we provide `os::xxx` wrapper functions as described below and forbid the use of the library `::vsnprintf` and `::snprintf`. >> >> The potential errors are, generally speaking, not something we should encounter in our own well-written code: >> >> - encoding error: not applicable as we are not using extended character sets >> - invalid parameters (null buffers, specifying a limit > size of the buffer [Windows], things of this nature) >> - mal-formed formatting directives >> - overflow error (POSIX) if the required buffer size exceeds INT_MAX (as we return `int`). >> >> As these should simply never occur, we handle the checks for -1 at the lowest-level (`os::vsnprintf`) with an assertion, and accompanying precondition assertions. >> >> The potential clients of this API then fall into a number of camps: >> >> 1. Those who have sized their buffer correctly, don't need the return value for subsequent use, and for whom truncation (if it were possible) would be a programming error. >> >> For these clients we have `void os::snprintf_checked` - which returns nothing and asserts on truncation. >> >> 2. Those who have sized their buffer correctly, but do need the return value for subsequent operations (e.g. chains of `snprintf` where you advance the buffer pointer based on previous writes), but again for whom truncation should never happen. >> >> For these clients we have `os::snprintf`, but they have to add their own assertion for no truncation. >> >> 3. Those who present a buffer but know that truncation is a possibility, but don't need to do anything about it themselves, and for whom the return value is of no use. >> >> These clients also use `os::snprintf_checked`. The truncation assertion can be useful for guiding buffer sizing... > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Note, before integrating I merged locally with master, checked the incoming changes and re-ran tier 1-3 builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26849#issuecomment-3240430237