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