From kbarrett at openjdk.org Wed Oct 1 04:02:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 1 Oct 2025 04:02:05 GMT Subject: Integrated: 8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain In-Reply-To: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com> References: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com> Message-ID: On Tue, 30 Sep 2025 02:53:00 GMT, Kim Barrett wrote: > Please review this change to JDK_Version::to_string to use stringStream to > accumulate the version string in the buffer, rather than using jio_snprintf to > write the various pieces. > > Testing: mach5 tier1 > Locally manually examined result of JDK_Version for builds configured with > different values for various version parameters. This pull request has now been integrated. Changeset: 8c3ca024 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/8c3ca024c770d3cf3b35234e967e5f0f0d610388 Stats: 17 lines in 1 file changed: 0 ins; 10 del; 7 mod 8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain Reviewed-by: fandreuzzi, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27567 From kbarrett at openjdk.org Wed Oct 1 04:02:04 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 1 Oct 2025 04:02:04 GMT Subject: RFR: 8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain In-Reply-To: References: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com> Message-ID: On Tue, 30 Sep 2025 07:54:21 GMT, Francesco Andreuzzi wrote: >> Please review this change to JDK_Version::to_string to use stringStream to >> accumulate the version string in the buffer, rather than using jio_snprintf to >> write the various pieces. >> >> Testing: mach5 tier1 >> Locally manually examined result of JDK_Version for builds configured with >> different values for various version parameters. > > Marked as reviewed by fandreuzzi (Author). Thanks for reviews @fandreuz and @jdksjolen ------------- PR Comment: https://git.openjdk.org/jdk/pull/27567#issuecomment-3354631422 From ayang at openjdk.org Wed Oct 1 08:52:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 1 Oct 2025 08:52:21 GMT Subject: RFR: 8368938: Remove ObjectWaiter::badObjectWaiterPtr [v3] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 11:38:29 GMT, Francesco Andreuzzi wrote: >> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > include I think having a static `badObjectWaiterPtr` conveys the intention more clearly, but up to you. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27571#pullrequestreview-3288152045 From fandreuzzi at openjdk.org Wed Oct 1 09:02:28 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 09:02:28 GMT Subject: RFR: 8368938: Remove ObjectWaiter::badObjectWaiterPtr [v3] In-Reply-To: References: Message-ID: <5w0hqKhHUDRNGGR1LttQc6tBMfF5wY553ao6OHiMfFE=.fba2d8c7-947e-4c7c-88f7-b9378babce02@github.com> On Wed, 1 Oct 2025 08:49:34 GMT, Albert Mingkun Yang wrote: > I think having a static badObjectWaiterPtr conveys the intention more clearly, but up to you. I don't have a strong opinion about this, my only push towards the global constant is that we can easily search all usages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27571#issuecomment-3355388997 From jsjolen at openjdk.org Wed Oct 1 09:04:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 1 Oct 2025 09:04:39 GMT Subject: Integrated: 8368885: NMT CommandLine tests can check for error better In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:52:01 GMT, Johan Sj?len wrote: > We can check for more specific error text when running the command line tests, the current 'error' string check misses NMT parsing succeeding but NMT initialization failure. > > We also fix the indentation of the test files, let's use 4 spaces in the Java source files. This pull request has now been integrated. Changeset: 84e5d63b Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/84e5d63b9fa8af0b35e1d682a81900cb157697fe Stats: 22 lines in 2 files changed: 2 ins; 0 del; 20 mod 8368885: NMT CommandLine tests can check for error better Reviewed-by: phubner, azafari, shade ------------- PR: https://git.openjdk.org/jdk/pull/27554 From schernyshev at openjdk.org Wed Oct 1 12:50:49 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 1 Oct 2025 12:50:49 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux. >> >> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. >> >> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. >> >> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. >> >> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). >> >> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. >> >> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8319589 > - Removed unused native method > - addressed review comment #2 > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > Co-authored-by: Andrey Turbanov > - addressed review comments > - 8319589: Attach from root to a user java process not supported in Mac @sspitsyn Could you please have a look at this PR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3356063722 From jkern at openjdk.org Wed Oct 1 14:26:48 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 1 Oct 2025 14:26:48 GMT Subject: RFR: 8368997: AIX allows reading from address zero which leads to several ubsan findings Message-ID: In _SafeFetchXX_internal() a pointer is checked for readability before using. It returns false if this is not the case. The implementation tries to read from the pointer if this is not feasible the signal handler comes into place jumping back to the function via longjmp, so the _SafeFetchXX_internal() itself can return with a false and a null as pseudo content of the address. If the address was readable the function returns true and provides the content of the address. Because AIX allows reading from address zero, _SafeFetchXX_internal() returns true and follow up functions using the address are called. All these functions end up in an UBSAN finding regarding reading from zero. The solution could be to manually code that also AIX behaves like other operating systems and returns false and the content zero in case of address zero. Then no UBSAN finding occur. ------------- Commit messages: - JDK-8368997 Changes: https://git.openjdk.org/jdk/pull/27591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368997 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27591/head:pull/27591 PR: https://git.openjdk.org/jdk/pull/27591 From fandreuzzi at openjdk.org Wed Oct 1 14:28:28 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 14:28:28 GMT Subject: RFR: 8368938: Remove ObjectWaiter::badObjectWaiterPtr [v3] In-Reply-To: <4oeODpbnRQ2f-54LQt3U2OYRkP2Ul6088ysaGk-nB_8=.42d89cbd-f612-4d8d-8be5-9c4c178c7b93@github.com> References: <4oeODpbnRQ2f-54LQt3U2OYRkP2Ul6088ysaGk-nB_8=.42d89cbd-f612-4d8d-8be5-9c4c178c7b93@github.com> Message-ID: <0RUR5YWkhUtvBM2afXmDue_yxuY10C-6u_BXAXhWeSM=.550ce062-a5ce-4f49-9805-1099b1c0e9f9@github.com> On Tue, 30 Sep 2025 15:20:55 GMT, Aleksey Shipilev wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> include > > I am good with switching to `badAddressVal` for this, thanks! Thanks for the review @shipilev and @albertnetymk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27571#issuecomment-3356601420 From duke at openjdk.org Wed Oct 1 14:28:30 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Oct 2025 14:28:30 GMT Subject: RFR: 8368938: Remove ObjectWaiter::badObjectWaiterPtr [v3] In-Reply-To: References: Message-ID: <9EjAICJYhKlQOkrE1fUmmC8g0dSRRj40AgVMG1C4iuw=.ba576d3f-a77a-41af-8cd6-a05c04ab9432@github.com> On Tue, 30 Sep 2025 11:38:29 GMT, Francesco Andreuzzi wrote: >> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > include @fandreuz Your change (at version b9eb7c4c6df5d10e08b4917922fea42fcb242fcf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27571#issuecomment-3356612094 From fandreuzzi at openjdk.org Wed Oct 1 15:02:36 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 15:02:36 GMT Subject: Integrated: 8368938: Remove ObjectWaiter::badObjectWaiterPtr In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 10:11:34 GMT, Francesco Andreuzzi wrote: > There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`. > > Passes tier1 and tier2 (fastdebug). This pull request has now been integrated. Changeset: c54dcefb Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c54dcefbfd2eb44a569767740dc053813c4f6fe1 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod 8368938: Remove ObjectWaiter::badObjectWaiterPtr Reviewed-by: shade, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27571 From pchilanomate at openjdk.org Wed Oct 1 23:38:24 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 1 Oct 2025 23:38:24 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support Message-ID: Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/27597/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369019 Stats: 155 lines in 4 files changed: 143 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From dholmes at openjdk.org Thu Oct 2 04:05:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Oct 2025 04:05:46 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 16:20:11 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio For AsyncExceptionTest.java I have one issue - see below. Looking at AsyncExceptionOnMonitorEnter.java we seem to be making a number of assumptions based on the fact we only have real platform threads: 1. An async exception is either thrown before we start the monitorenter, or else after we are blocked (is this true? we never used to be able to unblock a monitor acquisition via stop() because the code will still try to unlock it???) 2. We can safely hit `Thread.sleep` with an async exception without breaking anything. Aside: > // Don't stop() worker1 with JVMTI raw monitors since if the monitor is not released worker2 will deadlock on enter Pre-existing but surely the rawMonitorExit should be in a finally block to avoid this problem. Thanks test/hotspot/jtreg/runtime/Thread/AsyncExceptionTest.java line 82: > 80: public void internalRun1() { > 81: started = true; > 82: try { You need to move the setting of `started` to inside the try block else you could throw outside the range of the catch. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27582#pullrequestreview-3292062215 PR Review Comment: https://git.openjdk.org/jdk/pull/27582#discussion_r2396634482 From dholmes at openjdk.org Thu Oct 2 04:46:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Oct 2025 04:46:45 GMT Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len wrote: > Hi, > > `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not. > > We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is. Fix looks good - thanks. My own view is that `(p - signature) > 1` was a mal-formed attempt at checking at least one more character was present. src/hotspot/share/classfile/classFileParser.cpp line 4688: > 4686: // The next character better be a semicolon > 4687: if (p != nullptr && // Parse of field name succeeded. > 4688: p - signature < static_cast(length) && // There is at least one character left to parse. Suggestion: if (p != nullptr && // Parse of field name succeeded. p - signature < static_cast(length) && // There is at least one character left to parse. I'm not a fan of this kind of alignment but lets at least not add unnecessary whitespace. :) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27528#pullrequestreview-3292254739 PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2396815363 From dholmes at openjdk.org Thu Oct 2 05:38:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Oct 2025 05:38:48 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:13:58 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio src/hotspot/share/runtime/objectMonitor.cpp line 988: > 986: > 987: // If there are unmounted virtual threads ahead in the _entry_list we want > 988: // to do a timed-park instead to alleviate some deadlocks cases where one Suggestion: // to do a timed-park instead to alleviate some deadlock cases where one src/hotspot/share/runtime/objectMonitor.cpp line 997: > 995: // prevents this load from floating up previous store. > 996: // Note that we can have false positives where timed-park is not necessary. > 997: bool do_timed_parked = has_unmounted_vthreads(); Don't we still only need the timed-park if the current thread is a pinned vthread? src/hotspot/share/runtime/objectMonitor.cpp line 1095: > 1093: > 1094: // If there are unmounted virtual threads ahead in the _entry_list we want > 1095: // to do a timed-park instead to alleviate some deadlocks cases where one Suggestion: // to do a timed-park instead to alleviate some deadlock cases where one ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2396996314 PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2397010146 PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2397000418 From duke at openjdk.org Thu Oct 2 08:33:48 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 08:33:48 GMT Subject: RFR: 8363440: Upgrade AOT map file logging to display more assets and asset content Message-ID: Part of https://bugs.openjdk.org/browse/JDK-8363440 The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. Before: $ cat aot.map | grep "@@ MethodCounters" [...] 0x0000000801e4c280: @@ MethodCounters 64 ``` bash $ cat aot.map | grep "@@ MethodData" [...] 0x0000000801e44448: @@ MethodData 584 After: $ cat aot.map | grep "@@ MethodCounters" [...] 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() ``` bash $ cat aot.map | grep "@@ MethodData" [...] 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) ------------- Commit messages: - JDK-8363440: Adding the method name to MethodCounters and MethodData Changes: https://git.openjdk.org/jdk/pull/27603/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363440 Stats: 22 lines in 2 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From mbaesken at openjdk.org Thu Oct 2 08:33:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 2 Oct 2025 08:33:53 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent Message-ID: Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. ------------- Commit messages: - JDK-8368781 Changes: https://git.openjdk.org/jdk/pull/27602/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368781 Stats: 67 lines in 4 files changed: 3 ins; 0 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From duke at openjdk.org Thu Oct 2 08:40:25 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 08:40:25 GMT Subject: RFR: 8363440: Upgrade AOT map file logging to display more assets and asset content In-Reply-To: References: Message-ID: <3SQLDtcl0PEzkmgseHTHP4jJnAtbCJDj4rHupp2zH2I=.a12ea099-f90c-4e4c-8b8e-103d2869384d@github.com> On Thu, 2 Oct 2025 08:26:54 GMT, Mar?a Arias de Reyna wrote: > Part of https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) trying to restart the tests (I didn't configure actions on my github fork, sorry) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3359886057 From duke at openjdk.org Thu Oct 2 08:51:22 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 08:51:22 GMT Subject: RFR: 8363440: Upgrade AOT map file logging to display more assets and asset content [v2] In-Reply-To: References: Message-ID: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> > Part of https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) Mar?a Arias de Reyna has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8363440: Adding the Method name to MethodCounters and MethodData ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27603/files - new: https://git.openjdk.org/jdk/pull/27603/files/7137a130..7b317990 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From duke at openjdk.org Thu Oct 2 08:51:23 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 08:51:23 GMT Subject: RFR: 8363440: Upgrade AOT map file logging to display more assets and asset content In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 08:26:54 GMT, Mar?a Arias de Reyna wrote: > Part of https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) I know, bot, but wanted a clean trigger of the jobs in my repository. And no one has reviewed anything yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3359929086 From adinn at openjdk.org Thu Oct 2 09:16:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 09:16:46 GMT Subject: RFR: 8363440: Upgrade AOT map file logging to display more assets and asset content In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 08:47:54 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8363440 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > I know, bot, but wanted a clean trigger of the jobs in my repository. And no one has reviewed anything yet. @Delawen > Part of https://bugs.openjdk.org/browse/JDK-8363440 As this is only the first of several potential improvements I think you should create a subtask issue from the above one and then address this PR to the subtask. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3360056239 From duke at openjdk.org Thu Oct 2 09:28:47 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 09:28:47 GMT Subject: RFR: 8369037: Upgrade AOT map file logging to display more assets and asset content [v2] In-Reply-To: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> References: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> Message-ID: On Thu, 2 Oct 2025 08:51:22 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8363440: Adding the Method name to MethodCounters and MethodData Adding it as subtask of the parent task because image Changed the related issue ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3360100259 PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3360109760 From adinn at openjdk.org Thu Oct 2 09:42:58 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 09:42:58 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v2] In-Reply-To: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> References: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> Message-ID: On Thu, 2 Oct 2025 08:51:22 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8363440: Adding the Method name to MethodCounters and MethodData Hmm, no subtasks of subtasks? Ok . . . adding to the main umbrella task will do. You still need to align the new issue title and the title of this PR: I'd suggest "8369037: Identify owning method for MethodData and MethodCounters in AOT map output" Also, in the description for this PR you need to refer to the correct related issue: "Part of https://bugs.openjdk.org/browse/JDK-8363440" ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3360172196 From duke at openjdk.org Thu Oct 2 11:13:24 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 11:13:24 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v3] In-Reply-To: References: Message-ID: <3ijjaKUZTUPsWex94CdLxTJmpEnK3m-A1mnxbuZC2t0=.c0927ac5-33b7-4bb1-a7f8-6d7e8702e057@github.com> > Part of https://bugs.openjdk.org/browse/JDK-8369037 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: Adding includes of mthodCounters and methodData headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27603/files - new: https://git.openjdk.org/jdk/pull/27603/files/7b317990..efb301d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From jsjolen at openjdk.org Thu Oct 2 11:56:45 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 2 Oct 2025 11:56:45 GMT Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature [v2] In-Reply-To: References: Message-ID: > Hi, > > `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not. > > We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/classfile/classFileParser.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27528/files - new: https://git.openjdk.org/jdk/pull/27528/files/75709361..f6b89402 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27528&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27528/head:pull/27528 PR: https://git.openjdk.org/jdk/pull/27528 From jsikstro at openjdk.org Thu Oct 2 13:30:02 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 2 Oct 2025 13:30:02 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag. > > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Namings and comment - 8367413: Refactor types in Arguments::set_heap_size() - Merge branch 'master' into JDK-8367413_arguments_sizet_julong - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp" This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8. - Revert "size_t casts for 32-bit part of test_arguments.cpp" This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625. - size_t casts for 32-bit part of test_arguments.cpp - 8367413: Use size_t instead of julong in runtime/arguments.cpp ------------- Changes: https://git.openjdk.org/jdk/pull/27224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=02 Stats: 92 lines in 4 files changed: 20 ins; 23 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From jsikstro at openjdk.org Thu Oct 2 13:33:00 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 2 Oct 2025 13:33:00 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 13:30:02 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag. >> >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Namings and comment > - 8367413: Refactor types in Arguments::set_heap_size() > - Merge branch 'master' into JDK-8367413_arguments_sizet_julong > - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp" > > This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8. > - Revert "size_t casts for 32-bit part of test_arguments.cpp" > > This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625. > - size_t casts for 32-bit part of test_arguments.cpp > - 8367413: Use size_t instead of julong in runtime/arguments.cpp [JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485) is now integrated. I've changed the direction of this issue a bit. I now focus on makus sure the transition from uint64_t to size_t is handled robustly along with adding comments to make things easier to understand in `Arguments::set_heap_size()`. Setting `MaxRAM` to `MIN2(MaxRAM, (uint64_t) ms.ullTotalVirtual)` on Windows was only needed on 32-bit, which is no longer supported. So I've gone ahead and removed it. The virtual address space will practically always be extremely large on Windows 64-bit. See the following resources for more information: https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases https://learn.microsoft.com/en-us/windows-server/get-started/locks-limits?tabs=full-comparison&pivots=windows-server-2025 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3361236605 From eosterlund at openjdk.org Thu Oct 2 13:36:54 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 2 Oct 2025 13:36:54 GMT Subject: RFR: 8292984: Refactor internal container-related interfaces for clarity [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 08:45:38 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers. >> >> For example, consider the call sequence for `os::available_memory()`: >> >> os::available_memory() >> | >> v >> os::Linux::available_memory() >> |-------------------------------------------- >> v v >> OSContainer::memory_limit_in_bytes() or return host physical memory >> | >> v >> CgroupSubsystem::memory_limit_in_bytes() >> |-------------------------------------------- >> v v >> return os::Linux::physical_memory() or return cgroup v1/v2 limit >> >> >> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality: >> * `os::Linux` should focus solely on actual machine memory values. >> * `CgroupSubsystem` should focus exclusively on cgroup memory limits. >> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized. >> >> >> A revised structure separates these responsibilities: >> >> os::available_memory() >> |-------------------------------------------- >> v v >> OSContainer::memory_limit_in_bytes() or os::Linux::available_memory() >> |-------------------------------------------- >> v v >> CgroupSubsystem::memory_limit_in_bytes() os::Linux::physical_memory() >> | >> v >> return bounded cgroup v1/v2 limit >> >> >> With these changes: >> * `os::Linux` only retrieves machine values. >> * `CgroupSubsystem` works exclusively with cgroup limits. >> * `OSContainer` fetches and passes bounds for the cgroup values. >> * The decision of container or machine value is done in the `os` layer. >> >> The concrete code changes include: >> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`). >> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also ref... > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into linux-container-mem-restructure > - keep cgroupsubsystem separate > - keep os::linux separate Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27470#pullrequestreview-3294664653 From cnorrbin at openjdk.org Thu Oct 2 13:41:04 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 2 Oct 2025 13:41:04 GMT Subject: RFR: 8292984: Refactor internal container-related interfaces for clarity [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 08:45:38 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers. >> >> For example, consider the call sequence for `os::available_memory()`: >> >> os::available_memory() >> | >> v >> os::Linux::available_memory() >> |-------------------------------------------- >> v v >> OSContainer::memory_limit_in_bytes() or return host physical memory >> | >> v >> CgroupSubsystem::memory_limit_in_bytes() >> |-------------------------------------------- >> v v >> return os::Linux::physical_memory() or return cgroup v1/v2 limit >> >> >> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality: >> * `os::Linux` should focus solely on actual machine memory values. >> * `CgroupSubsystem` should focus exclusively on cgroup memory limits. >> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized. >> >> >> A revised structure separates these responsibilities: >> >> os::available_memory() >> |-------------------------------------------- >> v v >> OSContainer::memory_limit_in_bytes() or os::Linux::available_memory() >> |-------------------------------------------- >> v v >> CgroupSubsystem::memory_limit_in_bytes() os::Linux::physical_memory() >> | >> v >> return bounded cgroup v1/v2 limit >> >> >> With these changes: >> * `os::Linux` only retrieves machine values. >> * `CgroupSubsystem` works exclusively with cgroup limits. >> * `OSContainer` fetches and passes bounds for the cgroup values. >> * The decision of container or machine value is done in the `os` layer. >> >> The concrete code changes include: >> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`). >> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also ref... > > Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into linux-container-mem-restructure > - keep cgroupsubsystem separate > - keep os::linux separate Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27470#issuecomment-3361266047 From cnorrbin at openjdk.org Thu Oct 2 13:41:05 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 2 Oct 2025 13:41:05 GMT Subject: Integrated: 8292984: Refactor internal container-related interfaces for clarity In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:55:35 GMT, Casper Norrbin wrote: > Hi everyone, > > The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers. > > For example, consider the call sequence for `os::available_memory()`: > > os::available_memory() > | > v > os::Linux::available_memory() > |-------------------------------------------- > v v > OSContainer::memory_limit_in_bytes() or return host physical memory > | > v > CgroupSubsystem::memory_limit_in_bytes() > |-------------------------------------------- > v v > return os::Linux::physical_memory() or return cgroup v1/v2 limit > > > This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality: > * `os::Linux` should focus solely on actual machine memory values. > * `CgroupSubsystem` should focus exclusively on cgroup memory limits. > * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized. > > > A revised structure separates these responsibilities: > > os::available_memory() > |-------------------------------------------- > v v > OSContainer::memory_limit_in_bytes() or os::Linux::available_memory() > |-------------------------------------------- > v v > CgroupSubsystem::memory_limit_in_bytes() os::Linux::physical_memory() > | > v > return bounded cgroup v1/v2 limit > > > With these changes: > * `os::Linux` only retrieves machine values. > * `CgroupSubsystem` works exclusively with cgroup limits. > * `OSContainer` fetches and passes bounds for the cgroup values. > * The decision of container or machine value is done in the `os` layer. > > The concrete code changes include: > * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`). > * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also refactored to use the new bool and reference interface introduced in [JDK-8357086](https://bugs.openjdk... This pull request has now been integrated. Changeset: 52522623 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/5252262349cccb09f693ebd431fe2987ec0917f0 Stats: 135 lines in 9 files changed: 32 ins; 27 del; 76 mod 8292984: Refactor internal container-related interfaces for clarity Reviewed-by: sgehwolf, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/27470 From asmehra at openjdk.org Thu Oct 2 14:31:24 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 2 Oct 2025 14:31:24 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v3] In-Reply-To: <3ijjaKUZTUPsWex94CdLxTJmpEnK3m-A1mnxbuZC2t0=.c0927ac5-33b7-4bb1-a7f8-6d7e8702e057@github.com> References: <3ijjaKUZTUPsWex94CdLxTJmpEnK3m-A1mnxbuZC2t0=.c0927ac5-33b7-4bb1-a7f8-6d7e8702e057@github.com> Message-ID: On Thu, 2 Oct 2025 11:13:24 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: > > Adding includes of mthodCounters and methodData headers lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/27603#pullrequestreview-3294928831 From adinn at openjdk.org Thu Oct 2 14:39:10 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 14:39:10 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v3] In-Reply-To: <3ijjaKUZTUPsWex94CdLxTJmpEnK3m-A1mnxbuZC2t0=.c0927ac5-33b7-4bb1-a7f8-6d7e8702e057@github.com> References: <3ijjaKUZTUPsWex94CdLxTJmpEnK3m-A1mnxbuZC2t0=.c0927ac5-33b7-4bb1-a7f8-6d7e8702e057@github.com> Message-ID: On Thu, 2 Oct 2025 11:13:24 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: > > Adding includes of mthodCounters and methodData headers Looks ok to me too but perhaps @iklam would like to confirm. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27603#pullrequestreview-3294961485 From duke at openjdk.org Thu Oct 2 14:42:22 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 14:42:22 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v4] In-Reply-To: References: Message-ID: > Part of https://bugs.openjdk.org/browse/JDK-8369037 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27603/files - new: https://git.openjdk.org/jdk/pull/27603/files/efb301d2..b36e4408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From adinn at openjdk.org Thu Oct 2 14:57:38 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 14:57:38 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v2] In-Reply-To: References: <-9guhTcAQZDl4jnRpmCUy0pHubHiwv7O4qJzKUs8SLc=.8b7d3028-f610-4985-a568-f0bfcb416463@github.com> Message-ID: On Thu, 2 Oct 2025 09:26:05 GMT, Mar?a Arias de Reyna wrote: >> Mar?a Arias de Reyna has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> JDK-8363440: Adding the Method name to MethodCounters and MethodData > > Changed the related issue @Delawen You still need to update the first line of this PR description. It says this PR is "Part of JDK-8369037" i.e. the JIRA issue this PR is raised against. What it should say is that this PR "Provides part of fixes needed to resolve JDK-8363440". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27603#issuecomment-3361594046 From liach at openjdk.org Thu Oct 2 15:47:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 2 Oct 2025 15:47:53 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v4] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 14:42:22 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: > > Update full name src/hotspot/share/cds/aotMapLogger.cpp line 401: > 399: > 400: void AOTMapLogger::log_method_counter(MethodCounters* mc, address requested_addr, const char* type_name, > 401: int bytes, Thread* current) { I think our preferred code style is to align continued parameters with the `(`. Same for other 3 places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27603#discussion_r2399267315 From jwaters at openjdk.org Thu Oct 2 16:23:41 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 2 Oct 2025 16:23:41 GMT Subject: RFR: 8367984: Eliminate offset_of in vmStructs In-Reply-To: <__SmTPxscRXLzen7lQ8ZE7nQOvcGfXGSE51UK41hHfI=.c3e35b17-d7ce-4c64-b70c-df37511a322e@github.com> References: <__SmTPxscRXLzen7lQ8ZE7nQOvcGfXGSE51UK41hHfI=.c3e35b17-d7ce-4c64-b70c-df37511a322e@github.com> Message-ID: On Thu, 18 Sep 2025 12:49:10 GMT, Francesco Andreuzzi wrote: >> There are several usages of `offset_of` in `vmStructs`, they can be replaced with standard `offsetof` due to [JDK-8367016](https://bugs.openjdk.org/browse/JDK-8367016). >> >> Passes `tier1`. > > src/hotspot/share/runtime/vmStructs.cpp line 1984: > >> 1982: >> 1983: JNIEXPORT VMStructEntry* gHotSpotVMStructs = VMStructs::localHotSpotVMStructs; >> 1984: extern JNIEXPORT constexpr uint64_t gHotSpotVMStructEntryTypeNameOffset = offsetof(VMStructEntry, typeName); > > I got a partial understanding about this change, I thought having `JNIEXPORT` and `constexpr` together wouldn't work. But the symbols are exported: > > objdump --syms build/gcc/jdk/lib/server/libjvm.so | grep gHotSpotVMTypeEntryIsIntegerTypeOffset > 000000000137ca78 g O .rodata 0000000000000008 gHotSpotVMTypeEntryIsIntegerTypeOffset > > and I tested that the values are still readable. I was wondering if this wouldn't be portable? I believe constexpr means the entity marked as a constant expression will be treated as such if conditions allow it to be used as a compile time constant, and doesn't mean it will disappear from the final binary entirely. Since JNIEXPORT exports the symbol from HotSpot, it is obviously used and the compiler takes note of that, hence allowing it to be JNIEXPORT despite being constexpr Also I think the JNIEXPORT would preferably be in front of the extern (Actually, could I ask why extern is required here?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27362#discussion_r2399361039 From duke at openjdk.org Thu Oct 2 17:16:41 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 17:16:41 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v5] In-Reply-To: References: Message-ID: > Part of https://bugs.openjdk.org/browse/JDK-8369037 > Provides part of fixes needed to resolve https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: Fixing style: aligning parameters with '(' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27603/files - new: https://git.openjdk.org/jdk/pull/27603/files/b36e4408..76e3a5a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From duke at openjdk.org Thu Oct 2 17:16:43 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 17:16:43 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v4] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:12 GMT, Chen Liang wrote: >> Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: >> >> Update full name > > src/hotspot/share/cds/aotMapLogger.cpp line 401: > >> 399: >> 400: void AOTMapLogger::log_method_counter(MethodCounters* mc, address requested_addr, const char* type_name, >> 401: int bytes, Thread* current) { > > I think our preferred code style is to align continued parameters with the `(`. Same for other 3 places. Fixed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27603#discussion_r2399513084 From macarte at openjdk.org Thu Oct 2 17:49:42 2025 From: macarte at openjdk.org (Mat Carter) Date: Thu, 2 Oct 2025 17:49:42 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v5] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 17:16:41 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> Provides part of fixes needed to resolve https://bugs.openjdk.org/browse/JDK-8363440 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: > > Fixing style: aligning parameters with '(' Marked as reviewed by macarte (Author). src/hotspot/share/cds/aotMapLogger.cpp line 400: > 398: } > 399: > 400: void AOTMapLogger::log_method_counter(MethodCounters* mc, address requested_addr, const char* type_name, nit: perhaps name this log_method_counters [plural case] for consistency in the code ------------- PR Review: https://git.openjdk.org/jdk/pull/27603#pullrequestreview-3295737165 PR Review Comment: https://git.openjdk.org/jdk/pull/27603#discussion_r2399602398 From duke at openjdk.org Thu Oct 2 17:58:59 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 17:58:59 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v6] In-Reply-To: References: Message-ID: > Part of https://bugs.openjdk.org/browse/JDK-8369037 > Provides part of fixes needed to resolve https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: Using plural for method name for consistency in the code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27603/files - new: https://git.openjdk.org/jdk/pull/27603/files/76e3a5a0..febffa73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27603&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27603/head:pull/27603 PR: https://git.openjdk.org/jdk/pull/27603 From duke at openjdk.org Thu Oct 2 17:59:02 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 2 Oct 2025 17:59:02 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v5] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 17:46:53 GMT, Mat Carter wrote: >> Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing style: aligning parameters with '(' > > src/hotspot/share/cds/aotMapLogger.cpp line 400: > >> 398: } >> 399: >> 400: void AOTMapLogger::log_method_counter(MethodCounters* mc, address requested_addr, const char* type_name, > > nit: perhaps name this log_method_counters [plural case] for consistency in the code Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27603#discussion_r2399615390 From iklam at openjdk.org Thu Oct 2 18:49:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 2 Oct 2025 18:49:12 GMT Subject: RFR: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output [v6] In-Reply-To: References: Message-ID: <9kFx8l4TxiCbvYWHvO0T7hAcNH3pxuyvM5W-gIMlxao=.b8d7f999-2ef6-4776-bbc8-f7db215aa1f6@github.com> On Thu, 2 Oct 2025 17:58:59 GMT, Mar?a Arias de Reyna wrote: >> Part of https://bugs.openjdk.org/browse/JDK-8369037 >> Provides part of fixes needed to resolve https://bugs.openjdk.org/browse/JDK-8363440 >> >> The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. >> >> Before: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801e4c280: @@ MethodCounters 64 >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801e44448: @@ MethodData 584 >> >> >> After: >> >> $ cat aot.map | grep "@@ MethodCounters" >> [...] >> 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) >> 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() >> >> ``` bash >> $ cat aot.map | grep "@@ MethodData" >> [...] >> 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() >> 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) > > Mar?a Arias de Reyna has updated the pull request incrementally with one additional commit since the last revision: > > Using plural for method name for consistency in the code. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27603#pullrequestreview-3295954780 From pchilanomate at openjdk.org Thu Oct 2 20:34:02 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 2 Oct 2025 20:34:02 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v2] In-Reply-To: References: Message-ID: > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: David's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27582/files - new: https://git.openjdk.org/jdk/pull/27582/files/d3a478cf..0f566c09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=00-01 Stats: 13 lines in 2 files changed: 7 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27582.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27582/head:pull/27582 PR: https://git.openjdk.org/jdk/pull/27582 From pchilanomate at openjdk.org Thu Oct 2 20:40:48 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 2 Oct 2025 20:40:48 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 04:03:18 GMT, David Holmes wrote: > For AsyncExceptionTest.java I have one issue - see below. > > Looking at AsyncExceptionOnMonitorEnter.java we seem to be making a number of assumptions based on the fact we only have real platform threads: > > 1. An async exception is either thrown before we start the monitorenter, or else after we are blocked (is this true? we never used to be able to unblock a monitor acquisition via stop() because the code will still try to unlock it???) > So the stopThread operation will only install the async exception handshake. If the target is blocked on monitorenter (or RawMonitorEnter) the handshake won?t be processed until the target acquires the monitor and transitions back to Java. There is a slight difference here between testWithJavaMonitor and testWithJVMTIRawMonitor. enterRawMonitor is a native method so we will throw the exception on return from it. The call to monitorenter uses JRT_ENTRY_NO_ASYNC which doesn?t process the async exceptions. So for testWithJavaMonitor the exception will be likely thrown during Thread.sleep (don?t see other obvious safepoint polls in the bytecodes). > 2. We can safely hit `Thread.sleep` with an async exception without breaking anything. > Yes. The stopThread handshake will unpark the target after adding the async handshake. The target will see the async condition on wake up and return to Java where the exception will be thrown. > Aside: > > > // Don't stop() worker1 with JVMTI raw monitors since if the monitor is not released worker2 will deadlock on enter > > Pre-existing but surely the rawMonitorExit should be in a finally block to avoid this problem. > Ok, I added it but I had to also restrict sending stopThread to only one time for this case. Otherwise the next async exception could be thrown at the finally block before releasing the monitor, causing the same deadlock. In practice I think this should never happen though, except the first time we resolve the call to `exitRawMonitor`, because we first call `InterpreterRuntime::resolve_from_cache` and the exception could be installed there. Also although unlikely, the target could have already released the raw monitor when it throws the exception. So in the finally block the call to `RawMonitorExit` would return `JVMTI_ERROR_NOT_MONITOR_OWNER`. The test will not fail but we just print an error message. We could skip it like with destroyRawMonitor. > test/hotspot/jtreg/runtime/Thread/AsyncExceptionTest.java line 82: > >> 80: public void internalRun1() { >> 81: started = true; >> 82: try { > > You need to move the setting of `started` to inside the try block else you could throw outside the range of the catch. Right, fixed. Although the one in `testWithJVMTIRawMonitor` won?t cause the test to fail I moved it inside the try block too just for consistency. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27582#issuecomment-3362871360 PR Review Comment: https://git.openjdk.org/jdk/pull/27582#discussion_r2400006650 From dholmes at openjdk.org Fri Oct 3 06:21:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Oct 2025 06:21:46 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v2] In-Reply-To: References: Message-ID: <1uOtOSsKH5YeIJfJwYw9_m5n3HzKOENk5pl4bwQHPrA=.0606ad65-fbeb-4b33-9dc0-b6dc14da05be@github.com> On Thu, 2 Oct 2025 20:34:02 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > David's comments test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java line 95: > 93: throw new Error("Unexpected: " + e); > 94: } finally { > 95: exitRawMonitor(); This isn't quite right. If we have the exit in the finally block then it should be deleted from the main block. But we also need the enter to be outside the scope of the try-catch-finally incase we abort before entering the raw monitor. Not worth wasting time on this part - just restore it to how it was. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27582#discussion_r2400919911 From duke at openjdk.org Fri Oct 3 08:00:57 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Fri, 3 Oct 2025 08:00:57 GMT Subject: Integrated: 8369037: Identify owning method for MethodData and MethodCounters in AOT map output In-Reply-To: References: Message-ID: <7pe4XwytvcHOAjI7tzJYcdgeCO3RYoJGE7d6aUr1j04=.8734adf1-36a0-417d-a555-da939e6b90b7@github.com> On Thu, 2 Oct 2025 08:26:54 GMT, Mar?a Arias de Reyna wrote: > Part of https://bugs.openjdk.org/browse/JDK-8369037 > Provides part of fixes needed to resolve https://bugs.openjdk.org/browse/JDK-8363440 > > The AOT map file lists many objects without any kind of context of what they represent. For example, `MethodCounters` and `MethodData` do not show to what method they belong to. With this patch, now we can at least link the `MethodCounters` and `MethodData` to the `Method` they belong to. > > Before: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801e4c280: @@ MethodCounters 64 > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801e44448: @@ MethodData 584 > > > After: > > $ cat aot.map | grep "@@ MethodCounters" > [...] > 0x0000000801f8b9a8: @@ MethodCounters 64 void jdk.internal.access.SharedSecrets.setJavaLangAccess(jdk.internal.access.JavaLangAccess) > 0x0000000801f8be60: @@ MethodCounters 64 void java.lang.Object.notifyAll() > > ``` bash > $ cat aot.map | grep "@@ MethodData" > [...] > 0x0000000801f700e0: @@ MethodData 728 int java.lang.module.ModuleDescriptor.hashCode() > 0x0000000801f81af0: @@ MethodData 688 java.lang.String java.lang.Class.cannotCastMsg(java.lang.Object) This pull request has now been integrated. Changeset: 2e783963 Author: Mar?a Arias de Reyna Dom?nguez Committer: Roland Westrelin URL: https://git.openjdk.org/jdk/commit/2e783963d21c8edd88e79226ca473cfe0e41335b Stats: 24 lines in 2 files changed: 24 ins; 0 del; 0 mod 8369037: Identify owning method for MethodData and MethodCounters in AOT map output Reviewed-by: iklam, asmehra, adinn, macarte ------------- PR: https://git.openjdk.org/jdk/pull/27603 From dholmes at openjdk.org Fri Oct 3 11:41:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Oct 2025 11:41:46 GMT Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 11:56:45 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not. >> >> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/classfile/classFileParser.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27528#pullrequestreview-3298563138 From pchilanomate at openjdk.org Fri Oct 3 15:02:47 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 15:02:47 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: > Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. > > I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: - Remove extra space - Remove finally block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27582/files - new: https://git.openjdk.org/jdk/pull/27582/files/0f566c09..930906da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27582.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27582/head:pull/27582 PR: https://git.openjdk.org/jdk/pull/27582 From pchilanomate at openjdk.org Fri Oct 3 15:02:50 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 15:02:50 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v2] In-Reply-To: <1uOtOSsKH5YeIJfJwYw9_m5n3HzKOENk5pl4bwQHPrA=.0606ad65-fbeb-4b33-9dc0-b6dc14da05be@github.com> References: <1uOtOSsKH5YeIJfJwYw9_m5n3HzKOENk5pl4bwQHPrA=.0606ad65-fbeb-4b33-9dc0-b6dc14da05be@github.com> Message-ID: <-uMjhIfbqBVP62NEwcWoFZd4xvCh5jm1kQdk1Xzi0rg=.8aa5556e-8eda-47ab-9b07-159e712e82dc@github.com> On Fri, 3 Oct 2025 06:18:50 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> David's comments > > test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java line 95: > >> 93: throw new Error("Unexpected: " + e); >> 94: } finally { >> 95: exitRawMonitor(); > > This isn't quite right. If we have the exit in the finally block then it should be deleted from the main block. But we also need the enter to be outside the scope of the try-catch-finally incase we abort before entering the raw monitor. Not worth wasting time on this part - just restore it to how it was. Right, but removing it from the main block would have the same potential deadlock, that?s why I checked calling exitRawMonitor just returns an error if not the owner. Unless we also wrap the Thread.sleep() call in a while true loop, and call exitRawMonitor in the finally block only for worker1. That would replace a possible error returned by exitRawMonitor with never releasing for worker2. The good thing about stopping worker1 too is that we don?t have to wait for the sleep call and can run many more iterations. Anyways, I kept it as it was without the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27582#discussion_r2402286585 From pchilanomate at openjdk.org Fri Oct 3 15:29:25 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 15:29:25 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v2] In-Reply-To: References: Message-ID: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Fix typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/0168c88f..398712a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From pchilanomate at openjdk.org Fri Oct 3 15:29:26 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 15:29:26 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 05:36:14 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > src/hotspot/share/runtime/objectMonitor.cpp line 997: > >> 995: // prevents this load from floating up previous store. >> 996: // Note that we can have false positives where timed-park is not necessary. >> 997: bool do_timed_parked = has_unmounted_vthreads(); > > Don't we still only need the timed-park if the current thread is a pinned vthread? Yes, except if the monitor is also used in the context of a carrier thread. Currently there are only very few such cases and we disable preemption for them (e.g. `interruptLock`), so it?s likely not needed. With the upcoming changes to preempt on klass initialization, we could also have this situation if a class can be initialized both in the context of a carrier and a vthread. Since code executed in the context of the carriers is limited to library code there will also be very few cases of this, but I?ve seen at least one such case with `LockSupport`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2402384724 From coleenp at openjdk.org Fri Oct 3 19:04:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 3 Oct 2025 19:04:49 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 15:29:25 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos src/hotspot/share/runtime/objectMonitor.cpp line 1108: > 1106: // Note that we can have false positives where timed-park is not necessary. > 1107: bool do_timed_parked = has_unmounted_vthreads(); > 1108: static int MAX_RECHECK_INTERVAL = 1000; Is this a constant? This is the same as the enter case, should there be only one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2403055591 From pchilanomate at openjdk.org Fri Oct 3 19:55:23 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 19:55:23 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 19:02:23 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > src/hotspot/share/runtime/objectMonitor.cpp line 1108: > >> 1106: // Note that we can have false positives where timed-park is not necessary. >> 1107: bool do_timed_parked = has_unmounted_vthreads(); >> 1108: static int MAX_RECHECK_INTERVAL = 1000; > > Is this a constant? This is the same as the enter case, should there be only one? Yes, I moved it to a global static. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2403195006 From pchilanomate at openjdk.org Fri Oct 3 19:55:20 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Oct 2025 19:55:20 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v3] In-Reply-To: References: Message-ID: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: make MAX_RECHECK_INTERVAL global static ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/398712a3..e60c375f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From dcubed at openjdk.org Fri Oct 3 21:05:16 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 21:05:16 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs Message-ID: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option ------------- Commit messages: - 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option - 8369132 disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC - 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs Changes: https://git.openjdk.org/jdk/pull/27629/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27629&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369128 Stats: 4 lines in 4 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27629.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27629/head:pull/27629 PR: https://git.openjdk.org/jdk/pull/27629 From dcubed at openjdk.org Fri Oct 3 21:05:19 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 21:05:19 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com> References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com> Message-ID: <_a422YA5GgS6goxf5CnnaG-YsMmfn-M6vYqkK0XYnR4=.21894e92-f2f6-4d93-8fd7-3cfa0447f7c8@github.com> On Fri, 3 Oct 2025 20:47:42 GMT, Albert Mingkun Yang wrote: >> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: >> >> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs >> >> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC >> >> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option > > Marked as reviewed by ayang (Reviewer). @albertnetymk - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367206699 From ayang at openjdk.org Fri Oct 3 21:05:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 3 Oct 2025 21:05:17 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> Message-ID: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com> On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty wrote: > In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: > > [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs > > [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC > > [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300900845 From dcubed at openjdk.org Fri Oct 3 21:05:18 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 21:05:18 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> Message-ID: On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty wrote: > In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: > > [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs > > [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC > > [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Blasted auto-correct keeps changing what I type... It's been too long since I've bundled multiple fixes together. I forgot a couple of steps... All Mach5 testing that I've done is documented in each bug report. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367198386 PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367205612 PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367207761 From dholmes at openjdk.org Fri Oct 3 21:14:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Oct 2025 21:14:58 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> Message-ID: On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty wrote: > In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: > > [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs > > [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC > > [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Seems reasonable. I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300964363 From dcubed at openjdk.org Fri Oct 3 21:14:59 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 21:14:59 GMT Subject: Integrated: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> Message-ID: On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty wrote: > In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: > > [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs > > [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC > > [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option This pull request has now been integrated. Changeset: 837f634b Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/837f634bf29fd877dd62a2e0f7d7a1bd383372d3 Stats: 4 lines in 4 files changed: 4 ins; 0 del; 0 mod 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs 8369132: Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Reviewed-by: ayang, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27629 From dcubed at openjdk.org Fri Oct 3 22:15:55 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 22:15:55 GMT Subject: RFR: 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs In-Reply-To: References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com> Message-ID: <0aO_PY7lyXtH0jQ2_Zhk7QYFdDtZjYFr_-oluOpdF8k=.e7659811-f5a6-40a9-a4e6-7e2357cc77ac@github.com> On Fri, 3 Oct 2025 21:10:15 GMT, David Holmes wrote: >> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes: >> >> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs >> >> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC >> >> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option > > Seems reasonable. > > I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too. > > Thanks @dholmes-ora - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367369658 From kvn at openjdk.org Fri Oct 3 22:20:08 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 3 Oct 2025 22:20:08 GMT Subject: Integrated: 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> Message-ID: <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com> On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java > to execute with release bits. Good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27630#pullrequestreview-3301152546 From dcubed at openjdk.org Fri Oct 3 22:20:08 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 22:20:08 GMT Subject: Integrated: 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> Message-ID: On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java > to execute with release bits. I tested this fix with a local release bits run on my MBP14. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27630#issuecomment-3367377177 From dcubed at openjdk.org Fri Oct 3 22:20:07 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 22:20:07 GMT Subject: Integrated: 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails Message-ID: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java to execute with release bits. ------------- Commit messages: - 8369138: new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails Changes: https://git.openjdk.org/jdk/pull/27630/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27630&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369138 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27630.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27630/head:pull/27630 PR: https://git.openjdk.org/jdk/pull/27630 From dcubed at openjdk.org Fri Oct 3 22:20:09 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 22:20:09 GMT Subject: Integrated: 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails In-Reply-To: <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com> References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com> Message-ID: <3naIU4lB6Vlr8RjCZKKAmHU4QfQJTjdHbX5rtOXy3L0=.d0b7c7fa-173e-43fe-9f7e-64da86e191fa@github.com> On Fri, 3 Oct 2025 22:14:51 GMT, Vladimir Kozlov wrote: >> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java >> to execute with release bits. > > Good @vnkozlov - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27630#issuecomment-3367377929 From dcubed at openjdk.org Fri Oct 3 22:20:10 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 3 Oct 2025 22:20:10 GMT Subject: Integrated: 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com> Message-ID: <8jFcnpEQJ0A-ewTXxSDdsKHPTc_sW4rDxuhZQTCShKk=.9c7d9937-045a-47a7-adfd-bbad9b899eaa@github.com> On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java > to execute with release bits. This pull request has now been integrated. Changeset: e6868c62 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/e6868c624851d5c6bd182e45ba908cb06b731e8c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/27630 From duke at openjdk.org Mon Oct 6 05:05:24 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 6 Oct 2025 05:05:24 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 Message-ID: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> related jira issue: https://bugs.openjdk.org/browse/JDK-8367717 ## Changes As described in the issue, this change aligns `atomic_copy64` definitions for zero platforms with those of other platforms. ## Verification - Verified by running: `make run-test TEST="gtest:AtomicAccess*"` with a JDK image built using the `zero` JVM variant. Please let me know if there are any additional or more appropriate verification steps I should perform. ------------- Commit messages: - cleanup: align atomic_copy64 definitions for zero platforms with others Changes: https://git.openjdk.org/jdk/pull/27642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27642&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367717 Stats: 28 lines in 4 files changed: 14 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27642/head:pull/27642 PR: https://git.openjdk.org/jdk/pull/27642 From kbarrett at openjdk.org Mon Oct 6 06:47:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 6 Oct 2025 06:47:47 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 In-Reply-To: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Mon, 6 Oct 2025 04:58:16 GMT, jonghoonpark wrote: > As described in the issue, this change aligns atomic_copy64 definitions for > zero platforms with those of other platforms. The issue suggests it might be better to replace calls to atomic_copy64 with `AtomicAccess::store(dst, AtomicAccess::load(src))` (using the new `AtomicAccess` nomenclature), and then delete all definitions of atomic_copy64. And there's a comment agreeing with that suggestion. I think that's the way to go, rather than what this PR proposes. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27642#pullrequestreview-3303009902 From duke at openjdk.org Mon Oct 6 07:50:57 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 6 Oct 2025 07:50:57 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Mon, 6 Oct 2025 06:44:48 GMT, Kim Barrett wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8367717 >> >> ## Changes >> As described in the issue, this change aligns `atomic_copy64` definitions for zero platforms with those of other platforms. >> >> ## Verification >> - Verified by running: `make run-test TEST="gtest:AtomicAccess*"` with a JDK image built using the `zero` JVM variant. >> >> Please let me know if there are any additional or more appropriate verification steps I should perform. > >> As described in the issue, this change aligns atomic_copy64 definitions for >> zero platforms with those of other platforms. > > The issue suggests it might be better to replace calls to atomic_copy64 with > `AtomicAccess::store(dst, AtomicAccess::load(src))` (using the new > `AtomicAccess` nomenclature), and then delete all definitions of > atomic_copy64. And there's a comment agreeing with that suggestion. I think > that's the way to go, rather than what this PR proposes. @kimbarrett Thanks for the feedback. I thought the plan was to align the definitions first, and then implement the new form later. I'll revise the work to make the change to the new formulation, as you suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3370333776 From jsjolen at openjdk.org Mon Oct 6 07:52:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 6 Oct 2025 07:52:07 GMT Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 11:56:45 GMT, Johan Sj?len wrote: >> Hi, >> >> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not. >> >> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/classfile/classFileParser.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27528#issuecomment-3370332669 From jsjolen at openjdk.org Mon Oct 6 07:52:08 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 6 Oct 2025 07:52:08 GMT Subject: Integrated: 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len wrote: > Hi, > > `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not. > > We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is. This pull request has now been integrated. Changeset: 069c569a Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/069c569a710f50bc715f523c6c4c7aa087694af6 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature Reviewed-by: dholmes, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/27528 From duke at openjdk.org Mon Oct 6 09:38:24 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 6 Oct 2025 09:38:24 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: > related jira issue: https://bugs.openjdk.org/browse/JDK-8367717 > > ## Changes > - deleted all definitions of atomic_copy64 > - replaced all calls to `atomic_copy64` with `AtomicAccess::store(dst, AtomicAccess::load(src))` > > ## Verification > - Verified by running: > - `make run-test TEST="gtest:StubRoutines*"` > - `make run-test TEST="gtest:AtomicAccess*"` > > Please let me know if there are any additional or more appropriate verification steps I should perform. jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: cleanup: align to use AtomicAccess Signed-off-by: jonghoonpark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27642/files - new: https://git.openjdk.org/jdk/pull/27642/files/33a93805..de15f195 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27642&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27642&range=00-01 Stats: 39 lines in 5 files changed: 3 ins; 26 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27642/head:pull/27642 PR: https://git.openjdk.org/jdk/pull/27642 From jcking at openjdk.org Mon Oct 6 14:26:16 2025 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Oct 2025 14:26:16 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Mon, 6 Oct 2025 09:38:24 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8367717 >> >> ## Changes >> - deleted all definitions of atomic_copy64 >> - replaced all calls to `atomic_copy64` with `AtomicAccess::store(dst, AtomicAccess::load(src))` >> >> ## Verification >> - Verified by running: >> - `make run-test TEST="gtest:StubRoutines*"` >> - `make run-test TEST="gtest:AtomicAccess*"` >> >> Please let me know if there are any additional or more appropriate verification steps I should perform. > > jonghoonpark has updated the pull request incrementally with one additional commit since the last revision: > > cleanup: align to use AtomicAccess > > Signed-off-by: jonghoonpark This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3371948431 From jcking at openjdk.org Mon Oct 6 14:26:27 2025 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Oct 2025 14:26:27 GMT Subject: RFR: 8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing Message-ID: Ensure the compiler cannot optimize the copy loops by replacing them with `memcpy` which is allowed to copy byte by byte potentially introducing tearing. Currently there is nothing preventing the compiler from doing this. We add `volatile` which prevents the compiler from making this optimization in the future. Currently the code generates to `ldp` and `stp`, this change does have the side affect of forcing it to do `ldr` and `str`. If that seems unacceptable from a performance standpoint we can hand-roll assembly to do `ldp` and `stp`. ------------- Commit messages: - JDK-8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing Changes: https://git.openjdk.org/jdk/pull/27647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27647&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369207 Stats: 20 lines in 2 files changed: 0 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27647/head:pull/27647 PR: https://git.openjdk.org/jdk/pull/27647 From aph at openjdk.org Mon Oct 6 15:35:20 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 6 Oct 2025 15:35:20 GMT Subject: RFR: 8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:17:52 GMT, Justin King wrote: > Currently the code generates to `ldp` and `stp`, this change does have the side affect of forcing it to do `ldr` and `str`. If that seems unacceptable from a performance standpoint we can hand-roll assembly to do `ldp` and `stp`. That would be much better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27647#issuecomment-3372327401 From jcking at openjdk.org Mon Oct 6 16:04:39 2025 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Oct 2025 16:04:39 GMT Subject: RFR: 8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 15:32:14 GMT, Andrew Haley wrote: > > Currently the code generates to `ldp` and `stp`, this change does have the side affect of forcing it to do `ldr` and `str`. If that seems unacceptable from a performance standpoint we can hand-roll assembly to do `ldp` and `stp`. > > That would be much better. https://github.com/openjdk/jdk/pull/27642 is already going to move it to `ldr` and `str`, FYI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27647#issuecomment-3372486093 From alanb at openjdk.org Mon Oct 6 16:51:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Oct 2025 16:51:24 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 19:55:20 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > make MAX_RECHECK_INTERVAL global static test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 645: > 643: /** > 644: * Test no deadlock happens when Object.wait is called from a mix of pinned and non-pinned > 645: * paths and notification is done using notifyAll. At some point then maybe we should combine this with RetryMonitorEnterWhenPinned. I'm not suggesting we do this now but some of the expanded description might be useful to include here as a passing reader might not immediately know what this test is doing. test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 648: > 646: */ > 647: @Test > 648: void testMixedPinnedUnmounted() throws Exception { What would you think of testing timed-wait too? Some of the other tests are paramerized with a value source and some time values to test both untimed and timed waits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2407415045 PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2407408631 From pchilanomate at openjdk.org Mon Oct 6 22:34:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 6 Oct 2025 22:34:29 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Move test to RetryMonitorEnterWhenPinned.java and add timed-variants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/e60c375f..bf3613e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=02-03 Stats: 160 lines in 2 files changed: 95 ins; 56 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From pchilanomate at openjdk.org Mon Oct 6 22:34:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 6 Oct 2025 22:34:30 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 16:48:35 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> make MAX_RECHECK_INTERVAL global static > > test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 645: > >> 643: /** >> 644: * Test no deadlock happens when Object.wait is called from a mix of pinned and non-pinned >> 645: * paths and notification is done using notifyAll. > > At some point then maybe we should combine this with RetryMonitorEnterWhenPinned. I'm not suggesting we do this now but some of the expanded description might be useful to include here as a passing reader might not immediately know what this test is doing. I wasn?t sure where to put the extra test and missed `RetryMonitorEnterWhenPinned.java`. I agree it makes more sense to have it here. Moved now, let me know what you think. > test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 648: > >> 646: */ >> 647: @Test >> 648: void testMixedPinnedUnmounted() throws Exception { > > What would you think of testing timed-wait too? Some of the other tests are paramerized with a value source and some time values to test both untimed and timed waits. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2408849669 PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2408850049 From dholmes at openjdk.org Tue Oct 7 00:50:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 00:50:47 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 15:02:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - Remove extra space > - Remove finally block Okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27582#pullrequestreview-3307947438 From kbarrett at openjdk.org Tue Oct 7 01:31:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 7 Oct 2025 01:31:48 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Mon, 6 Oct 2025 14:23:11 GMT, Justin King wrote: > This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR. @jcking - I noticed that problem too, while reviewing this change. I don't care whether it is fixed in this PR or in yours. Note that your's currently doesn't perform atomic accesses on the "from" value. I think that's wrong, since the documentation for these functions doesn't indicate atomicity only for the store. The comment in copy.hpp says "atomicity: atomic or non-atomic on the copy unit." I take that to mean both source and destination. Your PR is also not addressing other platforms with similar issues, such as in copy_ppc.hpp. Also, this all begs the question of why we have four different copies of these functions - bsd_aarch64, bsd_zero, linux_aarch64, and linux_zero. All of these should be identical. Basically, I think the Copy class is kind of a mess, and that discourages its use. Probably this needs an overall plan of attack (broken up into reviewable chunks, but with an overarching goal), rather than piecemeal fixups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3374841553 From dholmes at openjdk.org Tue Oct 7 04:13:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 04:13:49 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 15:25:41 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 997: >> >>> 995: // prevents this load from floating up previous store. >>> 996: // Note that we can have false positives where timed-park is not necessary. >>> 997: bool do_timed_parked = has_unmounted_vthreads(); >> >> Don't we still only need the timed-park if the current thread is a pinned vthread? > > Yes, except if the monitor is also used in the context of a carrier thread. Currently there are only very few such cases and we disable preemption for them (e.g. `interruptLock`), so it?s likely not needed. With the upcoming changes to preempt on klass initialization, we could also have this situation if a class can be initialized both in the context of a carrier and a vthread. Since code executed in the context of the carriers is limited to library code there will also be very few cases of this, but I?ve seen at least one such case with `LockSupport`. So you are saying the current code is insufficient and could still deadlock? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2409280439 From dholmes at openjdk.org Tue Oct 7 04:13:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 04:13:52 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 22:34:29 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Move test to RetryMonitorEnterWhenPinned.java and add timed-variants src/hotspot/share/runtime/objectMonitor.inline.hpp line 147: > 145: > 146: inline void ObjectMonitor::inc_unmounted_vthreads() { > 147: assert(_unmounted_vthreads >= 0, ""); Suggestion: assert(_unmounted_vthreads >= 0, "invariant"); Here and below - thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2409285515 From dholmes at openjdk.org Tue Oct 7 06:20:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 06:20:20 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List Message-ID: The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. Testing: - tiers 1-3 (sanity) Thanks. ------------- Commit messages: - Merge - Fix the NJT::List and its embedded Semaphore Changes: https://git.openjdk.org/jdk/pull/27664/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369250 Stats: 39 lines in 3 files changed: 18 ins; 9 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27664.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27664/head:pull/27664 PR: https://git.openjdk.org/jdk/pull/27664 From stefank at openjdk.org Tue Oct 7 06:35:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 06:35:44 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: Message-ID: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> On Tue, 7 Oct 2025 06:13:51 GMT, David Holmes wrote: > The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. > > Testing: > - tiers 1-3 (sanity) > > Thanks. src/hotspot/share/runtime/nonJavaThread.hpp line 49: > 47: } > 48: > 49: NonJavaThread* volatile _next; Is there a reason why the code couldn't stay in the .cpp file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409545857 From kbarrett at openjdk.org Tue Oct 7 07:15:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 7 Oct 2025 07:15:47 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 06:13:51 GMT, David Holmes wrote: > The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. > > Testing: > - tiers 1-3 (sanity) > > Thanks. Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27664#pullrequestreview-3308716715 From kbarrett at openjdk.org Tue Oct 7 07:15:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 7 Oct 2025 07:15:50 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 07:09:55 GMT, David Holmes wrote: >> src/hotspot/share/runtime/nonJavaThread.hpp line 49: >> >>> 47: } >>> 48: >>> 49: NonJavaThread* volatile _next; >> >> Is there a reason why the code couldn't stay in the .cpp file? > > Yes, we need a complete class definition of `T` available when we declare the `DeferredStatic`. But we could instead have in the header void non_java_threads_list_init(); and in the .cpp file void non_java_threads_list_init() { NonJavaThread::init(); } which is an idiom we frequently use elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409621459 From dholmes at openjdk.org Tue Oct 7 07:15:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 07:15:51 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 07:11:42 GMT, Kim Barrett wrote: >> Yes, we need a complete class definition of `T` available when we declare the `DeferredStatic`. > > But we could instead have in the header > > void non_java_threads_list_init(); > > and in the .cpp file > > void non_java_threads_list_init() { NonJavaThread::init(); } > > which is an idiom we frequently use elsewhere. IIUC given the declaration:' static DeferredStatic _the_list; the compiler must be able to see that `List` has an `initialize` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409625585 From dholmes at openjdk.org Tue Oct 7 07:15:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 07:15:49 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 06:33:29 GMT, Stefan Karlsson wrote: >> The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. >> >> Testing: >> - tiers 1-3 (sanity) >> >> Thanks. > > src/hotspot/share/runtime/nonJavaThread.hpp line 49: > >> 47: } >> 48: >> 49: NonJavaThread* volatile _next; > > Is there a reason why the code couldn't stay in the .cpp file? Yes, we need a complete class definition of `T` available when we declare the `DeferredStatic`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409617594 From stefank at openjdk.org Tue Oct 7 08:25:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 08:25:02 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 07:13:28 GMT, David Holmes wrote: >> But we could instead have in the header >> >> void non_java_threads_list_init(); >> >> and in the .cpp file >> >> void non_java_threads_list_init() { NonJavaThread::init(); } >> >> which is an idiom we frequently use elsewhere. > > IIUC given the declaration:' > > static DeferredStatic _the_list; > > the compiler must be able to see that `List` has an `initialize` method. And why can't you put `List` before that line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409814622 From stefank at openjdk.org Tue Oct 7 08:30:54 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 08:30:54 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 08:22:10 GMT, Stefan Karlsson wrote: >> IIUC given the declaration:' >> >> static DeferredStatic _the_list; >> >> the compiler must be able to see that `List` has an `initialize` method. > > And why can't you put `List` before that line? OK. I see now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409832390 From kbarrett at openjdk.org Tue Oct 7 08:41:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 7 Oct 2025 08:41:45 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 08:28:10 GMT, Stefan Karlsson wrote: >> And why can't you put `List` before that line? > > OK. I see now. It might be necessary to make `_the_list` be a file scoped variable rather than class scoped, to avoid needing to expose things in the header. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409863036 From stefank at openjdk.org Tue Oct 7 08:53:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 08:53:47 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 08:39:35 GMT, Kim Barrett wrote: >> OK. I see now. > > It might be necessary to make `_the_list` be a file scoped variable rather > than class scoped, to avoid needing to expose things in the header. Hmm. This seems to compile on my mac at least: https://github.com/openjdk/jdk/compare/master...stefank:jdk:pull_27664_alternative ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409892353 From stefank at openjdk.org Tue Oct 7 08:58:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 08:58:46 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 08:50:41 GMT, Stefan Karlsson wrote: >> It might be necessary to make `_the_list` be a file scoped variable rather >> than class scoped, to avoid needing to expose things in the header. > > Hmm. This seems to compile on my mac at least: > https://github.com/openjdk/jdk/compare/master...stefank:jdk:pull_27664_alternative http://cppreference.com/w/cpp/language/static.html > The declaration inside the class body is not a definition and may declare the member to be of [incomplete type](https://www.cppreference.com/w/cpp/language/incomplete_type.html) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2409908389 From jsikstro at openjdk.org Tue Oct 7 09:15:34 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 7 Oct 2025 09:15:34 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Revert MaxRAM default removals, defer to future enhancement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27224/files - new: https://git.openjdk.org/jdk/pull/27224/files/bd1f632e..2304c6aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=02-03 Stats: 17 lines in 2 files changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From ayang at openjdk.org Tue Oct 7 09:23:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 7 Oct 2025 09:23:26 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4] In-Reply-To: References: Message-ID: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com> On Tue, 7 Oct 2025 09:15:34 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Revert MaxRAM default removals, defer to future enhancement src/hotspot/share/runtime/arguments.cpp line 1514: > 1512: > 1513: // Check if the user has configured any limit on the amount of RAM we may use. > 1514: bool ram_limit_set = !FLAG_IS_DEFAULT(MaxRAMPercentage) || How about `has_ram_limit`/`is_ram_limit_set`? src/hotspot/share/runtime/arguments.cpp line 1544: > 1542: uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100); > 1543: > 1544: const size_t reasonable_min = limit_by_size_t_max(min_memory); I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result. src/hotspot/share/runtime/arguments.cpp line 1590: > 1588: > 1589: if (UseCompressedOops) { > 1590: size_t heap_end = HeapBaseMinAddress + MaxHeapSize; I wonder if this is a pre-existing issue: `HeapBaseMinAddress` , according to its name, sounds like a `uintptr_t` instead of `size_t`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409967306 PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409970585 PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409973796 From jsikstro at openjdk.org Tue Oct 7 09:34:19 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 7 Oct 2025 09:34:19 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Rename ram_limit_set to has_ram_limit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27224/files - new: https://git.openjdk.org/jdk/pull/27224/files/2304c6aa..c6e585e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From jsikstro at openjdk.org Tue Oct 7 09:34:21 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 7 Oct 2025 09:34:21 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4] In-Reply-To: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com> References: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com> Message-ID: On Tue, 7 Oct 2025 09:19:03 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert MaxRAM default removals, defer to future enhancement > > src/hotspot/share/runtime/arguments.cpp line 1544: > >> 1542: uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100); >> 1543: >> 1544: const size_t reasonable_min = limit_by_size_t_max(min_memory); > > I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result. I'm a bit hesitant to add non-debug logging here as I don't have resources to test this on a 32-bit VM. Also, I'm not sure how much extra code we'd like to have for 32-bit support. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2410006373 From dholmes at openjdk.org Tue Oct 7 10:43:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 10:43:45 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 08:56:18 GMT, Stefan Karlsson wrote: >> Hmm. This seems to compile on my mac at least: >> https://github.com/openjdk/jdk/compare/master...stefank:jdk:pull_27664_alternative > > http://cppreference.com/w/cpp/language/static.html >> The declaration inside the class body is not a definition and may declare the member to be of [incomplete type](https://www.cppreference.com/w/cpp/language/incomplete_type.html) I didn't initially move the definition of the `List` class and it failed to build for me - hence I had to move it. What is the concern with defining `List` in the header file??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2410192880 From stefank at openjdk.org Tue Oct 7 12:01:57 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Oct 2025 12:01:57 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 10:41:32 GMT, David Holmes wrote: >> http://cppreference.com/w/cpp/language/static.html >>> The declaration inside the class body is not a definition and may declare the member to be of [incomplete type](https://www.cppreference.com/w/cpp/language/incomplete_type.html) > > I didn't initially move the definition of the `List` class and it failed to build for me - hence I had to move it. > > What is the concern with defining `List` in the header file??? It added an unnecessary dependency to the header (SingleWriterSynchronizer) and it made the class uglier than it had to. My 2c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2410383501 From ayang at openjdk.org Tue Oct 7 12:43:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 7 Oct 2025 12:43:39 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 09:34:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Rename ram_limit_set to has_ram_limit Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3309934893 From mdoerr at openjdk.org Tue Oct 7 13:57:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 7 Oct 2025 13:57:38 GMT Subject: RFR: 8368997: AIX allows reading from address zero which leads to several ubsan findings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 14:08:08 GMT, Joachim Kern wrote: > In _SafeFetchXX_internal() a pointer is checked for readability before using. It returns false if this is not the case. The implementation tries to read from the pointer if this is not feasible the signal handler comes into place jumping back to the function via longjmp, so the _SafeFetchXX_internal() itself can return with a false and a null as pseudo content of the address. If the address was readable the function returns true and provides the content of the address. > Because AIX allows reading from address zero, _SafeFetchXX_internal() returns true and follow up functions using the address are called. All these functions end up in an UBSAN finding regarding reading from zero. > The solution could be to manually code that also AIX behaves like other operating systems and returns false and the content zero in case of address zero. Then no UBSAN finding occur. I think this is fine. Hotspot should never read from address 0, so returning false should be ok. This essentially emulates the behavior of other operating systems. Should we only catch `adr == nullptr` or all addresses within the first memory page? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27591#pullrequestreview-3310247930 From duke at openjdk.org Tue Oct 7 16:49:28 2025 From: duke at openjdk.org (Saint Wesonga) Date: Tue, 7 Oct 2025 16:49:28 GMT Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 [v4] In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> Message-ID: > The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. > > Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. > > Exceptions with the DBG_PRINTEXCEPTION_C exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code) Saint Wesonga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Scope down error reporting to failed exception codes (other than EXCEPTION_UNCAUGHT_CXX_EXCEPTION) on Windows AArch64 - Merge defined(_M_AMD64) blocks - Merge branch 'master' into 8348862-create-core-dumps-win-aarch64 - Move safefetch handling into existing _M_ARM64 block - Clarify that SEH is only used on Windows x86_64 Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Fix bug causing missing core dumps on Windows AArch64 - Windows AArch64 safefetch implementation should not use structured exception handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27074/files - new: https://git.openjdk.org/jdk/pull/27074/files/9829641a..056c0676 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=02-03 Stats: 205262 lines in 2808 files changed: 155420 ins; 32028 del; 17814 mod Patch: https://git.openjdk.org/jdk/pull/27074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27074/head:pull/27074 PR: https://git.openjdk.org/jdk/pull/27074 From duke at openjdk.org Tue Oct 7 17:05:04 2025 From: duke at openjdk.org (Saint Wesonga) Date: Tue, 7 Oct 2025 17:05:04 GMT Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 [v5] In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> Message-ID: <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> > The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. > > Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. > > Exceptions with the DBG_PRINTEXCEPTION_C exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code) Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: Add missing fix for UncaughtNativeExceptionTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27074/files - new: https://git.openjdk.org/jdk/pull/27074/files/056c0676..9faaa856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=03-04 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27074/head:pull/27074 PR: https://git.openjdk.org/jdk/pull/27074 From duke at openjdk.org Tue Oct 7 17:54:22 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 17:54:22 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v5] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - Merge remote-tracking branch 'origin/master' into nativelibraries-fix - switch platform helper to be mapToNativeLibraryName - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix - fix spelling - new approach: append . to file name on Windows - 8348828: Windows dll loading now resolves symlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/58d644a5..0e4f3ffb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=03-04 Stats: 516304 lines in 7697 files changed: 345477 ins; 116288 del; 54539 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Tue Oct 7 17:54:22 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 17:54:22 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v4] In-Reply-To: References: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> Message-ID: On Tue, 7 Oct 2025 15:52:12 GMT, Chen Liang wrote: > Thanks for prompting for attention on the mailing list. Thanks for looking. > > I just wonder if it would be better for us to handle this in `os::dll_load` in `os_windows.cpp` - this seems a better way to handle generic platform-specific peculiarities. This approach also means JNI and all other users would be updated too, but I don't see why JNI would handle this differently from class loader APIs. This is a good suggestion. I've now updated do append the dot in `os_windows.cpp`'s `dll_load`. I suppose this turns it in a hotspot review rather than a core-libs change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3377943193 From pchilanomate at openjdk.org Tue Oct 7 18:36:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:30 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: References: Message-ID: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add string in asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/bf3613e1..9e435e09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From pchilanomate at openjdk.org Tue Oct 7 18:36:31 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:31 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 04:03:40 GMT, David Holmes wrote: >> Yes, except if the monitor is also used in the context of a carrier thread. Currently there are only very few such cases and we disable preemption for them (e.g. `interruptLock`), so it?s likely not needed. With the upcoming changes to preempt on klass initialization, we could also have this situation if a class can be initialized both in the context of a carrier and a vthread. Since code executed in the context of the carriers is limited to library code there will also be very few cases of this, but I?ve seen at least one such case with `LockSupport`. > > So you are saying the current code is insufficient and could still deadlock? If there?s a monitor that is used both in the context of a virtual thread and the carriers then potentially yes. But this should almost never happen, and for the very few special cases we identified we currently disable preemption. So this is mostly to cover for the upcoming changes in case there is a class that can be initialized in the context of both a virtual thread and the carriers. Again this should also be a rare case but I?ve seen at least one case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2411545770 From pchilanomate at openjdk.org Tue Oct 7 18:36:33 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:33 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 04:08:50 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Move test to RetryMonitorEnterWhenPinned.java and add timed-variants > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 147: > >> 145: >> 146: inline void ObjectMonitor::inc_unmounted_vthreads() { >> 147: assert(_unmounted_vthreads >= 0, ""); > > Suggestion: > > assert(_unmounted_vthreads >= 0, "invariant"); > > Here and below - thanks. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2411544003 From duke at openjdk.org Tue Oct 7 20:06:13 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:06:13 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v6] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into nativelibraries-fix - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - Merge remote-tracking branch 'origin/master' into nativelibraries-fix - switch platform helper to be mapToNativeLibraryName - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix - fix spelling - new approach: append . to file name on Windows - 8348828: Windows dll loading now resolves symlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/0e4f3ffb..532891a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=04-05 Stats: 301 lines in 22 files changed: 213 ins; 40 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Tue Oct 7 20:14:15 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 7 Oct 2025 20:14:15 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands In-Reply-To: References: Message-ID: <_h6iPBFZzttUFCxAiBm1h7CzQzzDtQboxBFEVO_Mj0o=.c17cc4f9-3279-4f8d-adb1-69b049146ce7@github.com> On Wed, 24 Sep 2025 22:24:35 GMT, Larry Cable wrote: > My proposal would entail > * adding a new standard option to jcmd > * somehow funneling that option to the JVM > * the option should be optional, so that: > * old jcmd still works with new JVMs (and produces legacy jcmd output) > * new jcmd still works with old JVMs (and produces legacy jcmd output) > How complex would this be? There are two approaches to this. You > can either create a new attach listener protocol (we already have > ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or, > you can expand the jcmd parsing (see |jcmd(AttachOperation* op, > attachStream* out)| in attachListener.cpp). > > ATTACH_API_V2 supports "options". > Client (jcmd) detects options supported by the target VM ("getversion > options" command) and can set option values in attach command request. > Currently the only supported option is "streaming" (it allows turn off > streaming output). > The option is needed only for tests and needs to work for all attach > tools (jcmd, jstack, etc.), so it can be set by specifying java > property launching attach tool (like |jcmd > -J-Djdk.attach.allowStreamingOutput=false PID command|) Agreed. I will be working on the proposal. Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3360367314 From duke at openjdk.org Tue Oct 7 20:43:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:43:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v7] In-Reply-To: References: Message-ID: <7vzxlAlWx_gaQZSvMCYeuYlza-W9Z0DcjLJdWkjVZ5Q=.f616c102-decd-482c-b86e-fb204c8ca8e4@github.com> > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: use os::malloc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/532891a4..9f621161 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Tue Oct 7 20:54:08 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:54:08 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: add cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/9f621161..d571e826 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From dholmes at openjdk.org Tue Oct 7 21:23:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 21:23:55 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: Message-ID: > The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. > > Testing: > - tiers 1-3 (sanity) > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Return class List definition to cpp file per Stefan and Kim's requests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27664/files - new: https://git.openjdk.org/jdk/pull/27664/files/7c56f76f..ac664896 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27664&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27664&range=00-01 Stats: 26 lines in 2 files changed: 14 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27664.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27664/head:pull/27664 PR: https://git.openjdk.org/jdk/pull/27664 From dholmes at openjdk.org Tue Oct 7 21:23:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 21:23:57 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: <-hjIvshm1-PnJJELi-oWqsifdhR86oPhcRU3wn7MnG8=.55b24ef6-38d6-4d3b-a88c-3ca69ffe7941@github.com> Message-ID: On Tue, 7 Oct 2025 11:59:00 GMT, Stefan Karlsson wrote: >> I didn't initially move the definition of the `List` class and it failed to build for me - hence I had to move it. >> >> What is the concern with defining `List` in the header file??? > > It added an unnecessary dependency to the header (SingleWriterSynchronizer) and it made the class uglier than it had to. My 2c. Okay - the problem I had was the definition of the `init` function in the hpp file instead of the cpp file. Fixed per @stefank 's code above. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27664#discussion_r2411955211 From duke at openjdk.org Tue Oct 7 22:28:18 2025 From: duke at openjdk.org (Saint Wesonga) Date: Tue, 7 Oct 2025 22:28:18 GMT Subject: RFR: 8369322: runtime/jni/nativeStack/TestNativeStack.java fails on Windows AArch64 Message-ID: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/blo b/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. ------------- Commit messages: - Implement platform_print_native_stack for Windows AArch64 Changes: https://git.openjdk.org/jdk/pull/27680/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27680&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369322 Stats: 202 lines in 3 files changed: 110 ins; 92 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27680/head:pull/27680 PR: https://git.openjdk.org/jdk/pull/27680 From kbarrett at openjdk.org Tue Oct 7 23:00:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 7 Oct 2025 23:00:42 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 21:23:55 GMT, David Holmes wrote: >> The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. >> >> Testing: >> - tiers 1-3 (sanity) >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Return class List definition to cpp file per Stefan and Kim's requests Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27664#pullrequestreview-3312174879 From dholmes at openjdk.org Wed Oct 8 00:55:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 00:55:11 GMT Subject: RFR: 8369322: runtime/jni/nativeStack/TestNativeStack.java fails on Windows AArch64 In-Reply-To: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: <4nUP7C0ataemljrNYe95v6WA9Ogp45flZPbXMsFD6o0=.bcd6f45e-7679-4212-bfbf-07e335ef996a@github.com> On Tue, 7 Oct 2025 22:19:47 GMT, Saint Wesonga wrote: > HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/b lob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. > > This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. May I suggest changing the JBS issue title to "Implement native stack printing for Windows-Aarch64" and make it an enhancement. I can't speak to the aarch64 specifics but the overall change looks good to me. A couple of minor nits. Thanks src/hotspot/os/windows/os_windows.cpp line 6298: > 6296: */ > 6297: bool os::win32::platform_print_native_stack(outputStream* st, const void* context, > 6298: char *buf, int buf_size, address& lastpc) Suggestion: char* buf, int buf_size, address& lastpc) src/hotspot/os/windows/os_windows.cpp line 6363: > 6361: > 6362: PVOID p = WindowsDbgHelp::symFunctionTableAccess64(GetCurrentProcess(), stk.AddrPC.Offset); > 6363: if (!p) { Suggestion: if (p == nullptr) { Style nit: no implicit booleans EDIT: I see this is pre-existing, but please fix. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27680#pullrequestreview-3312424960 PR Review Comment: https://git.openjdk.org/jdk/pull/27680#discussion_r2412252089 PR Review Comment: https://git.openjdk.org/jdk/pull/27680#discussion_r2412254795 From dholmes at openjdk.org Wed Oct 8 02:01:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:01:05 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 20:54:08 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: > > add cast I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended! As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24694#pullrequestreview-3312513111 From duke at openjdk.org Wed Oct 8 02:25:04 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 02:25:04 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 01:57:59 GMT, David Holmes wrote: > I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended! I'm not sure such code previously would have worked. As far as I can tell, `System.loadLibrary` would fail before reaching `os::dll_load` if the string passed into `System.loadLibrary` could not be resolved to an extant file by `NativeLibraries`. (Okay, I suppose that if `mylib` and `mylib.dll` both exist, `System.loadLibrary("mylib")` would actually load `mylib.dll`. But that actually seems bad?) > > As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. This change doesn't affect the resolution of symlinks now, though. > > I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. liach's observation in https://github.com/openjdk/jdk/pull/24694#issuecomment-3377528055 that the JNI and `System.loadLibrary` should behave similarly likely means some hotspot change is needed. > > But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. I agree that the reproducer in the bug is not something you should do for itself; it is a small self-contained way to demonstrate the regression. I tried to expand on what the broken application actually does a few more places if that helps such as here: https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379336289 From dholmes at openjdk.org Wed Oct 8 02:32:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:32:02 GMT Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 [v5] In-Reply-To: <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> Message-ID: On Tue, 7 Oct 2025 17:05:04 GMT, Saint Wesonga wrote: >> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. >> >> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. >> >> Exceptions with exception codes that are success HRESULT values are also encountered in routine execution on Windows AArch64. One example of an error code for which error reporting should not be done is an exception with the DBG_PRINTEXCEPTION_C exception code, which is encountered in routine execution on Windows AArch64. Such exceptions are excluded from error reporting, similar to how EXCEPTION_BREAKPOINT is excluded. The codes for which error reporting will be performed are those for which the Windows FAILED macro returns true. See [Error Codes in COM >> ](https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com) for more information on COM error handling. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Add missing fix for UncaughtNativeExceptionTest Nothing further from me. Ideally one of the other Windows-aarch64 port developers would also review this. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27074#pullrequestreview-3312547108 From dholmes at openjdk.org Wed Oct 8 02:39:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:39:05 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:22:15 GMT, Benjamin Peterson wrote: > I'm not sure such code previously would have worked. As far as I can tell, System.loadLibrary would fail before reaching os::dll_load if the string passed into System.loadLibrary could not be resolved to an extant file by NativeLibraries. `os::dll_load` is not used only to implement `System.loadLibrary`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379356228 From duke at openjdk.org Wed Oct 8 02:44:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 02:44:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:36:42 GMT, David Holmes wrote: > > I'm not sure such code previously would have worked. As far as I can tell, System.loadLibrary would fail before reaching os::dll_load if the string passed into System.loadLibrary could not be resolved to an extant file by NativeLibraries. > > `os::dll_load` is not used only to implement `System.loadLibrary`. So, this dot logic should be lifted to `JVM_LoadLibrary`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379362093 From dholmes at openjdk.org Wed Oct 8 02:47:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:47:03 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:40:58 GMT, Benjamin Peterson wrote: > So, this dot logic should be lifted to JVM_LoadLibrary? Possibly, but I still want to understand this change as it is now proposed. The whole thing has been about symlinks till now, so now what exactly is the problem and solution? You just want a way to load an arbitrarily-named file as if it were a dll? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379366811 From duke at openjdk.org Wed Oct 8 03:05:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 03:05:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: <_n6Pb0NpMwo5q4DWQ9O2jaFsfB6KLXIELkGmk01vlQg=.3e9a0802-fb23-4824-b6ec-30dfc53f1796@github.com> On Wed, 8 Oct 2025 02:44:42 GMT, David Holmes wrote: > > So, this dot logic should be lifted to JVM_LoadLibrary? > > Possibly, but I still want to understand this change as it is now proposed. The whole thing has been about symlinks till now, so now what exactly is the problem and solution? It's been a windy path. As the PR description says, the problem appeared after JDK-8003887, which was a symlink-related change. JDK-8003887 looks be correct, though, and the regression was due to it exposing underlying problems in the native library loading code. Specifically, `JVM_LoadLibrary` on Windows does not work as expected when given a file without a `.dll` extension. We can make `JVM_LoadLibrary` work with the dot appending trick (current version of the PR), or apply the dot-appending trick in `NativeLibraries` (previous version of the PR). > You just want a way to load an arbitrarily-named file as if it were a dll? That sounds generally desirable. My use case is narrower. The file presented to `System.loadLibrary` does end with `.dll`. But after the path canonicalization done by `NativeLibraries`, the final path does not end with `.dll`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379394592 From dholmes at openjdk.org Wed Oct 8 05:11:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 05:11:03 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> References: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> Message-ID: On Tue, 7 Oct 2025 18:36:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add string in asserts Okay - thanks for clarifying. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27597#pullrequestreview-3312844664 From dholmes at openjdk.org Wed Oct 8 05:18:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 05:18:01 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 22:57:47 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Return class List definition to cpp file per Stefan and Kim's requests > > Looks good. Thanks for the review @kimbarrett ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27664#issuecomment-3379597313 From mbaesken at openjdk.org Wed Oct 8 07:27:50 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 8 Oct 2025 07:27:50 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Make EnhanceErrorWarningLogging DIAGNOSTIC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/695a40eb..0ce49518 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From stefank at openjdk.org Wed Oct 8 07:31:08 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 8 Oct 2025 07:31:08 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 21:23:55 GMT, David Holmes wrote: >> The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. >> >> Testing: >> - tiers 1-3 (sanity) >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Return class List definition to cpp file per Stefan and Kim's requests Thanks for the latest changes. Looks good. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27664#pullrequestreview-3313380630 From dholmes at openjdk.org Wed Oct 8 08:06:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 08:06:42 GMT Subject: RFR: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List [v2] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 07:28:39 GMT, Stefan Karlsson wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Return class List definition to cpp file per Stefan and Kim's requests > > Thanks for the latest changes. Looks good. Thanks for the review @stefank ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27664#issuecomment-3380226026 From azafari at openjdk.org Wed Oct 8 08:48:40 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 08:48:40 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build Message-ID: NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. ------------- Commit messages: - 8369393: NMT: poison the canaries of malloc header under ASAN build Changes: https://git.openjdk.org/jdk/pull/27685/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369393 Stats: 177 lines in 5 files changed: 154 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From lkorinth at openjdk.org Wed Oct 8 09:03:41 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 8 Oct 2025 09:03:41 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 09:34:19 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Rename ram_limit_set to has_ram_limit src/hotspot/share/utilities/globalDefinitions.hpp line 1112: > 1110: return (size_t)MIN2(value, (T)std::numeric_limits::max()); > 1111: } > 1112: Maybe something more generic like this: // return the value of B clamped by the numeric limits of S, casted to S template S clamp_into_from(B value) { static_assert(std::numeric_limits::min() <= std::numeric_limits::min(), "make sure the big type min can hold the small type min"); static_assert(std::numeric_limits::max() >= std::numeric_limits::max(), "make sure the big type max can hold the small type max"); B v = clamp(value, std::numeric_limits::min(), std::numeric_limits::max()); return static_cast(v); } and place it after clamp? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413130935 From jsjolen at openjdk.org Wed Oct 8 09:07:37 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 8 Oct 2025 09:07:37 GMT Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with ASAN In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 07:54:05 GMT, Afshin Zafari wrote: > When ASAN is enabled, memories allocated from ChunkManager are poisoned/unpoisoned. These un-/poisoning are done in ctor/dtor of VirtualSpaceNode and whenever chunks come/leave the ChunkManager list. Since chunks can be merged or split the poisoning should also follow the new memory segments correspondingly. To have a more precise control over where/when do the un-/poisoning, the ASAN poisoning/unpoisoning memory regions is moved after os::uncommit/commit operations. > > Tested on tiers1-5 LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27248#pullrequestreview-3313816775 From lkorinth at openjdk.org Wed Oct 8 09:49:29 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 8 Oct 2025 09:49:29 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 09:00:39 GMT, Leo Korinth wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename ram_limit_set to has_ram_limit > > src/hotspot/share/utilities/globalDefinitions.hpp line 1112: > >> 1110: return (size_t)MIN2(value, (T)std::numeric_limits::max()); >> 1111: } >> 1112: > > Maybe something more generic like this: > > // return the value of B clamped by the numeric limits of S, casted to S > template > S clamp_into_from(B value) { > static_assert(std::numeric_limits::min() <= std::numeric_limits::min(), "make sure the big type min can hold the small type min"); > static_assert(std::numeric_limits::max() >= std::numeric_limits::max(), "make sure the big type max can hold the small type max"); > B v = clamp(value, std::numeric_limits::min(), std::numeric_limits::max()); > return static_cast(v); > } > > and place it after clamp? I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413258617 From azafari at openjdk.org Wed Oct 8 09:52:27 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 09:52:27 GMT Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with ASAN In-Reply-To: References: Message-ID: <2EzoCXBLzo2iaTLvLmNUAlNmq2Div0upLrCBTXs9JOM=.e1dfe0f0-5020-4ed9-a03d-8c174f919f8e@github.com> On Tue, 30 Sep 2025 05:07:12 GMT, Thomas Stuefe wrote: >> When ASAN is enabled, memories allocated from ChunkManager are poisoned/unpoisoned. These un-/poisoning are done in ctor/dtor of VirtualSpaceNode and whenever chunks come/leave the ChunkManager list. Since chunks can be merged or split the poisoning should also follow the new memory segments correspondingly. To have a more precise control over where/when do the un-/poisoning, the ASAN poisoning/unpoisoning memory regions is moved after os::uncommit/commit operations. >> >> Tested on tiers1-5 > > Sorry for the delay, this fell through the cracks somehow. Good. Thanks! Thank you @tstuefe and @jdksjolen for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27248#issuecomment-3380719951 From azafari at openjdk.org Wed Oct 8 09:52:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 09:52:29 GMT Subject: Integrated: 8365385: [asan] os::pretouch_memory() is not compatible with ASAN In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 07:54:05 GMT, Afshin Zafari wrote: > When ASAN is enabled, memories allocated from ChunkManager are poisoned/unpoisoned. These un-/poisoning are done in ctor/dtor of VirtualSpaceNode and whenever chunks come/leave the ChunkManager list. Since chunks can be merged or split the poisoning should also follow the new memory segments correspondingly. To have a more precise control over where/when do the un-/poisoning, the ASAN poisoning/unpoisoning memory regions is moved after os::uncommit/commit operations. > > Tested on tiers1-5 This pull request has now been integrated. Changeset: 6a4c2676 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/6a4c2676a6378f573bd58d1bc32b57765d756291 Stats: 22 lines in 2 files changed: 4 ins; 18 del; 0 mod 8365385: [asan] os::pretouch_memory() is not compatible with ASAN Reviewed-by: stuefe, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27248 From jsikstro at openjdk.org Wed Oct 8 09:57:38 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 8 Oct 2025 09:57:38 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Make limit_by_size_t_max to a static function in arguments.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27224/files - new: https://git.openjdk.org/jdk/pull/27224/files/c6e585e2..b46d124e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=04-05 Stats: 10 lines in 2 files changed: 4 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From jsikstro at openjdk.org Wed Oct 8 09:57:39 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 8 Oct 2025 09:57:39 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 09:47:02 GMT, Leo Korinth wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 1112: >> >>> 1110: return (size_t)MIN2(value, (T)std::numeric_limits::max()); >>> 1111: } >>> 1112: >> >> Maybe something more generic like this: >> >> // return the value of B clamped by the numeric limits of S, casted to S >> template >> S clamp_into_from(B value) { >> static_assert(std::numeric_limits::min() <= std::numeric_limits::min(), "make sure the big type min can hold the small type min"); >> static_assert(std::numeric_limits::max() >= std::numeric_limits::max(), "make sure the big type max can hold the small type max"); >> B v = clamp(value, std::numeric_limits::min(), std::numeric_limits::max()); >> return static_cast(v); >> } >> >> and place it after clamp? > > I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp. I agree, let's make it local to arguments.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413274164 From mbaesken at openjdk.org Wed Oct 8 11:19:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 8 Oct 2025 11:19:01 GMT Subject: RFR: 8368997: AIX allows reading from address zero which leads to several ubsan findings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 14:08:08 GMT, Joachim Kern wrote: > In _SafeFetchXX_internal() a pointer is checked for readability before using. It returns false if this is not the case. The implementation tries to read from the pointer if this is not feasible the signal handler comes into place jumping back to the function via longjmp, so the _SafeFetchXX_internal() itself can return with a false and a null as pseudo content of the address. If the address was readable the function returns true and provides the content of the address. > Because AIX allows reading from address zero, _SafeFetchXX_internal() returns true and follow up functions using the address are called. All these functions end up in an UBSAN finding regarding reading from zero. > The solution could be to manually code that also AIX behaves like other operating systems and returns false and the content zero in case of address zero. Then no UBSAN finding occur. Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27591#pullrequestreview-3314331653 From ayang at openjdk.org Wed Oct 8 11:25:05 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 8 Oct 2025 11:25:05 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6] In-Reply-To: References: Message-ID: <-jc1OS_5p7LgxFY_YEeH_mHtBjGCFVrjiZ8uza8sWL8=.a6c5b1c8-79ed-4c6e-8ba2-03e18ee3dc77@github.com> On Wed, 8 Oct 2025 09:57:38 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Make limit_by_size_t_max to a static function in arguments.cpp Marked as reviewed by ayang (Reviewer). src/hotspot/share/runtime/arguments.cpp line 1510: > 1508: static const size_t DefaultHeapBaseMinAddress = HeapBaseMinAddress; > 1509: > 1510: static size_t limit_by_size_t_max(uint64_t value) { I wonder if `clamp_by_size_t_max` sounds better. Up to you. ------------- PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314359536 PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413529193 From jsikstro at openjdk.org Wed Oct 8 11:32:44 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 8 Oct 2025 11:32:44 GMT Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v7] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Rename limit_by_size_t_max to clamp_by_size_t_max ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27224/files - new: https://git.openjdk.org/jdk/pull/27224/files/b46d124e..47163464 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From azafari at openjdk.org Wed Oct 8 11:35:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 11:35:42 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v2] In-Reply-To: References: Message-ID: <425ISaP05PEBhOb8iXQGz2AFybpGTvtTniDzkUDmH5U=.ba9dd24e-2a06-4ae8-a4fb-f874c6ef50c9@github.com> > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: include sort ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/d67947be..a9f791cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From lkorinth at openjdk.org Wed Oct 8 11:45:06 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 8 Oct 2025 11:45:06 GMT Subject: RFR: 8367413: Fix potential truncation error in Arguments::set_heap_size() [v7] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 11:32:44 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Rename limit_by_size_t_max to clamp_by_size_t_max Looks very good to me. ------------- Marked as reviewed by lkorinth (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314426587 From jsjolen at openjdk.org Wed Oct 8 12:05:25 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 8 Oct 2025 12:05:25 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree In-Reply-To: References: Message-ID: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> On Thu, 11 Sep 2025 09:40:21 GMT, Casper Norrbin wrote: > Hi everyone, > > Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. > > This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. > > Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. > > Testing: > - Oracle tiers 1-8 Looks good to me. Thanks for the cleanup. src/hotspot/share/memory/metaspace/blockTree.hpp line 105: > 103: static Node* cast_to_node(const TreeNode* tree_node) { > 104: return (Node*)((uintptr_t)tree_node - offset_of(Node, _tree_node)); > 105: } We should really have this as a separate static function for the IntrusiveRBNode. It's also technically not a cast, it finds the outer data. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27212#pullrequestreview-3313971296 PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2413245653 From jsjolen at openjdk.org Wed Oct 8 12:13:21 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 8 Oct 2025 12:13:21 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v2] In-Reply-To: <425ISaP05PEBhOb8iXQGz2AFybpGTvtTniDzkUDmH5U=.ba9dd24e-2a06-4ae8-a4fb-f874c6ef50c9@github.com> References: <425ISaP05PEBhOb8iXQGz2AFybpGTvtTniDzkUDmH5U=.ba9dd24e-2a06-4ae8-a4fb-f874c6ef50c9@github.com> Message-ID: On Wed, 8 Oct 2025 11:35:42 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > include sort src/hotspot/share/nmt/mallocHeader.hpp line 142: > 140: footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v; > 141: } > 142: #endif I'd prefer the following. Then we keep the simple definitions separate and as small as previously. ```c++ #if INCLUDE_ASAN // Insert your defs here. #else uint8_t* footer_address() const { return ((address)this) + sizeof(MallocHeader) + _size; } uint16_t get_footer() const { return build_footer(footer_address()[0], footer_address()[1]); } void set_footer(uint16_t v) { footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v; } #endif src/hotspot/share/nmt/mallocHeader.hpp line 191: > 189: inline bool is_poisoned() const { return false; } > 190: inline void set_poisoned(bool poison) { } > 191: #endif Please do the same type of separation that I suggested above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2413634910 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2413642636 From jcking at openjdk.org Wed Oct 8 12:31:58 2025 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Oct 2025 12:31:58 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Tue, 7 Oct 2025 01:28:59 GMT, Kim Barrett wrote: >> This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR. > >> This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR. > > @jcking - I noticed that problem too, while reviewing this change. I don't care > whether it is fixed in this PR or in yours. > > Note that your's currently doesn't perform atomic accesses on the "from" > value. I think that's wrong, since the documentation for these functions > doesn't indicate atomicity only for the store. The comment in copy.hpp says > "atomicity: atomic or non-atomic on the copy unit." I take that to mean both > source and destination. > > Your PR is also not addressing other platforms with similar issues, such as in > copy_ppc.hpp. > > Also, this all begs the question of why we have four different copies of these > functions - bsd_aarch64, bsd_zero, linux_aarch64, and linux_zero. All of these > should be identical. > > Basically, I think the Copy class is kind of a mess, and that discourages its > use. Probably this needs an overall plan of attack (broken up into reviewable > chunks, but with an overarching goal), rather than piecemeal fixups. @kimbarrett Proposal, should we do something similar to AtomicAccess? Provide default naive implementations and let each platform specialize? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3381289286 From jcking at openjdk.org Wed Oct 8 12:33:02 2025 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Oct 2025 12:33:02 GMT Subject: RFR: 8369207: _Copy_conjoint_{jshorts,jints,jlongs}_atomic on Linux/BSD AArch64 do not prevent tearing In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:17:52 GMT, Justin King wrote: > Ensure the compiler cannot optimize the copy loops by replacing them with `memcpy` which is allowed to copy byte by byte potentially introducing tearing. Currently there is nothing preventing the compiler from doing this. We add `volatile` which prevents the compiler from making this optimization in the future. > > Currently the code generates to `ldp` and `stp`, this change does have the side affect of forcing it to do `ldr` and `str`. If that seems unacceptable from a performance standpoint we can hand-roll assembly to do `ldp` and `stp`. Moving this back to draft until discussions in #27642 finish. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27647#issuecomment-3381292689 From jkern at openjdk.org Wed Oct 8 12:36:00 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 8 Oct 2025 12:36:00 GMT Subject: RFR: 8368997: AIX allows reading from address zero which leads to several ubsan findings In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 13:54:51 GMT, Martin Doerr wrote: > I think this is fine. Hotspot should never read from address 0, so returning false should be ok. This essentially emulates the behavior of other operating systems. Should we only catch `adr == nullptr` or all addresses within the first memory page? I would prefer to catch only the nullptr, because this is standard conform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27591#issuecomment-3381302602 From cnorrbin at openjdk.org Wed Oct 8 12:39:10 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 8 Oct 2025 12:39:10 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree In-Reply-To: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> References: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> Message-ID: On Wed, 8 Oct 2025 12:02:13 GMT, Johan Sj?len wrote: >> Hi everyone, >> >> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. >> >> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. >> >> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. >> >> Testing: >> - Oracle tiers 1-8 > > Looks good to me. Thanks for the cleanup. Thank you for reviewing @jdksjolen! Pinging @tstuefe, is this something you could have a look at? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3381313648 From alanb at openjdk.org Wed Oct 8 12:39:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 12:39:10 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com> On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote: >> Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system. > >> You might be correct. We'll see what @AlanBateman and others have to say about it. > > I'm still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails. > > As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix. > As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. > > I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. > > But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. The bug report is an unusual environment where the DLLs in the JDK bin directory are moved and renamed to some other location and without the .dll suffix, and sym links created in their place. That's a bit of distraction. A better starting point for discussion would be a test that exercises System.loadLibrary with the a library name that locates a DLL through a sym link to a final target that doesn't have the .dll suffix. There's a matrix of configurations to test there. Same thing with System.load to see what works and doesn't work. The discussion/proposal was originally to use the platform specific jdk.internal.load.ClassLoaderHelper as that gets used by the implementation of ClassLoader/NativeLibraries code to setup the path to the native library. I think we should stay away from JVM_LoadLibrary and os::dll_load for now, at least until we get come to some consensus on whether is this something that should be allowed (it may require input from security folks). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3381313263 From azafari at openjdk.org Wed Oct 8 12:43:31 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 12:43:31 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v3] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: rearrange ASAN and non-ASAN parts. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/a9f791cf..ca7b9561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=01-02 Stats: 106 lines in 1 file changed: 38 ins; 54 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Wed Oct 8 12:47:40 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 8 Oct 2025 12:47:40 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v2] In-Reply-To: References: <425ISaP05PEBhOb8iXQGz2AFybpGTvtTniDzkUDmH5U=.ba9dd24e-2a06-4ae8-a4fb-f874c6ef50c9@github.com> Message-ID: On Wed, 8 Oct 2025 12:05:56 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> include sort > > src/hotspot/share/nmt/mallocHeader.hpp line 142: > >> 140: footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v; >> 141: } >> 142: #endif > > I'd prefer the following. Then we keep the simple definitions separate and as small as previously. > > ```c++ > #if INCLUDE_ASAN > // Insert your defs here. > #else > uint8_t* footer_address() const { return ((address)this) + sizeof(MallocHeader) + _size; } > uint16_t get_footer() const { return build_footer(footer_address()[0], footer_address()[1]); } > void set_footer(uint16_t v) { footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v; } > #endif Done. > src/hotspot/share/nmt/mallocHeader.hpp line 191: > >> 189: inline bool is_poisoned() const { return false; } >> 190: inline void set_poisoned(bool poison) { } >> 191: #endif > > Please do the same type of separation that I suggested above. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2413737076 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2413736531 From ayang at openjdk.org Wed Oct 8 13:14:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 8 Oct 2025 13:14:35 GMT Subject: RFR: 8367413: Fix potential truncation error in Arguments::set_heap_size() [v7] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 11:32:44 GMT, Joel Sikstr?m wrote: >> Hello, >> >> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. >> >> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. >> >> Testing: >> * Oracle's tier1-8 on all Oracle supported platforms > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Rename limit_by_size_t_max to clamp_by_size_t_max Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314754064 From jsikstro at openjdk.org Wed Oct 8 13:31:25 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 8 Oct 2025 13:31:25 GMT Subject: RFR: 8367413: Fix potential truncation error in Arguments::set_heap_size() [v8] In-Reply-To: References: Message-ID: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8367413_arguments_sizet_julong - Rename limit_by_size_t_max to clamp_by_size_t_max - Make limit_by_size_t_max to a static function in arguments.cpp - Rename ram_limit_set to has_ram_limit - Revert MaxRAM default removals, defer to future enhancement - Namings and comment - 8367413: Refactor types in Arguments::set_heap_size() - Merge branch 'master' into JDK-8367413_arguments_sizet_julong - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp" This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8. - Revert "size_t casts for 32-bit part of test_arguments.cpp" This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625. - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7 ------------- Changes: https://git.openjdk.org/jdk/pull/27224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=07 Stats: 73 lines in 1 file changed: 18 ins; 6 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/27224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224 PR: https://git.openjdk.org/jdk/pull/27224 From duke at openjdk.org Wed Oct 8 19:30:19 2025 From: duke at openjdk.org (Saint Wesonga) Date: Wed, 8 Oct 2025 19:30:19 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: > HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/b lob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. > > This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: Fix style nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27680/files - new: https://git.openjdk.org/jdk/pull/27680/files/1db9af2e..10cc7291 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27680&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27680&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27680/head:pull/27680 PR: https://git.openjdk.org/jdk/pull/27680 From dholmes at openjdk.org Wed Oct 8 20:31:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 20:31:40 GMT Subject: Integrated: 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 06:13:51 GMT, David Holmes wrote: > The `NonJavaThread::List` has a statically allocated instance which contains a `SingleWriterSynchronizer`, which contains a `Semaphore`. The `VMThread` can try to remove itself from the list after the static destructors have executed, leading to an assertion failure for the `Semaphore` but potentially it could crash as the `List` itself gets deallocated.. Simplest fix is to change the `List` instance to a `DeferredStatic` such that it is never destroyed. > > Testing: > - tiers 1-3 (sanity) > > Thanks. This pull request has now been integrated. Changeset: 4d0da18a Author: David Holmes URL: https://git.openjdk.org/jdk/commit/4d0da18ab6e83549e81074e15011cf8a4fbd4ea9 Stats: 25 lines in 3 files changed: 13 ins; 1 del; 11 mod 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List Reviewed-by: kbarrett, stefank ------------- PR: https://git.openjdk.org/jdk/pull/27664 From dholmes at openjdk.org Thu Oct 9 04:51:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Oct 2025 04:51:04 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Wed, 8 Oct 2025 19:30:19 GMT, Saint Wesonga wrote: >> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/ blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. >> >> This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Fix style nits Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27680#pullrequestreview-3317211229 From duke at openjdk.org Thu Oct 9 06:13:04 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Oct 2025 06:13:04 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Wed, 8 Oct 2025 19:30:19 GMT, Saint Wesonga wrote: >> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/ blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. >> >> This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Fix style nits @swesonga Your change (at version 10cc72915a882de9d73a8324122a804be7b69ba9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27680#issuecomment-3384265217 From aboldtch at openjdk.org Thu Oct 9 07:12:03 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 9 Oct 2025 07:12:03 GMT Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black tree In-Reply-To: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> References: <7cZrjdHg5xzP0a1-BMsRLHOJSmxRp0hW-3H1buEraaY=.70ceb41c-0cca-4767-8c3f-9667f9019c65@github.com> Message-ID: On Wed, 8 Oct 2025 09:42:07 GMT, Johan Sj?len wrote: >> Hi everyone, >> >> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance. >> >> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. >> >> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead. >> >> Testing: >> - Oracle tiers 1-8 > > src/hotspot/share/memory/metaspace/blockTree.hpp line 105: > >> 103: static Node* cast_to_node(const TreeNode* tree_node) { >> 104: return (Node*)((uintptr_t)tree_node - offset_of(Node, _tree_node)); >> 105: } > > We should really have this as a separate static function for the IntrusiveRBNode. It's also technically not a cast, it finds the outer data. We could use inheritance `struct Node : public IntrusiveRBNode` and actually have it be a cast. Simplifies some things, not sure if we see other issues. But seems like a valid abstraction that the BlockTree Node is a IntrusiveRBNode. We should probably do an assert that the node is valid() here (Should catch if any none Node IntrusiveRBNode ended up here). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2415773836 From duke at openjdk.org Thu Oct 9 07:41:37 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 9 Oct 2025 07:41:37 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output Message-ID: Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 Fixes: https://bugs.openjdk.org/browse/JDK-8369418 Right now, the AOT Map displays the KlassTrainingData like this: 0x00000008002aa5e0: @@ KlassTrainingData 40 0x00000008002ac260: @@ KlassTrainingData 40 which doesn't provide any context on what class is this training for. Modify the AOT Map Logger so we can link the class to its training data: 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator ------------- Commit messages: - fixes JDK-8369418: Add class name to KlassTrainingData aot map output Changes: https://git.openjdk.org/jdk/pull/27715/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27715&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369418 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27715.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27715/head:pull/27715 PR: https://git.openjdk.org/jdk/pull/27715 From duke at openjdk.org Thu Oct 9 07:41:38 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna) Date: Thu, 9 Oct 2025 07:41:38 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output In-Reply-To: References: Message-ID: <2R2IzqwgmqSeY6fD6HYkLDyiub8__4EfZXS8HFc-Xcs=.28a5db68-dacb-486e-bc88-d5554bcf500c@github.com> On Thu, 9 Oct 2025 07:32:17 GMT, Mar?a Arias de Reyna wrote: > Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369418 > > Right now, the AOT Map displays the KlassTrainingData like this: > > > 0x00000008002aa5e0: @@ KlassTrainingData 40 > 0x00000008002ac260: @@ KlassTrainingData 40 > > > which doesn't provide any context on what class is this training for. > > Modify the AOT Map Logger so we can link the class to its training data: > > > 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader > 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle > 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet > 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports > 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator Some of the KlassTrainingData will not reflect a class name because of https://mail.openjdk.org/pipermail/leyden-dev/2025-October/002764.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/27715#issuecomment-3384538533 From azafari at openjdk.org Thu Oct 9 07:45:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 9 Oct 2025 07:45:37 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v4] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/ca7b9561..d4fc13b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From adinn at openjdk.org Thu Oct 9 07:56:11 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 9 Oct 2025 07:56:11 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 07:32:17 GMT, Mar?a Arias de Reyna wrote: > Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369418 > > Right now, the AOT Map displays the KlassTrainingData like this: > > > 0x00000008002aa5e0: @@ KlassTrainingData 40 > 0x00000008002ac260: @@ KlassTrainingData 40 > > > which doesn't provide any context on what class is this training for. > > Modify the AOT Map Logger so we can link the class to its training data: > > > 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader > 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle > 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet > 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports > 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27715#pullrequestreview-3317651084 From adinn at openjdk.org Thu Oct 9 07:56:13 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 9 Oct 2025 07:56:13 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output In-Reply-To: <2R2IzqwgmqSeY6fD6HYkLDyiub8__4EfZXS8HFc-Xcs=.28a5db68-dacb-486e-bc88-d5554bcf500c@github.com> References: <2R2IzqwgmqSeY6fD6HYkLDyiub8__4EfZXS8HFc-Xcs=.28a5db68-dacb-486e-bc88-d5554bcf500c@github.com> Message-ID: On Thu, 9 Oct 2025 07:33:28 GMT, Mar?a Arias de Reyna wrote: >> Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 >> Fixes: https://bugs.openjdk.org/browse/JDK-8369418 >> >> Right now, the AOT Map displays the KlassTrainingData like this: >> >> >> 0x00000008002aa5e0: @@ KlassTrainingData 40 >> 0x00000008002ac260: @@ KlassTrainingData 40 >> >> >> which doesn't provide any context on what class is this training for. >> >> Modify the AOT Map Logger so we can link the class to its training data: >> >> >> 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader >> 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle >> 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet >> 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports >> 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator > > Some of the KlassTrainingData will not reflect a class name because of https://mail.openjdk.org/pipermail/leyden-dev/2025-October/002764.html @Delawen You need another review -- perhaps from @iklam? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27715#issuecomment-3384594869 From aboldtch at openjdk.org Thu Oct 9 08:11:31 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 9 Oct 2025 08:11:31 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state Message-ID: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. Example stack trace: V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. ------------- Commit messages: - 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state Changes: https://git.openjdk.org/jdk/pull/27716/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369482 Stats: 9 lines in 1 file changed: 5 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27716/head:pull/27716 PR: https://git.openjdk.org/jdk/pull/27716 From jsikstro at openjdk.org Thu Oct 9 08:14:11 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 9 Oct 2025 08:14:11 GMT Subject: RFR: 8369483: Cleanup dead code in HandleArea Message-ID: Hello, When reading up on how HandleArea and HandleMark's work, I found some dead code and comments in the HandleArea class. This makes the code a bit easier to read and understand. Testing: * Oracles tier1-2 ------------- Commit messages: - 8369483: Cleanup dead code in HandleArea Changes: https://git.openjdk.org/jdk/pull/27717/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27717&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369483 Stats: 15 lines in 3 files changed: 1 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27717.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27717/head:pull/27717 PR: https://git.openjdk.org/jdk/pull/27717 From jsikstro at openjdk.org Thu Oct 9 08:21:01 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 9 Oct 2025 08:21:01 GMT Subject: RFR: 8367413: Fix potential truncation error in Arguments::set_heap_size() [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 13:11:18 GMT, Albert Mingkun Yang wrote: >> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into JDK-8367413_arguments_sizet_julong >> - Rename limit_by_size_t_max to clamp_by_size_t_max >> - Make limit_by_size_t_max to a static function in arguments.cpp >> - Rename ram_limit_set to has_ram_limit >> - Revert MaxRAM default removals, defer to future enhancement >> - Namings and comment >> - 8367413: Refactor types in Arguments::set_heap_size() >> - Merge branch 'master' into JDK-8367413_arguments_sizet_julong >> - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp" >> >> This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8. >> - Revert "size_t casts for 32-bit part of test_arguments.cpp" >> >> This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7 > > Marked as reviewed by ayang (Reviewer). For sanity I reran tier1-4, which looks good. Thank you for the reviews @albertnetymk and @lkorinth. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3384683108 From jsikstro at openjdk.org Thu Oct 9 08:21:03 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 9 Oct 2025 08:21:03 GMT Subject: Integrated: 8367413: Fix potential truncation error in Arguments::set_heap_size() In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:39:18 GMT, Joel Sikstr?m wrote: > Hello, > > There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. > > Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion. > > Testing: > * Oracle's tier1-8 on all Oracle supported platforms This pull request has now been integrated. Changeset: af2fbd5a Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/af2fbd5a7182cabdd88764b5653d2ce666f05d70 Stats: 73 lines in 1 file changed: 18 ins; 6 del; 49 mod 8367413: Fix potential truncation error in Arguments::set_heap_size() Reviewed-by: ayang, lkorinth ------------- PR: https://git.openjdk.org/jdk/pull/27224 From fandreuzzi at openjdk.org Thu Oct 9 09:00:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 9 Oct 2025 09:00:35 GMT Subject: RFR: 8369483: Cleanup dead code in HandleArea In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 08:06:35 GMT, Joel Sikstr?m wrote: > Hello, > > When reading up on how HandleArea and HandleMark's work, I found some dead code and comments in the HandleArea class. This makes the code a bit easier to read and understand. > > Testing: > * Oracle's tier1-2 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27717#pullrequestreview-3317903477 From stefank at openjdk.org Thu Oct 9 09:03:40 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 9 Oct 2025 09:03:40 GMT Subject: RFR: 8369483: Cleanup dead code in HandleArea In-Reply-To: References: Message-ID: <_xPku03-JR-7pExEEcnNFBtfmWXM4OKGkKWLCUVFRlw=.b8e449fe-56f5-44c1-bfdb-8f9071f92c6d@github.com> On Thu, 9 Oct 2025 08:06:35 GMT, Joel Sikstr?m wrote: > Hello, > > When reading up on how HandleArea and HandleMark's work, I found some dead code and comments in the HandleArea class. This makes the code a bit easier to read and understand. > > Testing: > * Oracle's tier1-2 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27717#pullrequestreview-3317917106 From jkern at openjdk.org Thu Oct 9 09:48:34 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Oct 2025 09:48:34 GMT Subject: Integrated: 8368997: AIX allows reading from address zero which leads to several ubsan findings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 14:08:08 GMT, Joachim Kern wrote: > In _SafeFetchXX_internal() a pointer is checked for readability before using. It returns false if this is not the case. The implementation tries to read from the pointer if this is not feasible the signal handler comes into place jumping back to the function via longjmp, so the _SafeFetchXX_internal() itself can return with a false and a null as pseudo content of the address. If the address was readable the function returns true and provides the content of the address. > Because AIX allows reading from address zero, _SafeFetchXX_internal() returns true and follow up functions using the address are called. All these functions end up in an UBSAN finding regarding reading from zero. > The solution could be to manually code that also AIX behaves like other operating systems and returns false and the content zero in case of address zero. Then no UBSAN finding occur. This pull request has now been integrated. Changeset: 692c20ce Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/692c20ce1df1526bd175572a61d3355a57d42d02 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8368997: AIX allows reading from address zero which leads to several ubsan findings Reviewed-by: mdoerr, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/27591 From azafari at openjdk.org Thu Oct 9 13:49:19 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 9 Oct 2025 13:49:19 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v5] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: no return from set ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/d4fc13b3..ea9e5b21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From iklam at openjdk.org Thu Oct 9 16:43:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 9 Oct 2025 16:43:51 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 07:32:17 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369418 > > Right now, the AOT Map displays the KlassTrainingData like this: > > > 0x00000008002aa5e0: @@ KlassTrainingData 40 > 0x00000008002ac260: @@ KlassTrainingData 40 > > > which doesn't provide any context on what class is this training for. > > Modify the AOT Map Logger so we can link the class to its training data: > > > 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader > 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle > 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet > 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports > 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator src/hotspot/share/cds/aotMapLogger.hpp line 32: > 30: #include "memory/allStatic.hpp" > 31: #include "oops/oopsHierarchy.hpp" > 32: #include "oops/trainingData.hpp" I header files, if a type can be forward declared, we usually do not include the its header. In this case, we can use: class KlassTrainingData; instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27715#discussion_r2417353670 From duke at openjdk.org Thu Oct 9 17:48:00 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=) Date: Thu, 9 Oct 2025 17:48:00 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output [v2] In-Reply-To: References: Message-ID: > Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369418 > > Right now, the AOT Map displays the KlassTrainingData like this: > > > 0x00000008002aa5e0: @@ KlassTrainingData 40 > 0x00000008002ac260: @@ KlassTrainingData 40 > > > which doesn't provide any context on what class is this training for. > > Modify the AOT Map Logger so we can link the class to its training data: > > > 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader > 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle > 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet > 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports > 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator Mar?a Arias de Reyna Dom?nguez has updated the pull request incrementally with one additional commit since the last revision: Changing the include by a forward declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27715/files - new: https://git.openjdk.org/jdk/pull/27715/files/06c4b672..5ee2f0ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27715&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27715&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27715.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27715/head:pull/27715 PR: https://git.openjdk.org/jdk/pull/27715 From pchilanomate at openjdk.org Thu Oct 9 17:49:33 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 9 Oct 2025 17:49:33 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas wrote: > [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` > which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. > > Example stack trace: > > V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) > V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c > V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 > V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 > V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 > V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 > V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 > V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 > V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 > V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 > V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 > V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 > > > I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. I think `JvmtiExport::has_frame_pops` should just check if `thread->jvmti_thread_state()` is nullptr?and return false, and not try to create the state. Same with `JvmtiExport::continuation_yield_cleanup()`. This `JvmtiExport::get_jvmti_thread_state()` method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the `JvmtiThreadState` created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in `VTMS_unmount_begin` so we would leave the wrong state in the platform thread until the next transition. @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a `!cont.entry()->is_virtual_thread()` check too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3386916577 From pchilanomate at openjdk.org Thu Oct 9 18:01:28 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 9 Oct 2025 18:01:28 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: <9qkFKSVtJbxaB0sHzxOTNUJzOWr1Efy0XxTReTR0-ww=.95fc9bb8-03b4-4d5c-9ac7-2ada4aa697ea@github.com> On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas wrote: > [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` > which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. > > Example stack trace: > > V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) > V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c > V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 > V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 > V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 > V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 > V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 > V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 > V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 > V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 > V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 > V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 > > > I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. Also, pre-existing and maybe for a different bug, but seems we are missing a call to `invalidate_jvmti_stack()` for the preempt case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3386959343 From kbarrett at openjdk.org Thu Oct 9 18:32:06 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 9 Oct 2025 18:32:06 GMT Subject: RFR: 8367717: Cleanup atomic_copy64 [v2] In-Reply-To: References: <3lRD_DjxK4NQqosh-I9RkndecicN7Yp64Hr_h9_Ixpg=.ca230216-7910-4d46-bc94-f2d1ce01c726@github.com> Message-ID: On Wed, 8 Oct 2025 12:29:42 GMT, Justin King wrote: >>> This partially fixes https://bugs.openjdk.org/browse/JDK-8369207 as well, but this only does it for `jlong`. I can wait for this to go in, and then update `jshort` and `jint` to use `AtomicAccess` as well or we can do it all in this PR. >> >> @jcking - I noticed that problem too, while reviewing this change. I don't care >> whether it is fixed in this PR or in yours. >> >> Note that your's currently doesn't perform atomic accesses on the "from" >> value. I think that's wrong, since the documentation for these functions >> doesn't indicate atomicity only for the store. The comment in copy.hpp says >> "atomicity: atomic or non-atomic on the copy unit." I take that to mean both >> source and destination. >> >> Your PR is also not addressing other platforms with similar issues, such as in >> copy_ppc.hpp. >> >> Also, this all begs the question of why we have four different copies of these >> functions - bsd_aarch64, bsd_zero, linux_aarch64, and linux_zero. All of these >> should be identical. >> >> Basically, I think the Copy class is kind of a mess, and that discourages its >> use. Probably this needs an overall plan of attack (broken up into reviewable >> chunks, but with an overarching goal), rather than piecemeal fixups. > > @kimbarrett > > Proposal, should we do something similar to AtomicAccess? Provide default naive implementations and let each platform specialize? @jcking I think AtomicAccess mostly already has platform-specific specializations. A case where it doesn't is the bitops, but there we have a default naive implementation, with the intent that platforms will (eventually) specialize. There's one of those efforts being reviewed now (for ppc). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27642#issuecomment-3387058047 From mbeckwit at openjdk.org Thu Oct 9 19:23:18 2025 From: mbeckwit at openjdk.org (Monica Beckwith) Date: Thu, 9 Oct 2025 19:23:18 GMT Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 [v5] In-Reply-To: <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> Message-ID: On Tue, 7 Oct 2025 17:05:04 GMT, Saint Wesonga wrote: >> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. >> >> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. >> >> Exceptions with exception codes that are success HRESULT values are also encountered in routine execution on Windows AArch64. One example of an error code for which error reporting should not be done is an exception with the DBG_PRINTEXCEPTION_C exception code, which is encountered in routine execution on Windows AArch64. Such exceptions are excluded from error reporting, similar to how EXCEPTION_BREAKPOINT is excluded. The codes for which error reporting will be performed are those for which the Windows FAILED macro returns true. See [Error Codes in COM >> ](https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com) for more information on COM error handling. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Add missing fix for UncaughtNativeExceptionTest LGTM - Thanks for fixing this @swesonga Reviewed the Windows aarch64 exception handling implementation: - FAILED() macro usage correct for vectored exception handling - SafeFetch integration properly handles fault/continuation pattern - Test update with 0xdeadbeef appropriately validates the filtering logic - Clean platform-specific conditional compilation Good fix for the crash handling issues. ------------- Marked as reviewed by mbeckwit (Author). PR Review: https://git.openjdk.org/jdk/pull/27074#pullrequestreview-3320338147 From duke at openjdk.org Thu Oct 9 19:27:42 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Oct 2025 19:27:42 GMT Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 [v5] In-Reply-To: <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> <1eHrwyhvPwN6o5apVAUlyXIH0Co2uJcHqGYJT6qXKaU=.6c8601b5-02cc-40e5-a224-b05f53e3ee92@github.com> Message-ID: On Tue, 7 Oct 2025 17:05:04 GMT, Saint Wesonga wrote: >> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. >> >> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. >> >> Exceptions with exception codes that are success HRESULT values are also encountered in routine execution on Windows AArch64. One example of an error code for which error reporting should not be done is an exception with the DBG_PRINTEXCEPTION_C exception code, which is encountered in routine execution on Windows AArch64. Such exceptions are excluded from error reporting, similar to how EXCEPTION_BREAKPOINT is excluded. The codes for which error reporting will be performed are those for which the Windows FAILED macro returns true. See [Error Codes in COM >> ](https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com) for more information on COM error handling. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Add missing fix for UncaughtNativeExceptionTest @swesonga Your change (at version 9faaa856663c79588b8508ee7a540d344e2b92b6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27074#issuecomment-3387218535 From ysuenaga at openjdk.org Thu Oct 9 23:34:20 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 9 Oct 2025 23:34:20 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 Message-ID: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) And also I got following (strange) stacks which causes `AssersionFailure` in above: ----------------- 70094 ----------------- "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f8f64658462 __syscall_cancel_arch + 0x32 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c 0x00007f8f646a8c37 __GI___nanosleep + 0x17 0x00007f8f646bb14e __sleep + 0x3e 0x00007f8f4b3a8e1e 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c050800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame) 0x00007f8f4b33fe48 * jdk.internal.foreign.abi.DowncallStub+0x000000000c048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x00007f8f4b33fe48 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame) 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c04e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame) 0x00007f8f4b33fd00 * java.lang.invoke.LambdaForm$MH+0x000000000c04c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame) 0x00007f8f4b33fd00 * Test.run() bci:21 line:28 (Interpreted frame) 0x00007f8f4b33e098 0x00007f8f4b33fd00 return entry points 0x00007f8f4b33fd00 return entry points 0x00007f8f4b33fd00 return entry points 0x00007f8f4b340206 return entry points 0x00007f8f4b33fe9a return entry points 0x00007f8f4b33fe9a return entry points 0x00007f8f4b33fe48 return entry points 0x00007f8f4b33fd00 return entry points 0x00007f8f4b33fd00 return entry points 0x00007f8f4b33fd00 return entry points 0x00007f8f4b3386fd 0x00007f8f62bc0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce 0x00007f8f62bc11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3 0x00007f8f62bc17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab 0x00007f8f62d83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0 0x00007f8f62c02806 JavaThread::thread_main_inner() + 0x256 0x00007f8f63865b57 Thread::call_run() + 0xb7 0x00007f8f632fc588 thread_native_entry(Thread*) + 0x128 0x00007f8f6464ff54 start_thread + 0x2e4 According to stack layout described in continuationFreezeThaw.cpp and stub implementation in `StubGenerator::generate_cont_thaw()` in stubGenerator_x86_64.cpp, we cannot calculate caller SP from `CodeBlob` for continuation stub. We need to restore SP from `_cont_entry` in `JavaThread`. After this fix, we can see following stacks: ----------------- 39371 ----------------- "ForkJoinPool-1-worker-1" #27 daemon prio=5 tid=0x00007fe83036f230 nid=39371 runnable [0x00007fe815e06000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007fe839b17462 __syscall_cancel_arch + 0x32 0x00007fe839b0b75c __internal_syscall_cancel + 0x5c 0x00007fe839b67c37 __GI___nanosleep + 0x17 0x00007fe839b7a14e __sleep + 0x3e 0x00007fe81f3a859e 0x00007fe81f33fe48 * java.lang.invoke.LambdaForm$MH+0x0000000041047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) 0x00007fe81f33fe48 * java.lang.invoke.LambdaForm$MH+0x0000000041051400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame) 0x00007fe81f33fe48 * jdk.internal.foreign.abi.DowncallStub+0x0000000041048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x00007fe81f33fe48 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame) 0x00007fe81f33fe48 * java.lang.invoke.LambdaForm$MH+0x000000004104e800.invoke(java.lang.Object, int) bci:44 (Interpreted frame) 0x00007fe81f33fd00 * java.lang.invoke.LambdaForm$MH+0x000000004104d800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame) 0x00007fe81f33fd00 * Test.run() bci:21 line:28 (Interpreted frame) 0x00007fe81f33e098 0x00007fe81f33fd00 * jdk.internal.vm.Continuation.run() bci:122 line:248 (Interpreted frame) 0x00007fe81f33fd00 * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Interpreted frame) 0x00007fe81f33fd00 * java.lang.VirtualThread$$Lambda+0x0000000041029b58.run() bci:4 (Interpreted frame) 0x00007fe81f340206 * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:4 line:1753 (Interpreted frame) 0x00007fe81f33fe9a * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:1 line:1745 (Interpreted frame) 0x00007fe81f33fe9a * java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() bci:51 line:1662 (Interpreted frame) 0x00007fe81f33fe48 * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Interpreted frame) 0x00007fe81f33fd00 * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Interpreted frame) 0x00007fe81f33fd00 * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame) 0x00007fe81f33fd00 * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Interpreted frame) 0x00007fe81f3386fd 0x00007fe837fc0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce 0x00007fe837fc11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3 0x00007fe837fc17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab 0x00007fe838183a90 thread_entry(JavaThread*, JavaThread*) + 0xd0 0x00007fe838002806 JavaThread::thread_main_inner() + 0x256 0x00007fe838c65b57 Thread::call_run() + 0xb7 0x00007fe8386fc588 thread_native_entry(Thread*) + 0x128 0x00007fe839b0ef54 start_thread + 0x2e4 I saw this issue on Linux AMD64. I'm not sure but it might happen on another platforms. I haven't yet created a complete reproducer, but Test.java on JBS can be reproduced with high probability. ------------- Commit messages: - 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 Changes: https://git.openjdk.org/jdk/pull/27728/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369505 Stats: 93 lines in 6 files changed: 91 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From iklam at openjdk.org Fri Oct 10 00:38:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 10 Oct 2025 00:38:04 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output [v2] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 17:48:00 GMT, Mar?a Arias de Reyna Dom?nguez wrote: >> Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 >> Fixes: https://bugs.openjdk.org/browse/JDK-8369418 >> >> Right now, the AOT Map displays the KlassTrainingData like this: >> >> >> 0x00000008002aa5e0: @@ KlassTrainingData 40 >> 0x00000008002ac260: @@ KlassTrainingData 40 >> >> >> which doesn't provide any context on what class is this training for. >> >> Modify the AOT Map Logger so we can link the class to its training data: >> >> >> 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader >> 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle >> 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet >> 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports >> 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator > > Mar?a Arias de Reyna Dom?nguez has updated the pull request incrementally with one additional commit since the last revision: > > Changing the include by a forward declaration Looks good to me ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27715#pullrequestreview-3321006817 From duke at openjdk.org Fri Oct 10 03:59:15 2025 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 10 Oct 2025 03:59:15 GMT Subject: Integrated: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com> Message-ID: On Wed, 3 Sep 2025 14:45:27 GMT, Saint Wesonga wrote: > The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change. > > Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler. > > Exceptions with exception codes that are success HRESULT values are also encountered in routine execution on Windows AArch64. One example of an error code for which error reporting should not be done is an exception with the DBG_PRINTEXCEPTION_C exception code, which is encountered in routine execution on Windows AArch64. Such exceptions are excluded from error reporting, similar to how EXCEPTION_BREAKPOINT is excluded. The codes for which error reporting will be performed are those for which the Windows FAILED macro returns true. See [Error Codes in COM > ](https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com) for more information on COM error handling. This pull request has now been integrated. Changeset: f4209dff Author: Saint Wesonga Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/f4209dff3ba14ccbdc0846d9bfcc62688361b6d5 Stats: 186 lines in 8 files changed: 145 ins; 29 del; 12 mod 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 Reviewed-by: dholmes, mbeckwit ------------- PR: https://git.openjdk.org/jdk/pull/27074 From dholmes at openjdk.org Fri Oct 10 05:53:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Oct 2025 05:53:05 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Wed, 8 Oct 2025 19:30:19 GMT, Saint Wesonga wrote: >> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/ blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. >> >> This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Fix style nits Two reviews are needed before integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27680#issuecomment-3388381484 From sspitsyn at openjdk.org Fri Oct 10 06:03:07 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 10 Oct 2025 06:03:07 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Thu, 9 Oct 2025 17:45:23 GMT, Patricio Chilano Mateo wrote: > I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition. Thank you, Patrico! I agree with this. Below is the patch for this change. diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp index 077b3fec505..fa6ede86cd9 100644 --- a/src/hotspot/share/prims/jvmtiExport.cpp +++ b/src/hotspot/share/prims/jvmtiExport.cpp @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) { if (!can_post_frame_pop()) { return false; } - JvmtiThreadState *state = get_jvmti_thread_state(thread); + JvmtiThreadState *state = thread->jvmti_thread_state(); if (state == nullptr) { return false; } @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati } assert(thread == JavaThread::current(), "must be"); - JvmtiThreadState *state = get_jvmti_thread_state(thread); + JvmtiThreadState *state = thread->jvmti_thread_state(); if (state == nullptr) { return; } > @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too? Good idea. I was also thinking about it at some point. > Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case. I can be but could you be more presize about the preempt case? What place do you mean? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388398133 From aboldtch at openjdk.org Fri Oct 10 06:29:40 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 10 Oct 2025 06:29:40 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v2] In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: > [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` > which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. > > Example stack trace: > > V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) > V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c > V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 > V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 > V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 > V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 > V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 > V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 > V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 > V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 > V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 > V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 > > > I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - sspitsyn patch - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state" This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27716/files - new: https://git.openjdk.org/jdk/pull/27716/files/e133d9b7..4ec7ce98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27716/head:pull/27716 PR: https://git.openjdk.org/jdk/pull/27716 From aboldtch at openjdk.org Fri Oct 10 06:35:01 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 10 Oct 2025 06:35:01 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn wrote: > I agree with this. Below is the patch for this change. Done. I was also wondering why the original patch change from just `JavaThread::jvmti_thread_state` to `get_jvmti_thread_state`. But it looked so intentional, I thought it was fundamental to JDK-8368159. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388474246 From jsikstro at openjdk.org Fri Oct 10 08:15:04 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 10 Oct 2025 08:15:04 GMT Subject: RFR: 8369483: Cleanup dead code in HandleArea In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 08:58:06 GMT, Francesco Andreuzzi wrote: >> Hello, >> >> When reading up on how HandleArea and HandleMark's work I found some dead code and comments in the HandleArea class. This makes the code a bit easier to read and understand. >> >> Testing: >> * Oracle's tier1-2 > > Marked as reviewed by fandreuzzi (Author). Thank you for the reviews! @fandreuz @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/27717#issuecomment-3388766574 From jsikstro at openjdk.org Fri Oct 10 08:15:05 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 10 Oct 2025 08:15:05 GMT Subject: Integrated: 8369483: Cleanup dead code in HandleArea In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 08:06:35 GMT, Joel Sikstr?m wrote: > Hello, > > When reading up on how HandleArea and HandleMark's work I found some dead code and comments in the HandleArea class. This makes the code a bit easier to read and understand. > > Testing: > * Oracle's tier1-2 This pull request has now been integrated. Changeset: 1159b53b Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/1159b53bfcfce771a23506394d998b0d95eb8981 Stats: 15 lines in 3 files changed: 1 ins; 8 del; 6 mod 8369483: Cleanup dead code in HandleArea Reviewed-by: fandreuzzi, stefank ------------- PR: https://git.openjdk.org/jdk/pull/27717 From duke at openjdk.org Fri Oct 10 08:32:23 2025 From: duke at openjdk.org (duke) Date: Fri, 10 Oct 2025 08:32:23 GMT Subject: RFR: 8369418: Identify owning class for KlassTrainingData in AOT map output [v2] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 17:48:00 GMT, Mar?a Arias de Reyna Dom?nguez wrote: >> Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 >> Fixes: https://bugs.openjdk.org/browse/JDK-8369418 >> >> Right now, the AOT Map displays the KlassTrainingData like this: >> >> >> 0x00000008002aa5e0: @@ KlassTrainingData 40 >> 0x00000008002ac260: @@ KlassTrainingData 40 >> >> >> which doesn't provide any context on what class is this training for. >> >> Modify the AOT Map Logger so we can link the class to its training data: >> >> >> 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader >> 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle >> 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet >> 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports >> 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator > > Mar?a Arias de Reyna Dom?nguez has updated the pull request incrementally with one additional commit since the last revision: > > Changing the include by a forward declaration @Delawen Your change (at version 5ee2f0ea3c042a614b28d5dd430360d91097b881) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27715#issuecomment-3388860107 From sspitsyn at openjdk.org Fri Oct 10 08:42:10 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 10 Oct 2025 08:42:10 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn wrote: >> I think `JvmtiExport::has_frame_pops` should just check if `thread->jvmti_thread_state()` is nullptr?and return false, and not try to create the state. Same with `JvmtiExport::continuation_yield_cleanup()`. This `JvmtiExport::get_jvmti_thread_state()` method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the `JvmtiThreadState` created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in `VTMS_unmount_begin` so we would leave the wrong state in the platform thread until the next transition. >> >> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a `!cont.entry()->is_virtual_thread()` check too? > >> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition. > > Thank you, Patrico! > I agree with this. Below is the patch for this change. > > > diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp > index 077b3fec505..fa6ede86cd9 100644 > --- a/src/hotspot/share/prims/jvmtiExport.cpp > +++ b/src/hotspot/share/prims/jvmtiExport.cpp > @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) { > if (!can_post_frame_pop()) { > return false; > } > - JvmtiThreadState *state = get_jvmti_thread_state(thread); > + JvmtiThreadState *state = thread->jvmti_thread_state(); > if (state == nullptr) { > return false; > } > @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati > } > > assert(thread == JavaThread::current(), "must be"); > - JvmtiThreadState *state = get_jvmti_thread_state(thread); > + JvmtiThreadState *state = thread->jvmti_thread_state(); > if (state == nullptr) { > return; > } > > >> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too? > > Good idea. I was also thinking about it at some point. > >> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case. > > I can be but could you be more presize about the preempt case? What place do you mean? > /author @sspitsyn This suggestion came from Patricio. :) > I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159. Wrong assumptions. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388899792 From clanger at openjdk.org Fri Oct 10 09:18:07 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Oct 2025 09:18:07 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 07:27:50 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Make EnhanceErrorWarningLogging DIAGNOSTIC I think adding a new diagnostic flag named `EnhanceErrorWarningLogging` in addition to `PrintMiscellaneous`and `Verbose` unnecessarily convolutes things and the name of the new option is not really obvious. I would rather add a flag like `TracePerfMemory` and replace usage of `(PrintMiscellaneous && Verbose)` with the new flag or change `PrintMiscellaneous` and `Verbose` to diagnostic flags such that they are available in product VMs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3389017140 From duke at openjdk.org Fri Oct 10 09:49:32 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=) Date: Fri, 10 Oct 2025 09:49:32 GMT Subject: Integrated: 8369418: Identify owning class for KlassTrainingData in AOT map output In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 07:32:17 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Contains patches for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369418 > > Right now, the AOT Map displays the KlassTrainingData like this: > > > 0x00000008002aa5e0: @@ KlassTrainingData 40 > 0x00000008002ac260: @@ KlassTrainingData 40 > > > which doesn't provide any context on what class is this training for. > > Modify the AOT Map Logger so we can link the class to its training data: > > > 0x00000008007d5940: @@ KlassTrainingData 40 jdk.internal.loader.BuiltinClassLoader > 0x0000000800815398: @@ KlassTrainingData 40 java.lang.invoke.DirectMethodHandle > 0x00000008008791f0: @@ KlassTrainingData 40 java.util.HashSet > 0x00000008008bd980: @@ KlassTrainingData 40 java.lang.module.ModuleDescriptor$Exports > 0x00000008008db8e8: @@ KlassTrainingData 40 java.lang.invoke.InvokerBytecodeGenerator This pull request has now been integrated. Changeset: f52aed6f Author: Mar?a Arias de Reyna Dom?nguez Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/f52aed6f81e7df9ab9a379ada952b8e666c54e6d Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod 8369418: Identify owning class for KlassTrainingData in AOT map output Reviewed-by: iklam, adinn ------------- PR: https://git.openjdk.org/jdk/pull/27715 From azafari at openjdk.org Fri Oct 10 10:16:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 10 Oct 2025 10:16:02 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v6] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: gtest fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/ea9e5b21..601b5b2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=04-05 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From sspitsyn at openjdk.org Fri Oct 10 10:25:53 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 10 Oct 2025 10:25:53 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: <0O2-w0R94vfTJjRk7iVnL2EBImcfgmYNLHpI-gXEHlQ=.7937917d-80d9-493c-ab42-747001694da9@github.com> On Fri, 10 Oct 2025 08:39:37 GMT, Serguei Spitsyn wrote: >>> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition. >> >> Thank you, Patrico! >> I agree with this. Below is the patch for this change. >> >> >> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp >> index 077b3fec505..fa6ede86cd9 100644 >> --- a/src/hotspot/share/prims/jvmtiExport.cpp >> +++ b/src/hotspot/share/prims/jvmtiExport.cpp >> @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) { >> if (!can_post_frame_pop()) { >> return false; >> } >> - JvmtiThreadState *state = get_jvmti_thread_state(thread); >> + JvmtiThreadState *state = thread->jvmti_thread_state(); >> if (state == nullptr) { >> return false; >> } >> @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati >> } >> >> assert(thread == JavaThread::current(), "must be"); >> - JvmtiThreadState *state = get_jvmti_thread_state(thread); >> + JvmtiThreadState *state = thread->jvmti_thread_state(); >> if (state == nullptr) { >> return; >> } >> >> >>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too? >> >> Good idea. I was also thinking about it at some point. >> >>> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case. >> >> I can be but could you be more presize about the preempt case? What place do you mean? > >> /author @sspitsyn > > This suggestion came from Patricio. :) > >> I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159. > > Wrong assumptions. :) For consistency with `JvmtiExport::continuation_yield_cleanup()`. > @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too? This is one more suggestion from Patricio (I'm testing it now): diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 33b4f2bf488..3e509e71551 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -1626,7 +1626,7 @@ static void invalidate_jvmti_stack(JavaThread* thread) { } static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { - if (JvmtiExport::has_frame_pops(thread)) { + if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { int num_frames = num_java_frames(cont); ContinuationWrapper::SafepointOp so(Thread::current(), cont); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3389242915 From mbaesken at openjdk.org Fri Oct 10 11:30:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Oct 2025 11:30:01 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 09:14:41 GMT, Christoph Langer wrote: > or change PrintMiscellaneous and Verbose to diagnostic flags such that they are available in product VMs. Might be an option ; PrintMiscellaneous is used besides perfMemory also at some more places , e.g. C2 JIT. See below cpu/x86/vm_version_x86.cpp:1392: if (supports_avx() && PrintMiscellaneous && Verbose && TraceNewVectors) { os/posix/perfMemory_posix.cpp:74: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:300: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:374: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:414: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:421: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:450: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:683: if (PrintMiscellaneous && Verbose && result == OS_ERR) { os/posix/perfMemory_posix.cpp:825: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:835: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:875: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:927: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:936: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:1060: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:1138: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:1215: if (PrintMiscellaneous && Verbose) { os/posix/perfMemory_posix.cpp:1251: if (PrintMiscellaneous && Verbose) { os/windows/os_windows.cpp:3350: if (Verbose && PrintMiscellaneous) reserveTimer.start(); os/windows/os_windows.cpp:3357: if (Verbose && PrintMiscellaneous) { os/windows/perfMemory_windows.cpp:65: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:99: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:108: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:120: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:223: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:237: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:256: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:495: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:518: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:529: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:548: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:556: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:579: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:589: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:598: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:707: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:720: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:786: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:798: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:811: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:824: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:869: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:889: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:917: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:930: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:957: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:972: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:988: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:996: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1008: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1028: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1060: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1117: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1135: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1239: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1252: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1259: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1328: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1356: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1372: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1405: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1488: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1554: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1562: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1640: if (PrintMiscellaneous && Verbose) { os/windows/perfMemory_windows.cpp:1711: if (PrintMiscellaneous && Verbose) { share/compiler/disassembler.cpp:861: : ((WizardMode || PrintMiscellaneous) share/opto/graphKit.cpp:856: if (PrintMiscellaneous && (Verbose || WizardMode)) { share/opto/gcm.cpp:739: (PrintMiscellaneous && (WizardMode || Verbose)))) { share/opto/library_call.cpp:787: if ((PrintMiscellaneous && (Verbose || WizardMode)) || PrintOpto) { share/opto/library_call.cpp:825: if ((PrintMiscellaneous && (Verbose || WizardMode)) || PrintOpto) { share/opto/matcher.cpp:1001: if (PrintOpto || (PrintMiscellaneous && (WizardMode || Verbose))) { share/runtime/globals.hpp:521: develop(bool, PrintMiscellaneous, false, \ share/runtime/perfData.cpp:227: if (PrintMiscellaneous && Verbose) { share/runtime/perfMemory.cpp:117: if (PrintMiscellaneous && Verbose) { share/runtime/perfMemory.cpp:177: if (PrintMiscellaneous && Verbose) { share/runtime/perfMemory.cpp:253: if (PrintMiscellaneous && Verbose) { Would it be okay to offer this in product JVMs ? (Verbose is even harder to say, because it is used more) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3389510553 From duke at openjdk.org Fri Oct 10 11:33:36 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=) Date: Fri, 10 Oct 2025 11:33:36 GMT Subject: RFR: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output Message-ID: Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 Fixes: https://bugs.openjdk.org/browse/JDK-8369559 Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: $ cat aot.map | grep MethodTrainingData 0x00000008019d54c0: @@ MethodTrainingData 96 0x00000008019dcec8: @@ MethodTrainingData 96 [...] $ cat aot.map | grep CompileTrainingData [...] 0x000000080079c8a0: @@ CompileTrainingData 80 0x00000008007a7660: @@ CompileTrainingData 80 Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. The output should look like the following: $ cat aot.map | grep CompileTrainingData 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() [...] $ cat aot.map | grep MethodTrainingData 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) [...] Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). ------------- Commit messages: - Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output Changes: https://git.openjdk.org/jdk/pull/27740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369559 Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27740/head:pull/27740 PR: https://git.openjdk.org/jdk/pull/27740 From mbaesken at openjdk.org Fri Oct 10 14:46:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Oct 2025 14:46:04 GMT Subject: RFR: 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files Message-ID: When running with stripped pdb files, the gtest dll_address_to_function_and_library_name can find output like "0x... in ..." instead of usual strings. So this test should better check for this. See also https://github.com/openjdk/jdk/pull/24012/files#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884 where this was discussed as part of a larger change. ------------- Commit messages: - JDK-8369563 Changes: https://git.openjdk.org/jdk/pull/27745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369563 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27745/head:pull/27745 PR: https://git.openjdk.org/jdk/pull/27745 From clanger at openjdk.org Fri Oct 10 14:46:05 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Oct 2025 14:46:05 GMT Subject: RFR: 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files In-Reply-To: References: Message-ID: <5FIpKeVbpk9th3EB7Dnu_vFdQrjouW5WcQhLhv8nMwQ=.f317ad51-18a5-45ec-a53c-c24bab014e4d@github.com> On Fri, 10 Oct 2025 14:36:24 GMT, Matthias Baesken wrote: > When running with stripped pdb files, the gtest dll_address_to_function_and_library_name > can find output like "0x... in ..." instead of usual strings. > So this test should better check for this. > See also > https://github.com/openjdk/jdk/pull/24012/files#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884 > > where this was discussed as part of a larger change. LGTM ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27745#pullrequestreview-3324013165 From pchilanomate at openjdk.org Fri Oct 10 14:56:15 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 10 Oct 2025 14:56:15 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn wrote: > > Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case. > > I can be but could you be more presize about the preempt case? What place do you mean? > So after freezing for the preempt case we should also call `invalidate_jvmti_stack()` in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3390600355 From pchilanomate at openjdk.org Fri Oct 10 15:22:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 10 Oct 2025 15:22:58 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... I can reproduce it with the attached test too. The issue happens when the return pc of the sender frame is the return barrier, which will be the case if the virtual thread was unmounted at some earlier point and there are still frames freezed in the stackChunk (see `frame::sender_for_interpreter_frame` and `frame::sender_for_compiled_frame` for handling this case in the VM). In your test, unmounting can happen at the `System.out.println` call. So this issue will be present in the other platforms too. I tested the fix for x64 and looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3390733064 From cjplummer at openjdk.org Fri Oct 10 19:27:09 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Oct 2025 19:27:09 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... I'm seeing a similar exception on macosx-aarch64 with your test, however, I don't see all the frames that you are seeing. The stack dump stops at `Test.run()`. Also, on threads that are fully dumped, the output is different than you working dump above. I'm not sure if this is expected: "ForkJoinPool-1-worker-6" #33 daemon prio=5 tid=0x0000000147856810 nid=41731 runnable [0x0000000172df5000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - java.lang.invoke.LambdaForm$MH+0x0000000801047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x0000000801054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) - jdk.internal.foreign.abi.DowncallStub+0x0000000801048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) - java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000000080104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000000080104e000.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) - Test.run() @bci=21, line=28 (Interpreted frame) - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1487 (Interpreted frame) - java.lang.VirtualThread.run(java.lang.Runnable) @bci=62, line=456 (Interpreted frame) - java.lang.VirtualThread$VThreadContinuation$1.run() @bci=15, line=248 (Interpreted frame) - jdk.internal.vm.Continuation.enter0() @bci=4, line=322 (Interpreted frame) - jdk.internal.vm.Continuation.enter(jdk.internal.vm.Continuation, boolean) @bci=1, line=313 (Interpreted frame) - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) - jdk.internal.vm.Continuation.run() @bci=122, line=248 (Interpreted frame) - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) - java.lang.VirtualThread$$Lambda+0x0000000801027670.run() @bci=4 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame) - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame) I can see if your changes are applicable to aarch64. If they work, then great, if not, I'll probably need some help getting it right. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391989222 PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391996631 From cjplummer at openjdk.org Fri Oct 10 19:31:01 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Oct 2025 19:31:01 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Can you convert your test to JTREG? It would make it a lot easier to test fixes on all platforms. Also, the fix is a bit fragile and it would be nice to quickly detect if it breaks again in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392014129 From sspitsyn at openjdk.org Fri Oct 10 19:51:05 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 10 Oct 2025 19:51:05 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Fri, 10 Oct 2025 14:53:41 GMT, Patricio Chilano Mateo wrote: > So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug. We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392113146 From cjplummer at openjdk.org Fri Oct 10 19:55:01 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Oct 2025 19:55:01 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) - Test.run() @bci=21, line=28 (Interpreted frame) - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame) - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame) "ForkJoinPool-1-worker-6" #36 daemon prio=5 tid=0x0000000159052610 nid=42243 runnable [0x000000017296d000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) - java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe01050400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) - Test.run() @bci=21, line=28 (Interpreted frame) - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1487 (Interpreted frame) - java.lang.VirtualThread.run(java.lang.Runnable) @bci=62, line=456 (Interpreted frame) - java.lang.VirtualThread$VThreadContinuation$1.run() @bci=15, line=248 (Interpreted frame) - jdk.internal.vm.Continuation.enter0() @bci=4, line=322 (Interpreted frame) - jdk.internal.vm.Continuation.enter(jdk.internal.vm.Continuation, boolean) @bci=1, line=313 (Interpreted frame) - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) - jdk.internal.vm.Continuation.run() @bci=122, line=248 (Interpreted frame) - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame) - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392130193 From pchilanomate at openjdk.org Fri Oct 10 20:37:02 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 10 Oct 2025 20:37:02 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com> On Fri, 10 Oct 2025 19:48:47 GMT, Serguei Spitsyn wrote: > > So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug. > > We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything? > Yes, but we are calling the other overload of `freeze_epilog()` which only logs and verifies the continuation. : ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392242151 From pchilanomate at openjdk.org Fri Oct 10 20:41:00 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 10 Oct 2025 20:41:00 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer wrote: > I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. > These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392251835 From sspitsyn at openjdk.org Fri Oct 10 22:33:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 10 Oct 2025 22:33:01 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com> Message-ID: On Fri, 10 Oct 2025 20:34:42 GMT, Patricio Chilano Mateo wrote: > Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : ) I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well? I've filed new JVMTI bug: [8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392488763 From ysuenaga at openjdk.org Sat Oct 11 02:45:04 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 02:45:04 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. > > "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) > - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) > - Test.run() @bci=21, line=28 (Interpreted frame) > - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) > - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) > - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) > - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) > - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) > - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) > - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.F... @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least). Thanks @pchilano for explaining the problem, I understood it relates to unmount, it is triggered by `System.out.println` and we can replace it to `Thread.yield`. I can convert Test.java to JTREG test of course, However I'm not sure how we can reproduce this issue 100%. I guess the problem is very similar with race-condition - dependent on timing. Do you have any idea to happen the problem exactly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392807014 From ysuenaga at openjdk.org Sat Oct 11 03:16:03 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 03:16:03 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: <34sQ54VukmkIdGeSWUrfO_wNuBXsBn4c13dNjqCyUsA=.119a9ecd-04a9-415b-8e77-c83e7c8b5506@github.com> On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... I saw same issue in JDK 25 on Fedora Rawhide on Raspberry Pi 4. I will try to fix on AArch64. Server compiler detected. JVM version is 25+36-3489 sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:414) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.sender(AARCH64Frame.java:295) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:207) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:212) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) ----------------- 1884 ----------------- "ForkJoinPool-1-worker-4" #30 daemon prio=5 tid=0x0000ffff982c0ce0 nid=1884 runnable [0x0000ffff4d20b000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x0000ffffa03282e8 __syscall_cancel_arch + 0x28 0x0000ffffa0358b7c __clock_nanosleep + 0x3c 0x0000ffffa0363740 __GI___nanosleep + 0x20 0x0000ffffa0373f50 __sleep + 0x50 0x0000ffff87c4c878 0x0000ffff87b3b910 * java.lang.invoke.LambdaForm$MH+0x0000004001047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) 0x0000ffff87b3b910 * java.lang.invoke.LambdaForm$MH+0x000000400104fc00.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame) 0x0000ffff87b3b910 * jdk.internal.foreign.abi.DowncallStub+0x0000004001048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x0000ffff87b3b910 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame) 0x0000ffff87b3b910 * java.lang.invoke.LambdaForm$MH+0x000000400104dc00.invoke(java.lang.Object, int) bci:44 (Interpreted frame) 0x0000ffff87b3ba90 * java.lang.invoke.LambdaForm$MH+0x000000400104c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame) 0x0000ffff87b3ba90 * Test.run() bci:21 line:28 (Interpreted frame) 0x0000ffff87b3a080 0x0000ffff87b3ba90 return entry points 0x0000ffff87b3ba90 return entry points 0x0000ffff87b3ba90 return entry points 0x0000ffff87b3c030 return entry points 0x0000ffff87b3b820 return entry points 0x0000ffff87b3b820 return entry points 0x0000ffff87b3b910 return entry points 0x0000ffff87b3ba90 return entry points 0x0000ffff87b3ba90 return entry points 0x0000ffff87b3ba90 return entry points 0x0000ffff87b37154 0x0000ffff9f620198 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x248 0x0000ffff9f621824 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x174 0x0000ffff9f6fa7f8 thread_entry(JavaThread*, JavaThread*) + 0x8c 0x0000ffff9f639d88 JavaThread::thread_main_inner() [clone .part.0] + 0xa4 0x0000ffff9fbbc308 Thread::call_run() + 0xa8 0x0000ffff9fa006a8 thread_native_entry(Thread*) + 0xd8 0x0000ffffa031e8d4 start_thread + 0x404 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392845921 From ysuenaga at openjdk.org Sat Oct 11 03:24:46 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 03:24:46 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 [v2] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix trivial bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/32b75fc7..d2a80f56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From cjplummer at openjdk.org Sat Oct 11 05:12:06 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 11 Oct 2025 05:12:06 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64 In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. > > "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) > - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) > - Test.run() @bci=21, line=28 (Interpreted frame) > - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) > - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) > - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) > - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) > - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) > - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) > - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) > - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.F... > @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least). I did not, and unfortunately --mixed is not support on OSX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392919979 From syan at openjdk.org Sat Oct 11 12:55:49 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 11 Oct 2025 12:55:49 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v4] In-Reply-To: References: Message-ID: > Hi all, > > The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. > > If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. > > This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. > > The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. > > Change has been verified locally, test-fix only, no risk. SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into jbs8362087 - Merge branch 'openjdk:master' into jbs8362087 - Add synchronized lock for addClassOptions - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26605/files - new: https://git.openjdk.org/jdk/pull/26605/files/2e9df8dc..d04cc981 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=02-03 Stats: 23474 lines in 811 files changed: 14482 ins; 4671 del; 4321 mod Patch: https://git.openjdk.org/jdk/pull/26605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26605/head:pull/26605 PR: https://git.openjdk.org/jdk/pull/26605 From syan at openjdk.org Sat Oct 11 12:55:54 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 11 Oct 2025 12:55:54 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v3] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 03:15:07 GMT, SendaoYan wrote: >> Hi all, >> >> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. >> >> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. >> >> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. >> >> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan has updated the pull request 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 'openjdk:master' into jbs8362087 > - Add synchronized lock for addClassOptions > - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails Looking reviewers for this test bug fix PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26605#issuecomment-3393294128 From ysuenaga at openjdk.org Sat Oct 11 13:57:41 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 13:57:41 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux [v3] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix for AArch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/d2a80f56..2f3eee62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=01-02 Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From ysuenaga at openjdk.org Sat Oct 11 13:57:41 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 13:57:41 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux [v2] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Sat, 11 Oct 2025 03:24:46 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix trivial bug I fixed for AArch64, and it works fine (in below) on Raspberry Pi 4. ----------------- 1687 ----------------- "ForkJoinPool-1-worker-2" #28 daemon prio=5 tid=0x0000ffff9c697a10 nid=1687 runnable [0x0000ffff70def000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x0000ffffa3b382e8 __syscall_cancel_arch + 0x28 0x0000ffffa3b68b7c __clock_nanosleep + 0x3c 0x0000ffffa3b73740 __GI___nanosleep + 0x20 0x0000ffffa3b83f50 __sleep + 0x50 0x0000ffff8b15b278 0x0000ffff8b13bd54 * java.lang.invoke.LambdaForm$MH+0x0000000010087000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) 0x0000ffff8b13bd54 * java.lang.invoke.LambdaForm$MH+0x0000000010090000.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame) 0x0000ffff8b13bd54 * jdk.internal.foreign.abi.DowncallStub+0x0000000010088000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x0000ffff8b13bd54 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame) 0x0000ffff8b13bd54 * java.lang.invoke.LambdaForm$MH+0x000000001008e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame) 0x0000ffff8b13bf24 * java.lang.invoke.LambdaForm$MH+0x000000001008cc00.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame) 0x0000ffff8b13bf24 * Test.run() bci:21 line:28 (Interpreted frame) 0x0000ffff8b13a3b8 0x0000ffff8b13bf24 * jdk.internal.vm.Continuation.run() bci:122 line:248 (Interpreted frame) 0x0000ffff8b13bf24 * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Interpreted frame) 0x0000ffff8b13bf24 * java.lang.VirtualThread$$Lambda+0x00000000100fba70.run() bci:4 (Interpreted frame) 0x0000ffff8b13c5b4 * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:4 line:1753 (Interpreted frame) 0x0000ffff8b13bc50 * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:1 line:1745 (Interpreted frame) 0x0000ffff8b13bc50 * java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() bci:51 line:1662 (Interpreted frame) 0x0000ffff8b13bd54 * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Interpreted frame) 0x0000ffff8b13bf24 * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Interpreted frame) 0x0000ffff8b13bf24 * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame) 0x0000ffff8b13bf24 * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Interpreted frame) 0x0000ffff8b13749c 0x0000ffffa24d15c4 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x474 0x0000ffffa24d1c48 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x278 0x0000ffffa24d21e4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x90 0x0000ffffa2668a14 thread_entry(JavaThread*, JavaThread*) + 0xc4 0x0000ffffa2510d18 JavaThread::thread_main_inner() + 0x104 0x0000ffffa30399fc Thread::call_run() + 0xac 0x0000ffffa2b6c69c thread_native_entry(Thread*) + 0x12c 0x0000ffffa3b2e8d4 start_thread + 0x404 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3393348999 From ysuenaga at openjdk.org Sat Oct 11 14:58:10 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 14:58:10 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux [v4] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: <1zkXIKlR0K0ZFR32Z62RDHOUezVSgcSAHUt3EUjfY2w=.2f7db4ef-351f-44ae-a349-aaccdb56fa37@github.com> > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Add testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/2f3eee62..915fca8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=02-03 Stats: 159 lines in 2 files changed: 159 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From ysuenaga at openjdk.org Sat Oct 11 14:58:11 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 11 Oct 2025 14:58:11 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com> On Fri, 10 Oct 2025 20:38:51 GMT, Patricio Chilano Mateo wrote: >> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. >> >> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) >> - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) >> - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) >> - Test.run() @bci=21, line=28 (Interpreted frame) >> - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) >> - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) >> - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) >> - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) >> - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) >> - java.util.concurrent.F... > >> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. >> > These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch. @pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3393398658 From alanb at openjdk.org Sun Oct 12 07:59:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 12 Oct 2025 07:59:10 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 22:30:21 GMT, Patricio Chilano Mateo wrote: >> test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 645: >> >>> 643: /** >>> 644: * Test no deadlock happens when Object.wait is called from a mix of pinned and non-pinned >>> 645: * paths and notification is done using notifyAll. >> >> At some point then maybe we should combine this with RetryMonitorEnterWhenPinned. I'm not suggesting we do this now but some of the expanded description might be useful to include here as a passing reader might not immediately know what this test is doing. > > I wasn?t sure where to put the extra test and missed `RetryMonitorEnterWhenPinned.java`. I agree it makes more sense to have it there. Moved now, let me know what you think. Thanks for moving to RetryMonitorEnterWhenPinned as it is similar to the test we had for enter. The update, and conversion to JUnit look good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2423388839 From alanb at openjdk.org Sun Oct 12 07:59:08 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 12 Oct 2025 07:59:08 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> References: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> Message-ID: On Tue, 7 Oct 2025 18:36:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add string in asserts Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27597#pullrequestreview-3327961626 From jsjolen at openjdk.org Sun Oct 12 12:12:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sun, 12 Oct 2025 12:12:05 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v6] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 10:16:02 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > gtest fix We can have the unpoisoning as a RAII type for automatic scoping. With a RAII type for unpoisoning, maybe the code becomes so similar, that we can have one API for everything without ifdefing? The RAII type would unpoison more than it necessarily needs to to access the data of the method, but I think that's fine? I don't get why the poisoning and unpoisoning of the header is done in the MallocTracker, that should probably be done in the constructor and some sort of destructor. For example, the `resolve_checked` in `MallocTracker::record_free_block` could be a different method, like `free_header` which returns the `FreeInfo` and marks the block as dead. The `FreeInfo` has the size, so this isn't a problem either. Some sketching: ```c++ private: // Better name?? struct AsanUnpoison { bool _poison_initial_state; MallocHeader& mh; // TODO: Have this implementation be if-defd depending on ASAN inclusion static set_posioned(MallocHeader& mh); AsanUnpoison(MallocHeader& mh) : // Do the unpoisoning ~AsanUnpoison() // Do the poisoning }; uint16_t get_footer() const { AsanUnpoison aup(*this); return build_footer(footer_address()[0], footer_address()[1]); } void set_footer(uint16_t v) { AsanUnpoison aup(*this); footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v; } public: inline size_t() const { AsanUnpoison aup(*this); return _size; } What do you think? I think it might become neater like this. ------------- PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3328327710 From dholmes at openjdk.org Mon Oct 13 01:55:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Oct 2025 01:55:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: <3j1U_yd7lCH-uQmpkULeuC3eW00LdwNwZlTLoI9anAU=.d7fdc00b-534c-49c4-b2c8-91e6e1adff0b@github.com> On Wed, 8 Oct 2025 07:27:50 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Make EnhanceErrorWarningLogging DIAGNOSTIC PerfMemory should be converted to Unified Logging (UL). We don't want any new flags for ad-hoc logging. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3395624819 From fyang at openjdk.org Mon Oct 13 02:12:05 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 13 Oct 2025 02:12:05 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux In-Reply-To: <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com> Message-ID: On Sat, 11 Oct 2025 14:54:05 GMT, Yasumasa Suenaga wrote: >>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. >>> >> These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch. > > @pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64. @YaSuenag : Hi, I tried on linux-riscv64 and I see the assertion failure is triggering on this platform as well. Seems that your changes are applicable to riscv64 with minor tweak. Maybe you can add this? Thanks. diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java index e02e056f028..44c8f4c679c 100644 --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java @@ -262,7 +262,13 @@ public Frame sender(RegisterMap regMap, CodeBlob cb) { } if (cb != null) { - return cb.isUpcallStub() ? senderForUpcallStub(map, (UpcallStub)cb) : senderForCompiledFrame(map, cb); + if (cb.isUpcallStub()) { + return senderForUpcallStub(map, (UpcallStub)cb); + } else if (cb.isContinuationStub()) { + return senderForContinuationStub(map, cb); + } else { + return senderForCompiledFrame(map, cb); + } } // Must be native-compiled frame, i.e. the marshaling code for native @@ -348,6 +354,16 @@ private void updateMapWithSavedLink(RegisterMap map, Address savedFPAddr) { map.setLocation(fp, savedFPAddr); } + private Frame senderForContinuationStub(RISCV64RegisterMap map, CodeBlob cb) { + var contEntry = map.getThread().getContEntry(); + + Address senderSP = contEntry.getEntrySP(); + Address senderPC = contEntry.getEntryPC(); + Address senderFP = contEntry.getEntryFP(); + + return new RISCV64Frame(senderSP, senderFP, senderPC); + } + private Frame senderForCompiledFrame(RISCV64RegisterMap map, CodeBlob cb) { if (DEBUG) { System.out.println("senderForCompiledFrame"); diff --git a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java index 2565fdf9056..9b4fa067dc0 100644 --- a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java +++ b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java @@ -37,7 +37,7 @@ * @test * @bug 8369505 * @requires (os.family == "linux") & (vm.hasSA) - * @requires (os.arch == "amd64" | os.arch == "aarch64") + * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64") * @library /test/lib * @run driver TestJhsdbJstackMixedWithVirtualThread */ ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3395643581 From ysuenaga at openjdk.org Mon Oct 13 03:08:57 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 13 Oct 2025 03:08:57 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux [v5] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Apply changes to RISC-V code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/915fca8d..57294d7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=03-04 Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From ysuenaga at openjdk.org Mon Oct 13 03:08:58 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 13 Oct 2025 03:08:58 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com> Message-ID: On Mon, 13 Oct 2025 02:09:50 GMT, Fei Yang wrote: >> @pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64. > > @YaSuenag : > Hi, I tried on linux-riscv64 and I see the assertion failure is triggering on this platform as well. > Seems that your changes are applicable to riscv64 with minor tweak. Maybe you can add this? Thanks. > > > diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java > index e02e056f028..44c8f4c679c 100644 > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java > @@ -262,7 +262,13 @@ public Frame sender(RegisterMap regMap, CodeBlob cb) { > } > > if (cb != null) { > - return cb.isUpcallStub() ? senderForUpcallStub(map, (UpcallStub)cb) : senderForCompiledFrame(map, cb); > + if (cb.isUpcallStub()) { > + return senderForUpcallStub(map, (UpcallStub)cb); > + } else if (cb.isContinuationStub()) { > + return senderForContinuationStub(map, cb); > + } else { > + return senderForCompiledFrame(map, cb); > + } > } > > // Must be native-compiled frame, i.e. the marshaling code for native > @@ -348,6 +354,16 @@ private void updateMapWithSavedLink(RegisterMap map, Address savedFPAddr) { > map.setLocation(fp, savedFPAddr); > } > > + private Frame senderForContinuationStub(RISCV64RegisterMap map, CodeBlob cb) { > + var contEntry = map.getThread().getContEntry(); > + > + Address senderSP = contEntry.getEntrySP(); > + Address senderPC = contEntry.getEntryPC(); > + Address senderFP = contEntry.getEntryFP(); > + > + return new RISCV64Frame(senderSP, senderFP, senderPC); > + } > + > private Frame senderForCompiledFrame(RISCV64RegisterMap map, CodeBlob cb) { > if (DEBUG) { > System.out.println("senderForCompiledFrame"); > diff --git a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java > index 2565fdf9056..9b4fa067dc0 100644 > --- a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java > +++ b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java > @@ -37,7 +37,7 @@ > * @test > * @bug 8369505 > * @requires (os.family == "linux") & (vm.hasSA) > - * @requires (os.arch == "amd64" | os.arch == "aarch64") > + * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64") > * @library /test/lib > * @run driver TestJhsdbJstac... @RealFYang Thanks a lot! I applied your change to this PR! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3395709070 From cjplummer at openjdk.org Mon Oct 13 05:08:08 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 13 Oct 2025 05:08:08 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux [v5] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 03:08:57 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Apply changes to RISC-V code test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39: > 37: * @test > 38: * @bug 8369505 > 39: * @requires (os.family == "linux") & (vm.hasSA) I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "" frame. The test would need to be modified to instead check for the exception. Probably we should run this on Windows also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2425225335 From jsjolen at openjdk.org Mon Oct 13 06:21:35 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 13 Oct 2025 06:21:35 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive Message-ID: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. ------------- Commit messages: - Recur lock Changes: https://git.openjdk.org/jdk/pull/27759/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27759&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369622 Stats: 27 lines in 2 files changed: 22 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27759/head:pull/27759 PR: https://git.openjdk.org/jdk/pull/27759 From dholmes at openjdk.org Mon Oct 13 06:43:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Oct 2025 06:43:05 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len wrote: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. src/hotspot/share/memory/arena.cpp line 43: > 41: // code and other areas. For many calls, the current thread has not > 42: // been created so we cannot use Mutex. > 43: class RecursivePlatformMutex : public PlatformMutex { It is a shame that we needed to (re)invent yet-another lock class. src/hotspot/share/memory/arena.cpp line 49: > 47: > 48: ChunkPoolLocker::ChunkPoolLocker() { > 49: assert(GlobalChunkPoolMutex != nullptr, "must be initialized"); Do we have an equivalent assertion to replace this with? src/hotspot/share/memory/arena.cpp line 55: > 53: PlatformMutex::lock(); > 54: _owner = t; > 55: } As per the comment: // For many calls, the current thread has not // been created so we cannot use Mutex. this ownership test won't allow for recursive use in those circumstances. So we have slightly odd semantics here that the mutex is recursive for attached threads but not for un-attached. For this specialised usecase maybe we can tolerate that. src/hotspot/share/memory/arena.cpp line 250: > 248: static const int cleaning_interval = 5000; // cleaning interval in ms > 249: > 250: public: The style guide doesn't mention this but I thought the unofficial preference was for one character indent so that we don't have lines at the same level as the outermost class definition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425331178 PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425309901 PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425336141 PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425338008 From coleenp at openjdk.org Mon Oct 13 06:43:07 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Oct 2025 06:43:07 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len wrote: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. src/hotspot/share/memory/arena.cpp line 43: > 41: // code and other areas. For many calls, the current thread has not > 42: // been created so we cannot use Mutex. > 43: class RecursivePlatformMutex : public PlatformMutex { There's already recursive platform Mutex in MutexLocker.hpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425335088 From jsjolen at openjdk.org Mon Oct 13 06:47:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 13 Oct 2025 06:47:03 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Mon, 13 Oct 2025 06:37:46 GMT, Coleen Phillimore wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > src/hotspot/share/memory/arena.cpp line 43: > >> 41: // code and other areas. For many calls, the current thread has not >> 42: // been created so we cannot use Mutex. >> 43: class RecursivePlatformMutex : public PlatformMutex { > > There's already recursive platform Mutex in MutexLocker.hpp D'oh, I didn't know that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425343626 From jsjolen at openjdk.org Mon Oct 13 06:47:04 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 13 Oct 2025 06:47:04 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Mon, 13 Oct 2025 06:19:42 GMT, David Holmes wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > src/hotspot/share/memory/arena.cpp line 49: > >> 47: >> 48: ChunkPoolLocker::ChunkPoolLocker() { >> 49: assert(GlobalChunkPoolMutex != nullptr, "must be initialized"); > > Do we have an equivalent assertion to replace this with? Yes, it's inside of the getter in `DeferredStatic` (so it's "fixed" by the class abstraction) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2425344502 From dholmes at openjdk.org Mon Oct 13 06:58:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Oct 2025 06:58:40 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code Message-ID: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. Testing: - tiers 1-3 sanity Thanks. ------------- Commit messages: - 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code Changes: https://git.openjdk.org/jdk/pull/27762/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27762&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369631 Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27762/head:pull/27762 PR: https://git.openjdk.org/jdk/pull/27762 From mbaesken at openjdk.org Mon Oct 13 07:52:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Oct 2025 07:52:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: <3j1U_yd7lCH-uQmpkULeuC3eW00LdwNwZlTLoI9anAU=.d7fdc00b-534c-49c4-b2c8-91e6e1adff0b@github.com> References: <3j1U_yd7lCH-uQmpkULeuC3eW00LdwNwZlTLoI9anAU=.d7fdc00b-534c-49c4-b2c8-91e6e1adff0b@github.com> Message-ID: On Mon, 13 Oct 2025 01:52:24 GMT, David Holmes wrote: > PerfMemory should be converted to Unified Logging (UL). We don't want any new flags for ad-hoc logging. Guess this makes sense, do you have some special UL category in mind? Maybe 'os' ? Or a new one ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3396275797 From lucy at openjdk.org Mon Oct 13 08:22:04 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 13 Oct 2025 08:22:04 GMT Subject: RFR: 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 14:36:24 GMT, Matthias Baesken wrote: > When running with stripped pdb files, the gtest dll_address_to_function_and_library_name > can find output like "0x... in ..." instead of usual strings. > So this test should better check for this. > See also > https://github.com/openjdk/jdk/pull/24012/files#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884 > > where this was discussed as part of a larger change. LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27745#pullrequestreview-3330428120 From aboldtch at openjdk.org Mon Oct 13 08:32:03 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 13 Oct 2025 08:32:03 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v3] In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: > [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` > which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. > > Example stack trace: > > V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) > V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c > V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 > V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 > V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 > V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 > V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 > V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 > V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 > V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 > V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 > V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 > > > I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Check !cont.entry()->is_virtual_thread() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27716/files - new: https://git.openjdk.org/jdk/pull/27716/files/4ec7ce98..d5a2cc0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27716/head:pull/27716 PR: https://git.openjdk.org/jdk/pull/27716 From aboldtch at openjdk.org Mon Oct 13 08:34:05 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 13 Oct 2025 08:34:05 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v2] In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Fri, 10 Oct 2025 06:29:40 GMT, Axel Boldt-Christmas wrote: >> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` >> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. >> >> Example stack trace: >> >> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) >> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c >> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 >> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 >> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 >> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 >> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 >> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 >> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 >> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 >> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 >> V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 >> >> >> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - sspitsyn patch > - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state" > > This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d. Pushed the latest patch. The intent of this bug fix was to solve the safepoint (check) issue. Is there anything else we should fix as part of this bug fix? Especially given that there is interest in back-porting JDK-8368159. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3396411952 From ysuenaga at openjdk.org Mon Oct 13 08:34:57 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 13 Oct 2025 08:34:57 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub [v6] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/57294d7c..25d883f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=04-05 Stats: 18 lines in 2 files changed: 9 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From ysuenaga at openjdk.org Mon Oct 13 08:35:01 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 13 Oct 2025 08:35:01 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub [v5] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 05:05:28 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply changes to RISC-V code > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39: > >> 37: * @test >> 38: * @bug 8369505 >> 39: * @requires (os.family == "linux") & (vm.hasSA) > > I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "" frame. The test would need to be modified to instead check for the exception. > > Probably we should run this on Windows also. I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr. I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2425558934 From sspitsyn at openjdk.org Mon Oct 13 09:58:05 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 13 Oct 2025 09:58:05 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v3] In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas wrote: >> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` >> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. >> >> Example stack trace: >> >> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) >> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c >> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 >> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 >> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 >> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 >> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 >> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 >> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 >> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 >> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 >> V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 >> >> >> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Check !cont.entry()->is_virtual_thread() Looks good. Thank you for taking care about this! ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3330756505 From mbaesken at openjdk.org Mon Oct 13 10:15:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Oct 2025 10:15:52 GMT Subject: RFR: 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files In-Reply-To: References: Message-ID: <84e4Vans7IIm8b3NpXCnNkptgTav8Q-GjZ4LEjPnOEE=.196f4970-29a1-4070-9986-b7a1ade4e281@github.com> On Fri, 10 Oct 2025 14:36:24 GMT, Matthias Baesken wrote: > When running with stripped pdb files, the gtest dll_address_to_function_and_library_name > can find output like "0x... in ..." instead of usual strings. > So this test should better check for this. > See also > https://github.com/openjdk/jdk/pull/24012/files#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884 > > where this was discussed as part of a larger change. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27745#issuecomment-3396779441 From mbaesken at openjdk.org Mon Oct 13 10:15:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Oct 2025 10:15:53 GMT Subject: Integrated: 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files In-Reply-To: References: Message-ID: <_ROd_Cp8NSN-5RbvM0ejy1e_ETi7AB2PHgMt6m3fbqw=.37c72144-705b-40ce-a435-be5cc3790f29@github.com> On Fri, 10 Oct 2025 14:36:24 GMT, Matthias Baesken wrote: > When running with stripped pdb files, the gtest dll_address_to_function_and_library_name > can find output like "0x... in ..." instead of usual strings. > So this test should better check for this. > See also > https://github.com/openjdk/jdk/pull/24012/files#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884 > > where this was discussed as part of a larger change. This pull request has now been integrated. Changeset: 98e1d2fa Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/98e1d2fab123befa78342ba53b76a560dddd6385 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files Reviewed-by: clanger, lucy ------------- PR: https://git.openjdk.org/jdk/pull/27745 From azafari at openjdk.org Mon Oct 13 10:34:19 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 13 Oct 2025 10:34:19 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted Message-ID: On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. ------------- Commit messages: - 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted Changes: https://git.openjdk.org/jdk/pull/27764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369527 Stats: 29 lines in 5 files changed: 25 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27764/head:pull/27764 PR: https://git.openjdk.org/jdk/pull/27764 From clanger at openjdk.org Mon Oct 13 13:01:22 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 13 Oct 2025 13:01:22 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug Message-ID: Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine, let's exclude it there for the time being. ------------- Commit messages: - JDK-8369683 Changes: https://git.openjdk.org/jdk/pull/27770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27770&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369683 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27770/head:pull/27770 PR: https://git.openjdk.org/jdk/pull/27770 From pchilanomate at openjdk.org Mon Oct 13 13:50:01 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 13 Oct 2025 13:50:01 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com> Message-ID: On Fri, 10 Oct 2025 22:29:56 GMT, Serguei Spitsyn wrote: > > Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : ) > > I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well? > > I've filed new JVMTI bug: [8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack > Yes, only `invalidate_jvmti_stack` is missing since `preempt_epilog` is only called in the virtual thread case. Thanks for filing the bug Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3397611850 From pchilanomate at openjdk.org Mon Oct 13 13:53:10 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 13 Oct 2025 13:53:10 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v3] In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas wrote: >> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` >> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. >> >> Example stack trace: >> >> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) >> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c >> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 >> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 >> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 >> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 >> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 >> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 >> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 >> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 >> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 >> V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 >> >> >> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Check !cont.entry()->is_virtual_thread() Looks good to me, thanks. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3331727767 From pchilanomate at openjdk.org Mon Oct 13 14:10:15 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 13 Oct 2025 14:10:15 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: References: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> Message-ID: On Wed, 8 Oct 2025 05:08:52 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add string in asserts > > Okay - thanks for clarifying. Thanks for the reviews and comments @dholmes-ora, @AlanBateman and @coleenp! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27597#issuecomment-3397686924 From pchilanomate at openjdk.org Mon Oct 13 14:10:16 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 13 Oct 2025 14:10:16 GMT Subject: Integrated: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:13:58 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 9feb8f21 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/9feb8f21b5d000f8901938f1dde89638c79ca805 Stats: 206 lines in 4 files changed: 180 ins; 3 del; 23 mod 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27597 From zgu at openjdk.org Mon Oct 13 14:21:55 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 13 Oct 2025 14:21:55 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Mon, 13 Oct 2025 06:38:31 GMT, David Holmes wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > src/hotspot/share/memory/arena.cpp line 55: > >> 53: PlatformMutex::lock(); >> 54: _owner = t; >> 55: } > > As per the comment: > > // For many calls, the current thread has not > // been created so we cannot use Mutex. > > this ownership test won't allow for recursive use in those circumstances. So we have slightly odd semantics here that the mutex is recursive for attached threads but not for un-attached. For this specialised usecase maybe we can tolerate that. What if the lock is contended by two threads without `current thread`s? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2426493709 From azafari at openjdk.org Mon Oct 13 17:22:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 13 Oct 2025 17:22:15 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v2] In-Reply-To: References: Message-ID: > On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: return nullptr when index is invalid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27764/files - new: https://git.openjdk.org/jdk/pull/27764/files/5152a166..67481139 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27764/head:pull/27764 PR: https://git.openjdk.org/jdk/pull/27764 From zgu at openjdk.org Mon Oct 13 18:17:40 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 13 Oct 2025 18:17:40 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: <-UnbsYzVUxdVJGgkrChNQypJtYUCXQx782lEpT8uROU=.373ff05b-61eb-4398-ad59-618f0e37dda4@github.com> On Mon, 13 Oct 2025 06:38:31 GMT, David Holmes wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > src/hotspot/share/memory/arena.cpp line 55: > >> 53: PlatformMutex::lock(); >> 54: _owner = t; >> 55: } > > As per the comment: > > // For many calls, the current thread has not > // been created so we cannot use Mutex. > > this ownership test won't allow for recursive use in those circumstances. So we have slightly odd semantics here that the mutex is recursive for attached threads but not for un-attached. For this specialised usecase maybe we can tolerate that. I don't see how it can work without recursion count ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2427017843 From cjplummer at openjdk.org Mon Oct 13 20:05:12 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 13 Oct 2025 20:05:12 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub [v6] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 08:34:57 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update testcase Changes requested by cjplummer (Reviewer). test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 40: > 38: * @bug 8369505 > 39: * @requires vm.hasSA > 40: * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64") You need to include `os.arch == "x86_64"` in order to run on macosx-x64. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 42: > 40: * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64") > 41: * @library /test/lib > 42: * @run driver TestJhsdbJstackMixedWithVirtualThread This test needs to be renamed since it no longer passes `--mixed`. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 62: > 60: System.err.println(out.getStderr()); > 61: > 62: out.stderrShouldBeEmptyIgnoreDeprecatedWarnings(); This check doesn't seem to be working. I disabled your fix and see the `must have non-zero frame size` exception in the log, but the test still passed. I think the exception is going to System.out. ------------- PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3332719455 PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427105111 PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427210111 PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427109788 From cjplummer at openjdk.org Mon Oct 13 20:05:14 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 13 Oct 2025 20:05:14 GMT Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub [v5] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 08:31:05 GMT, Yasumasa Suenaga wrote: >> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39: >> >>> 37: * @test >>> 38: * @bug 8369505 >>> 39: * @requires (os.family == "linux") & (vm.hasSA) >> >> I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "" frame. The test would need to be modified to instead check for the exception. >> >> Probably we should run this on Windows also. > > I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr. > > I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem. On Windows I am seeing the exception (with your fix disabled): "ForkJoinPool-1-worker-1" #30 daemon prio=5 tid=0x000001567d6bcdc0 nid=2588 runnable [0x00000002d35fe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - java.lang.invoke.LambdaForm$MH+0x0000000026047800.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000000002604e400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) - jdk.internal.foreign.abi.DowncallStub+0x0000000026048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$DMH+0x0000000026048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000000002604d800.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x000000002604d400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) - LingeredAppWithVirtualThread.run() @bci=15, line=65 (Interpreted frame) Error occurred during stack walking: sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size With your fix enabled, I see the full expected stack, so it seems to be working. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427225103 From sspitsyn at openjdk.org Mon Oct 13 22:04:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 13 Oct 2025 22:04:01 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v2] In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Mon, 13 Oct 2025 08:31:33 GMT, Axel Boldt-Christmas wrote: > The intent of this bug fix was to solve the safepoint (check) issue. Agreed. But thank you for fixing the additional issue pointed out by Patricio! > Is there anything else we should fix as part of this bug fix? The fix is good as is, thanks! > Especially given that there is interest in back-porting JDK-8368159. I'm curios who do you know is interested in back-porting JDK-8368159. I considered to back-port it but now it needs to be back-ported together with this one: JDK-8369482. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3399182611 From fandreuzzi at openjdk.org Mon Oct 13 22:33:15 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 13 Oct 2025 22:33:15 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used Message-ID: `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`. Passes tier1 and tier2 (fastdebug). ------------- Commit messages: - use Changes: https://git.openjdk.org/jdk/pull/27777/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369734 Stats: 15 lines in 1 file changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777 PR: https://git.openjdk.org/jdk/pull/27777 From dholmes at openjdk.org Tue Oct 14 00:55:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 00:55:03 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 12:54:30 GMT, Christoph Langer wrote: > Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine, let's exclude it there for the time being. Seems reasonable but the JBS issue does not indicate how/why the test fails on Musl debug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3399564968 From ysuenaga at openjdk.org Tue Oct 14 01:04:47 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 01:04:47 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v7] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/25d883f7..04d93099 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From ysuenaga at openjdk.org Tue Oct 14 01:04:47 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 01:04:47 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Sat, 11 Oct 2025 05:09:31 GMT, Chris Plummer wrote: >> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see ``. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `` or any of the frames that come after it. Maybe these are just expected platform differences. >> >> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) >> - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) >> - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) >> - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) >> - Test.run() @bci=21, line=28 (Interpreted frame) >> - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame) >> - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame) >> - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame) >> - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame) >> - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame) >> - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame) >> - java.util.concurrent.F... > >> @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least). > > I did not, and unfortunately --mixed is not support on OSX. @plummercj Thanks for your comment! I revised testcase in the latest commit. Could you review again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3399578469 From ysuenaga at openjdk.org Tue Oct 14 01:04:47 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 01:04:47 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v5] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 19:57:54 GMT, Chris Plummer wrote: >> I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr. >> >> I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem. > > On Windows I am seeing the exception (with your fix disabled): > > > "ForkJoinPool-1-worker-1" #30 daemon prio=5 tid=0x000001567d6bcdc0 nid=2588 runnable [0x00000002d35fe000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > - java.lang.invoke.LambdaForm$MH+0x0000000026047800.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000000002604e400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame) > - jdk.internal.foreign.abi.DowncallStub+0x0000000026048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$DMH+0x0000000026048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000000002604d800.invoke(java.lang.Object, int) @bci=44 (Interpreted frame) > - java.lang.invoke.LambdaForm$MH+0x000000002604d400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame) > - LingeredAppWithVirtualThread.run() @bci=15, line=65 (Interpreted frame) > > Error occurred during stack walking: > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > > With your fix enabled, I see the full expected stack, so it seems to be working. I tested only mixed mode, sorry. I could reproduce the problem on Windows, and I confirmed the problem has gone with this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427647746 From ysuenaga at openjdk.org Tue Oct 14 01:04:47 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 01:04:47 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v6] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Mon, 13 Oct 2025 19:07:25 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Update testcase > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java line 62: > >> (failed to retrieve contents of file, check the PR for context) > This check doesn't seem to be working. I disabled your fix and see the `must have non-zero frame size` exception in the log, but the test still passed. I think the exception is going to System.out. I added test whether the message appears in output, and it works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427649014 From iklam at openjdk.org Tue Oct 14 01:20:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 01:20:03 GMT Subject: RFR: 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols [v2] In-Reply-To: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com> References: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com> Message-ID: <7wxAklWF4B8uBupRZkxnJQhBKkPNgNxEHy8kt50fcn8=.a189a438-a3c8-467e-8945-33b8cfdbe35b@github.com> On Fri, 26 Sep 2025 16:43:28 GMT, Ioi Lam wrote: >> The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan. >> >> The fix is to copy the exact number of bytes for Symbols. >> >> Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - @jdksjolen comments -- simplified patch > - Merge branch 'master' into 8358597-asan-heap-buffer-flow-archive-builder-make-shallow-copy > - More clean up > - 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols @MBaesken does the fix work for you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27508#issuecomment-3399607868 From ysuenaga at openjdk.org Tue Oct 14 02:03:48 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 02:03:48 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v8] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Switch argument of s(S)leep between Windows API and POSIX function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/04d93099..e8090faf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=06-07 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From iklam at openjdk.org Tue Oct 14 03:11:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 03:11:40 GMT Subject: RFR: 8367449: Test runtime/cds/CDSMapTest.java timed out but passed Message-ID: The test CDSMapTest.java usually finished on Windows for about 1 minuet. On other platforms it takes much less time. Since [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) (Change the default TIMEOUT_FACTOR from 4 to 1), we saw only one timeout where the elapsed time is over the 120 sec default timeout value. For sanity, I changed the timeout to 240 sec, to avoid future intermittent timeouts. I also changed the related test AOTMapTest.java. ------------- Commit messages: - 8367449: Test runtime/cds/CDSMapTest.java timed out but passed Changes: https://git.openjdk.org/jdk/pull/27781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367449 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27781/head:pull/27781 PR: https://git.openjdk.org/jdk/pull/27781 From dholmes at openjdk.org Tue Oct 14 03:44:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 03:44:02 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 07:27:50 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Make EnhanceErrorWarningLogging DIAGNOSTIC We already have some UL in PerfMemory: > 8168122: Update logging in perfMemory to Unified Logging Summary: -XX:+PerfTraceMemOps replaced with -Xlog:perf+memops=debug, -XX:+PerfTraceDataCreation replaced with -Xlog:perf+datacreation=debug but for some reason that effort completely ignored the PrintMiscellaneous/Verbose "warnings". To keep things simple I suggest the following pattern: diff --git a/src/hotspot/os/posix/perfMemory_posix.cpp b/src/hotspot/os/posix/perfMemory_posix.cpp index ed83487265c..968f3cea249 100644 --- a/src/hotspot/os/posix/perfMemory_posix.cpp +++ b/src/hotspot/os/posix/perfMemory_posix.cpp @@ -447,10 +447,11 @@ static char* get_user_name(uid_t uid) { int result = getpwuid_r(uid, &pwent, pwbuf, (size_t)bufsize, &p); if (result != 0 || p == nullptr || p->pw_name == nullptr || *(p->pw_name) == '\0') { - if (PrintMiscellaneous && Verbose) { + if (log_is_enabled(Debug, perf)) { + LogStreamHandle(Debug, perf) log; if (result != 0) { - warning("Could not retrieve passwd entry: %s\n", - os::strerror(result)); + log->print_cr("Could not retrieve passwd entry: %s", + os::strerror(result)); } else if (p == nullptr) { // this check is added to protect against an observed problem @@ -463,13 +464,13 @@ static char* get_user_name(uid_t uid) { // message may result in an erroneous message. // Bug Id 89052 was opened with RedHat. // - warning("Could not retrieve passwd entry: %s\n", - os::strerror(errno)); + log->print_cr("Could not retrieve passwd entry: %s", + os::strerror(errno)); } else { - warning("Could not determine user name: %s\n", - p->pw_name == nullptr ? "pw_name = null" : - "pw_name zero length"); + log->print_cr("Could not determine user name: %s", + p->pw_name == nullptr ? "pw_name = null" : + "pw_name zero length"); } } FREE_C_HEAP_ARRAY(char, pwbuf); Of course you proposed changes as a potential consumer of this information, so how would you like to procure it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3399992595 From dholmes at openjdk.org Tue Oct 14 04:03:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 04:03:02 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v2] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 17:22:15 GMT, Afshin Zafari wrote: >> On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > return nullptr when index is invalid This seems reasonable to me. What does the output look like? Thanks test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 173: > 171: const size_t SIZE = 1024; > 172: char* p = (char*)os::malloc(SIZE, mtTest); > 173: *(p -1) = 0; Suggestion: *(p - 1) = 0; ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27764#pullrequestreview-3333820717 PR Review Comment: https://git.openjdk.org/jdk/pull/27764#discussion_r2427849031 From dholmes at openjdk.org Tue Oct 14 05:14:08 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 05:14:08 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Mon, 13 Oct 2025 06:43:49 GMT, Johan Sj?len wrote: >> src/hotspot/share/memory/arena.cpp line 43: >> >>> 41: // code and other areas. For many calls, the current thread has not >>> 42: // been created so we cannot use Mutex. >>> 43: class RecursivePlatformMutex : public PlatformMutex { >> >> There's already recursive platform Mutex in MutexLocker.hpp > > D'oh, I didn't know that. But you can't use that one because we may not have a current thread and we don't want safepoint interactions for JavaThreads IIUC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2427925126 From dholmes at openjdk.org Tue Oct 14 05:14:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 05:14:09 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Tue, 14 Oct 2025 05:09:17 GMT, David Holmes wrote: >> D'oh, I didn't know that. > > But you can't use that one because we may not have a current thread and we don't want safepoint interactions for JavaThreads IIUC. It is a `RecursiveMutex` not `RecursivePlatformMurtex` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2427926870 From dholmes at openjdk.org Tue Oct 14 05:14:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 05:14:11 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <-UnbsYzVUxdVJGgkrChNQypJtYUCXQx782lEpT8uROU=.373ff05b-61eb-4398-ad59-618f0e37dda4@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <-UnbsYzVUxdVJGgkrChNQypJtYUCXQx782lEpT8uROU=.373ff05b-61eb-4398-ad59-618f0e37dda4@github.com> Message-ID: On Mon, 13 Oct 2025 18:14:56 GMT, Zhengyu Gu wrote: >> src/hotspot/share/memory/arena.cpp line 55: >> >>> 53: PlatformMutex::lock(); >>> 54: _owner = t; >>> 55: } >> >> As per the comment: >> >> // For many calls, the current thread has not >> // been created so we cannot use Mutex. >> >> this ownership test won't allow for recursive use in those circumstances. So we have slightly odd semantics here that the mutex is recursive for attached threads but not for un-attached. For this specialised usecase maybe we can tolerate that. > > I don't see how it can work without recursion count ... Doh! Yep Zhengyu is right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2427927714 From ysuenaga at openjdk.org Tue Oct 14 05:27:46 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Oct 2025 05:27:46 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update TestJhsdbJstackWithVirtualThread.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/e8090faf..b82bb9aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From dholmes at openjdk.org Tue Oct 14 05:40:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 05:40:01 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi wrote: > `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`. > > Passes tier1 and tier2 (fastdebug). Sorry for ping-ponging on the serviceability labeling. I'm not sure this is the right fix. The logic to return a value from `post_class_file_load_hook` was added way back in JDK 9 by [JDK-8171008](https://bugs.openjdk.org/browse/JDK-8171008) as part of the original AOT compiler effort. But at that time no changes were made to any of the callers to use the new return value! That means this aspect of the code is completely untested - and it is also completely undocumented. I'd be more inclined to treat the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3400196178 From aboldtch at openjdk.org Tue Oct 14 05:43:16 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 14 Oct 2025 05:43:16 GMT Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state [v3] In-Reply-To: References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: <1q85w7kQkDpro3hC5sLTIoKoiU2pMb-g8EJGTGyAnFQ=.971e83d7-7f59-42fe-be64-c9120f1ac530@github.com> On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas wrote: >> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` >> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. >> >> Example stack trace: >> >> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) >> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c >> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 >> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 >> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 >> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 >> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 >> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 >> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 >> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 >> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 >> V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 >> >> >> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Check !cont.entry()->is_virtual_thread() Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3400197550 From aboldtch at openjdk.org Tue Oct 14 05:43:18 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 14 Oct 2025 05:43:18 GMT Subject: Integrated: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com> Message-ID: On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas wrote: > [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)` > which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint. > > Example stack trace: > > V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375) > V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c > V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0 > V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120 > V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48 > V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200 > V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0 > V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0 > V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24 > V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8 > V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4 > V [libjvm.dylib+0x59a4d4] int freeze>(JavaThread*, long*)+0x108 > > > I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope. This pull request has now been integrated. Changeset: 5bf1bab5 Author: Serguei Spitsyn Committer: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state Co-authored-by: Patricio Chilano Mateo Reviewed-by: sspitsyn, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/27716 From dholmes at openjdk.org Tue Oct 14 05:53:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 05:53:02 GMT Subject: RFR: 8367449: Test runtime/cds/CDSMapTest.java timed out but passed In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 03:06:13 GMT, Ioi Lam wrote: > The test CDSMapTest.java usually finished on Windows for about 1 minuet. On other platforms it takes much less time. > > Since [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) (Change the default TIMEOUT_FACTOR from 4 to 1), we saw only one timeout where the elapsed time is over the 120 sec default timeout value. > > For sanity, I changed the timeout to 240 sec, to avoid future intermittent timeouts. > > I also changed the related test AOTMapTest.java. Seems harmless and trivial. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27781#pullrequestreview-3333989393 From stefank at openjdk.org Tue Oct 14 07:00:00 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 14 Oct 2025 07:00:00 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Mon, 13 Oct 2025 06:52:32 GMT, David Holmes wrote: > Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. > > Testing: > - tiers 1-3 sanity > > Thanks. Looks good. I don't understand how those semaphore were guaranteed to be correctly initialized before, so I'm happy to see this change that explicitly initialization of them. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27762#pullrequestreview-3334155703 From stefank at openjdk.org Tue Oct 14 07:08:04 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 14 Oct 2025 07:08:04 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len wrote: > In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. FWIW, in ZGC we deal with similar situations by using this construct instead of a recursive lock: static bool try_lock_on_error(ZLock* lock) { if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) { return lock->try_lock(); } lock->lock(); return true; } void ZPageAllocator::print_usage_on(outputStream* st) const { const bool locked = try_lock_on_error(&_lock); if (!locked) { st->print_cr(""); } // Print information even though we may not have successfully taken the lock. // This is thread-safe, but may produce inconsistent results. print_total_usage_on(st); StreamIndentor si(st, 1); print_partition_usage_on(st); if (locked) { _lock.unlock(); } } I don't know the reason for NMT trying to take the look recursively in the error reporter, but maybe something similar to the above would work without adding a new RecursivePlatformMutex? Here's another example that simply skips some hs_err logging if the lock is being held (This time with Mutex, though): void GCLogPrecious::print_on_error(outputStream* st) { st->print_cr("GC Precious Log:"); if (_lines == nullptr) { st->print_cr("\n"); return; } if (!_lock->try_lock_without_rank_check()) { st->print_cr("\n"); return; } if (_lines->size() == 0) { st->print_cr("\n"); } else { st->print_cr("%s", _lines->base()); } _lock->unlock(); } ------------- PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3334177089 From duke at openjdk.org Tue Oct 14 07:27:05 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=) Date: Tue, 14 Oct 2025 07:27:05 GMT Subject: RFR: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 11:27:30 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369559 > > Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: > > > $ cat aot.map | grep MethodTrainingData > 0x00000008019d54c0: @@ MethodTrainingData 96 > 0x00000008019dcec8: @@ MethodTrainingData 96 > [...] > > $ cat aot.map | grep CompileTrainingData > [...] > 0x000000080079c8a0: @@ CompileTrainingData 80 > 0x00000008007a7660: @@ CompileTrainingData 80 > > > Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. > > The output should look like the following: > > > $ cat aot.map | grep CompileTrainingData > 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() > 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() > 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() > [...] > > $ cat aot.map | grep MethodTrainingData > 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) > 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() > 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) > [...] > > > Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. > > Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). @adinn @iklam can you please review this one too? More log messages on the AOT Map file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27740#issuecomment-3400457145 From azafari at openjdk.org Tue Oct 14 07:36:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 07:36:48 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v3] In-Reply-To: References: Message-ID: > On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: style fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27764/files - new: https://git.openjdk.org/jdk/pull/27764/files/67481139..e4957bd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27764/head:pull/27764 PR: https://git.openjdk.org/jdk/pull/27764 From azafari at openjdk.org Tue Oct 14 07:36:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 07:36:48 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v2] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 04:00:04 GMT, David Holmes wrote: > What does the output look like? The output is the stack trace of depth 4 (as it is in all NMT reports), if possible. When malloc-site marker is not corrupted: NMT Block at 0x000000011e01fc00, corruption at: 0x000000011e021c11: allocated from: [0x0000000107928184]NMT_test_overwrite_back_long_unaligned_distance_vm_assert_Test::TestBody()+0x268 [0x0000000108dadf28]testing::Test::Run()+0x1e8 [0x0000000108daf418]testing::TestInfo::Run()+0x248 [0x0000000108db0118]testing::TestSuite::Run()+0x3c8 and if it is also corrupted: NMT Block at 0x0000600001f622e0, corruption at: 0x0000600001f622e0: allocation-site cannot be shown since the marker is also corrupted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27764#issuecomment-3400477610 From adinn at openjdk.org Tue Oct 14 07:52:13 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 14 Oct 2025 07:52:13 GMT Subject: RFR: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 11:27:30 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369559 > > Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: > > > $ cat aot.map | grep MethodTrainingData > 0x00000008019d54c0: @@ MethodTrainingData 96 > 0x00000008019dcec8: @@ MethodTrainingData 96 > [...] > > $ cat aot.map | grep CompileTrainingData > [...] > 0x000000080079c8a0: @@ CompileTrainingData 80 > 0x00000008007a7660: @@ CompileTrainingData 80 > > > Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. > > The output should look like the following: > > > $ cat aot.map | grep CompileTrainingData > 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() > 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() > 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() > [...] > > $ cat aot.map | grep MethodTrainingData > 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) > 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() > 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) > [...] > > > Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. > > Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). Looks ok to me. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27740#pullrequestreview-3334320550 From zgu at openjdk.org Tue Oct 14 08:01:05 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 14 Oct 2025 08:01:05 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len wrote: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. What about using `os::current_thread_id()` for lock owner? it avoids the dependence on the existing of `Thread*` and more semantically close to the original `ThreadCritical`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3400562014 From kbarrett at openjdk.org Tue Oct 14 09:48:39 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 14 Oct 2025 09:48:39 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Mon, 13 Oct 2025 06:52:32 GMT, David Holmes wrote: > Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. > > Testing: > - tiers 1-3 sanity > > Thanks. src/hotspot/os/posix/signals_posix.cpp line 172: > 170: static OSXSemaphore* sr_semaphore; > 171: #else > 172: static PosixSemaphore* sr_semaphore; pre-existing: Why is this conditionalized, rather than just using `Semaphore` (which is already being used for `sig_semaphore`)? src/hotspot/os/posix/signals_posix.cpp line 172: > 170: static OSXSemaphore* sr_semaphore; > 171: #else > 172: static PosixSemaphore* sr_semaphore; I don't think consistency with the other semaphore is a great reason for avoiding the use of `DeferredStatic` here. Indeed, I would prefer that `DeferredStatic` be used for both semaphores. I think the only change from what's already being proposed here to make `sr_semaphore` be `DeferredStatic` is the declaration and the initialization. The changes needed for `sig_semaphore` to be `DeferredStatic` are pretty small. Change the declaration and initialization, and os::signal_notify needs to be adjusted. The last I think actually makes the code clearer and more consistent. void os::signal_notify(int sig) { - if (sig_semaphore != nullptr) { + if (!ReduceSignalUsage) { AtomicAccess::inc(&pending_signals[sig]); sig_semaphore->signal(); - } else { - // Signal thread is not created with ReduceSignalUsage and jdk_misc_signal_init - // initialization isn't called. - assert(ReduceSignalUsage, "signal semaphore should be created"); } } That would change a too-early signal to a crash in a product build, except our signal handlers are installed after the semaphores are initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2428427603 PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2428552303 From azafari at openjdk.org Tue Oct 14 11:01:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 11:01:06 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: - better style - a step back - alternative impl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/601b5b2b..cee97082 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=05-06 Stats: 330 lines in 6 files changed: 193 ins; 70 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From jsjolen at openjdk.org Tue Oct 14 11:48:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 14 Oct 2025 11:48:09 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 11:01:06 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - better style > - a step back > - alternative impl Changes requested by jsjolen (Reviewer). src/hotspot/share/nmt/mallocHeader.hpp line 108: > 106: ASAN_UNPOISON_MEMORY_REGION(addr, sizeof(T)); > 107: } > 108: }; Wrap the bodies of these functions with the `#ifdef ASAN`. As these defs are in the header, they'll be visible to any usages by the compiler, and so can be optimized away when ASAN is not in use. This helps simplify the rest of the code. The name `Poisoner` is unfortunate, as it's technically `Unpoisoning` the memory region. You can also have the `_memory` be `T*` and have the class take `T*` as its argument and do the casting inside of the class body instead. This avoids unnecessary clutter in the user-code. Perhaps rename `_memory` to `_memory_region` to mimic the wording used in the ASAN macros? Use `reinterpret_cast` instead of C-style cast, with the intent of providing the full meaning of the cast. `register` and `unregister` memory, perhaps they should be poison and unpoison? src/hotspot/share/nmt/mallocHeader.hpp line 120: > 118: static void unregister_memory(char* addr) { } > 119: ~AsanPoisoner() { } > 120: }; I think you can delete this definition src/hotspot/share/nmt/mallocHeader.hpp line 130: > 128: using SizeType = void; > 129: NOT_LP64(using AltCanaryType = void;) > 130: #endif Surely this won't work, as we're using some of these types as return types in functions? src/hotspot/share/nmt/mallocTracker.cpp line 191: > 189: assert(((size_t)memblock & (sizeof(size_t) * 2 - 1)) == 0, "Alignment check"); > 190: > 191: Style: Added in space, remove src/hotspot/share/sanitizers/address.hpp line 29: > 27: > 28: #ifdef ADDRESS_SANITIZER > 29: #define __SANITIZE_ADDRESS__ Why not just check for `ADDRESS_SANITIZER` in the test, and skip this definition? ------------- PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3335143623 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2428844050 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2428834787 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2428834342 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2428848537 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2428850122 From jsjolen at openjdk.org Tue Oct 14 11:53:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 14 Oct 2025 11:53:02 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 11:01:06 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - better style > - a step back > - alternative impl Ideas for names: - AsanPoisonSuppressor - AsanUnpoisonGuard - AsanUnpoisonScope ------------- PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3401406002 From azafari at openjdk.org Tue Oct 14 13:16:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 13:16:29 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v8] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: reviews applied ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/cee97082..98ec45e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=06-07 Stats: 46 lines in 3 files changed: 8 ins; 1 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Tue Oct 14 13:16:33 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 13:16:33 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 11:50:43 GMT, Johan Sj?len wrote: > Ideas for names: > > * AsanPoisonSuppressor > * AsanUnpoisonGuard > * AsanUnpoisonScope `AsanPoisoningHelper` is used. It is used both for suppressing and register/unregister memory regions. > src/hotspot/share/nmt/mallocHeader.hpp line 108: > >> 106: ASAN_UNPOISON_MEMORY_REGION(addr, sizeof(T)); >> 107: } >> 108: }; > > Wrap the bodies of these functions with the `#ifdef ASAN`. As these defs are in the header, they'll be visible to any usages by the compiler, and so can be optimized away when ASAN is not in use. This helps simplify the rest of the code. > > The name `Poisoner` is unfortunate, as it's technically `Unpoisoning` the memory region. You can also have the `_memory` be `T*` and have the class take `T*` as its argument and do the casting inside of the class body instead. This avoids unnecessary clutter in the user-code. > > Perhaps rename `_memory` to `_memory_region` to mimic the wording used in the ASAN macros? > > Use `reinterpret_cast` instead of C-style cast, with the intent of providing the full meaning of the cast. > > > `register` and `unregister` memory, perhaps they should be poison and unpoison? Done > src/hotspot/share/nmt/mallocHeader.hpp line 120: > >> 118: static void unregister_memory(char* addr) { } >> 119: ~AsanPoisoner() { } >> 120: }; > > I think you can delete this definition Kept. to be used in gtests. > src/hotspot/share/nmt/mallocHeader.hpp line 130: > >> 128: using SizeType = void; >> 129: NOT_LP64(using AltCanaryType = void;) >> 130: #endif > > Surely this won't work, as we're using some of these types as return types in functions? return values removed. > src/hotspot/share/nmt/mallocTracker.cpp line 191: > >> 189: assert(((size_t)memblock & (sizeof(size_t) * 2 - 1)) == 0, "Alignment check"); >> 190: >> 191: > > Style: Added in space, remove Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3401744335 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2429112495 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2429114941 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2429117080 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2429111374 From azafari at openjdk.org Tue Oct 14 13:22:01 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 13:22:01 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v9] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: register_memory -> poison_memory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/98ec45e9..e316cdbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=07-08 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From mbaesken at openjdk.org Tue Oct 14 13:32:36 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Oct 2025 13:32:36 GMT Subject: RFR: 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols [v2] In-Reply-To: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com> References: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com> Message-ID: On Fri, 26 Sep 2025 16:43:28 GMT, Ioi Lam wrote: >> The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan. >> >> The fix is to copy the exact number of bytes for Symbols. >> >> Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - @jdksjolen comments -- simplified patch > - Merge branch 'master' into 8358597-asan-heap-buffer-flow-archive-builder-make-shallow-copy > - More clean up > - 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27508#pullrequestreview-3335679997 From mbaesken at openjdk.org Tue Oct 14 13:32:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Oct 2025 13:32:38 GMT Subject: RFR: 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols [v2] In-Reply-To: <7wxAklWF4B8uBupRZkxnJQhBKkPNgNxEHy8kt50fcn8=.a189a438-a3c8-467e-8945-33b8cfdbe35b@github.com> References: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com> <7wxAklWF4B8uBupRZkxnJQhBKkPNgNxEHy8kt50fcn8=.a189a438-a3c8-467e-8945-33b8cfdbe35b@github.com> Message-ID: On Tue, 14 Oct 2025 01:17:16 GMT, Ioi Lam wrote: > does the fix work for you? The issue is gone when running the mentioned test `runtime/cds/appcds/CommandLineFlagCombo.java ` with asan - enabled binaries. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27508#issuecomment-3401856658 From kbarrett at openjdk.org Tue Oct 14 13:33:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 14 Oct 2025 13:33:42 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Mon, 13 Oct 2025 06:39:56 GMT, David Holmes wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > src/hotspot/share/memory/arena.cpp line 250: > >> 248: static const int cleaning_interval = 5000; // cleaning interval in ms >> 249: >> 250: public: > > The style guide doesn't mention this but I thought the unofficial preference was for one character indent so that we don't have lines at the same level as the outermost class definition. The style guide doesn't mention it because I don't think we have consistent usage, and I haven't felt like stirring that pot. (Others are, of course, free to do so.) Personally I use no-indent unless the surrounding code uses 1sp-indent. And only change an existing 1sp-indent to no-indent if it seems out of place compared to surrounding code and I happen to be touching something nearby. (switch/case labels are similarly inconsistent in our code.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2429199234 From stefank at openjdk.org Tue Oct 14 13:50:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 14 Oct 2025 13:50:42 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Tue, 14 Oct 2025 13:30:28 GMT, Kim Barrett wrote: >> src/hotspot/share/memory/arena.cpp line 250: >> >>> 248: static const int cleaning_interval = 5000; // cleaning interval in ms >>> 249: >>> 250: public: >> >> The style guide doesn't mention this but I thought the unofficial preference was for one character indent so that we don't have lines at the same level as the outermost class definition. > > The style guide doesn't mention it because I don't think we have consistent > usage, and I haven't felt like stirring that pot. (Others are, of course, free > to do so.) Personally I use no-indent unless the surrounding code uses > 1sp-indent. And only change an existing 1sp-indent to no-indent if it seems > out of place compared to surrounding code and I happen to be touching > something nearby. (switch/case labels are similarly inconsistent in our code.) FWIW, I've been removing one-space indents for years now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2429270384 From azafari at openjdk.org Tue Oct 14 16:00:39 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 16:00:39 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v10] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: NOT_LP64 code fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/e316cdbf..06281646 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=08-09 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Tue Oct 14 16:11:07 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 14 Oct 2025 16:11:07 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 11:45:06 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: >> >> - better style >> - a step back >> - alternative impl > > src/hotspot/share/sanitizers/address.hpp line 29: > >> 27: >> 28: #ifdef ADDRESS_SANITIZER >> 29: #define __SANITIZE_ADDRESS__ > > Why not just check for `ADDRESS_SANITIZER` in the test, and skip this definition? In `.../clang/15.0.0/include/sanitizer/asan_interface.h`, the ASAN_(UN)POISON_MEMORY_REGION macros would be empty as ```C++ // Macros provided for convenience. #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__) /// Marks a memory region as unaddressable. /// /// \note Macro provided for convenience; defined as a no-op if ASan is not /// enabled. /// /// \param addr Start of memory region. /// \param size Size of memory region. #define ASAN_POISON_MEMORY_REGION(addr, size) \ __asan_poison_memory_region((addr), (size)) /// Marks a memory region as addressable. /// /// \note Macro provided for convenience; defined as a no-op if ASan is not /// enabled. /// /// \param addr Start of memory region. /// \param size Size of memory region. #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \ __asan_unpoison_memory_region((addr), (size)) #else #define ASAN_POISON_MEMORY_REGION(addr, size) \ ((void)(addr), (void)(size)) #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \ ((void)(addr), (void)(size)) #endif I couldn't find yet why is that. So a fast/certain solution was to define the `__SANITIZE_ADDRESS__` explicitly. Should be found before integrating this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2429725296 From kbarrett at openjdk.org Tue Oct 14 17:23:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 14 Oct 2025 17:23:18 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: <8A3JE-eDSiWE1FSPdUTcPOjLoBIL2zTbSL8McsZkbn8=.3d7cd702-4417-488f-a968-5f48cd93888a@github.com> On Tue, 14 Oct 2025 08:59:02 GMT, Kim Barrett wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > src/hotspot/os/posix/signals_posix.cpp line 172: > >> 170: static OSXSemaphore* sr_semaphore; >> 171: #else >> 172: static PosixSemaphore* sr_semaphore; > > pre-existing: Why is this conditionalized, rather than just using `Semaphore` (which is already being used > for `sig_semaphore`)? Oops, I see why this is being done. The code in this file calls `timedwait` on the semaphore, but `Semaphore` for some reason doesn't provide that operation. It seems that's always been true, since the introduction of `Semaphore`, because "it wasn't needed". But that forces conditionalization like this. Sigh. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2429920395 From pchilanomate at openjdk.org Tue Oct 14 18:14:34 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 14 Oct 2025 18:14:34 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Sat, 11 Oct 2025 05:09:31 GMT, Chris Plummer wrote: > > @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least). > > I did not, and unfortunately --mixed is not support on OSX. > Ok, that?s why I wasn?t seeing `` either. I removed `?mixed` because it wasn?t working for me, only the top native frame was shown in the stacktrace (on linux-x64). I could still reproduce the assert without `?mixed` so I continued testing that way assuming the output for the `enterSpecial` frame would be the same in both modes. Now, testing on linux-aarch64, `?mixed` mode works and I can see `` for the `enterSpecial` frame. Looking at the code, I see the difference with mixed mode is the way we walk the stack. Even for Java frames the sender is always obtained through this method [1], relying basically on the FP. Then once we get to the frame with pc equal to the return barrier, here [2] we will just branch to the else case and print it as a continuation stub instead of the `enterSpecial` frame. I was also curious how we can walk compiled frames this way, since the FP will not contain in general a valid link unless `-XX:+PreserveFramePointer` is set. So I added `-Xcomp` to `LingeredApp.startApp` and I see that we indeed fail to walk the stack: ----------------- 2943661 ----------------- "ForkJoinPool-1-worker-2" #30 daemon prio=5 tid=0x0000ffff08007f30 nid=2943661 runnable [0x0000ffff695e1000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x0000ffff9bb40b24 __clock_nanosleep + 0x84 0x0000ffff9bb45c0c __GI___nanosleep + 0x1c 0x0000ffff9bb45acc __sleep + 0x4c 0x0000ffff836fb338 0x0000ffff7c802ef8 * java.lang.invoke.LambdaForm$MH+0x0000000601047800.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) * java.lang.invoke.LambdaForm$MH+0x000000060104d400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame) 0x910023e12a0003e2 ???????? ----------------- 2943659 ----------------- When setting` -XX:+PreserveFramePointer` we can walk them again (also tweaked the code to print the correct `enterSpecial` frame): ----------------- 2947348 ----------------- "ForkJoinPool-1-worker-2" #30 daemon prio=5 tid=0x0000ffff1c008040 nid=2947348 runnable [0x0000ffff7c8dd000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x0000ffffaee18b24 __clock_nanosleep + 0x84 0x0000ffffaee1dc0c __GI___nanosleep + 0x1c 0x0000ffffaee1dacc __sleep + 0x4c 0x0000ffff976faa38 0x0000ffff90806f3c * java.lang.invoke.LambdaForm$MH+0x000007e001047800.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) 0x0000ffff90bad354 * java.lang.invoke.LambdaForm$MH+0x000007e00104d400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame) 0x0000ffff97597d60 * jdk.internal.foreign.abi.DowncallStub+0x000007e001048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x0000ffff908b7a70 * java.lang.invoke.LambdaForm$DMH+0x000007e001048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame) 0x0000ffff90b9b710 * java.lang.invoke.LambdaForm$MH+0x000007e00104c800.invoke(java.lang.Object, int) bci:44 (Compiled frame) 0x0000ffff90b9041c * java.lang.invoke.LambdaForm$MH+0x000007e00104c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame) 0x0000ffff97597f30 * LingeredAppWithVirtualThread.run() bci:15 line:65 (Interpreted frame) 0x0000ffff975963b8 * jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) bci:0 (Compiled frame) 0x0000ffff97fa5fbc * jdk.internal.vm.Continuation.run() bci:152 line:251 (Compiled frame) 0x0000ffff90b85888 * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Compiled frame) 0x0000ffff97fa3eb0 * java.lang.VirtualThread$$Lambda+0x000007e001034c88.run() bci:4 (Compiled frame) 0x0000ffff90b8445c * java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec() bci:4 line:1596 (Compiled frame) 0x0000ffff90b83298 * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Compiled frame) 0x0000ffff90b81e2c * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Compiled frame) * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Compiled frame) 0x0000ffff97fa03a8 * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Compiled frame) 0x0000ffff9759349c 0x0000ffffad95020c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x45c 0x0000ffffad950880 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x278 0x0000ffffad950e14 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x8c 0x0000ffffadaee66c thread_entry(JavaThread*, JavaThread*) + 0xc4 0x0000ffffad98de68 JavaThread::thread_main_inner() + 0x108 0x0000ffffae301efc Thread::call_run() + 0xac 0x0000ffffadfe105c thread_native_entry(Thread*) + 0x12c 0x0000ffffaede3b50 start_thread + 0x300 I would have expected that `mixed` mode walked the stack similar to how we do it in the VM with `NativeStackPrinter` using `frame::next_frame()`, i.e we change how we get the sender based on the frame. Anyways, I was just curious about the difference in output with `mixed` mode. [1] https://github.com/openjdk/jdk/blob/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java#L56 [2] https://github.com/openjdk/jdk/blob/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java#L148 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3403057882 From pchilanomate at openjdk.org Tue Oct 14 18:18:47 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 14 Oct 2025 18:18:47 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Tue, 14 Oct 2025 05:27:46 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update TestJhsdbJstackWithVirtualThread.java test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 67: > 65: public void run() { > 66: signal.countDown(); > 67: Thread.yield(); `Thread.yield` should be moved before the `countDown` call, unless you intentionally want to make it time-dependent and catch the target at possibly different stages (before/after unmounting). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2430051397 From iklam at openjdk.org Tue Oct 14 20:06:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 20:06:21 GMT Subject: RFR: 8367449: Test runtime/cds/CDSMapTest.java timed out but passed In-Reply-To: References: Message-ID: <0gLmF0SiRunZ3Fw1BG1-ys-8ahRbyGECTORiwtp7Wfg=.587b89e6-907e-42c0-baa7-f0e2abbb4923@github.com> On Tue, 14 Oct 2025 05:50:06 GMT, David Holmes wrote: >> The test CDSMapTest.java usually finished on Windows for about 1 minuet. On other platforms it takes much less time. >> >> Since [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) (Change the default TIMEOUT_FACTOR from 4 to 1), we saw only one timeout where the elapsed time is over the 120 sec default timeout value. >> >> For sanity, I changed the timeout to 240 sec, to avoid future intermittent timeouts. >> >> I also changed the related test AOTMapTest.java. > > Seems harmless and trivial. > > Thanks Thanks @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27781#issuecomment-3403416661 From iklam at openjdk.org Tue Oct 14 20:06:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 20:06:23 GMT Subject: Integrated: 8367449: Test runtime/cds/CDSMapTest.java timed out but passed In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 03:06:13 GMT, Ioi Lam wrote: > The test CDSMapTest.java usually finished on Windows for about 1 minuet. On other platforms it takes much less time. > > Since [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) (Change the default TIMEOUT_FACTOR from 4 to 1), we saw only one timeout where the elapsed time is over the 120 sec default timeout value. > > For sanity, I changed the timeout to 240 sec, to avoid future intermittent timeouts. > > I also changed the related test AOTMapTest.java. This pull request has now been integrated. Changeset: ad2d0473 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/ad2d04733b64a6793e20fd32a3e9fafab93556c5 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8367449: Test runtime/cds/CDSMapTest.java timed out but passed Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27781 From iklam at openjdk.org Tue Oct 14 20:07:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 20:07:10 GMT Subject: RFR: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output In-Reply-To: References: Message-ID: <-g4JYuvsQxlvTuo_4E-zFp93xvFEVfaffUM2DWxpgKM=.d5de576c-4481-4975-b640-9c61b3808e6e@github.com> On Fri, 10 Oct 2025 11:27:30 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369559 > > Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: > > > $ cat aot.map | grep MethodTrainingData > 0x00000008019d54c0: @@ MethodTrainingData 96 > 0x00000008019dcec8: @@ MethodTrainingData 96 > [...] > > $ cat aot.map | grep CompileTrainingData > [...] > 0x000000080079c8a0: @@ CompileTrainingData 80 > 0x00000008007a7660: @@ CompileTrainingData 80 > > > Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. > > The output should look like the following: > > > $ cat aot.map | grep CompileTrainingData > 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() > 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() > 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() > [...] > > $ cat aot.map | grep MethodTrainingData > 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) > 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() > 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) > [...] > > > Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. > > Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). Looks good. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27740#pullrequestreview-3337262410 From dholmes at openjdk.org Tue Oct 14 20:23:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Oct 2025 20:23:04 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Tue, 14 Oct 2025 09:44:52 GMT, Kim Barrett wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > src/hotspot/os/posix/signals_posix.cpp line 172: > >> 170: static OSXSemaphore* sr_semaphore; >> 171: #else >> 172: static PosixSemaphore* sr_semaphore; > > I don't think consistency with the other semaphore is a great reason for > avoiding the use of `DeferredStatic` here. Indeed, I would prefer that > `DeferredStatic` be used for both semaphores. > > I think the only change from what's already being proposed here to make > `sr_semaphore` be `DeferredStatic` is the declaration and the initialization. > > The changes needed for `sig_semaphore` to be `DeferredStatic` are pretty > small. Change the declaration and initialization, and os::signal_notify needs > to be adjusted. The last I think actually makes the code clearer and more > consistent. > > > void os::signal_notify(int sig) { > - if (sig_semaphore != nullptr) { > + if (!ReduceSignalUsage) { > AtomicAccess::inc(&pending_signals[sig]); > sig_semaphore->signal(); > - } else { > - // Signal thread is not created with ReduceSignalUsage and jdk_misc_signal_init > - // initialization isn't called. > - assert(ReduceSignalUsage, "signal semaphore should be created"); > } > } > > > That would change a too-early signal to a crash in a product build, except our > signal handlers are installed after the semaphores are initialized. Thanks for taking a look @kimbarrett . I expected someone would say "why not switch both to DeferredStatic?" and I don't have an issue doing that (missing init checks notwithstanding), but it wasn't my immediate goto because I don't see `DeferredStatic as really being any superior to declaring a pointer instead (which is how we do lazy initialization in 99.9% of the VM). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430345486 From iklam at openjdk.org Tue Oct 14 23:54:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 23:54:10 GMT Subject: RFR: 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 12:13:47 GMT, Johan Sj?len wrote: >> The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan. >> >> The fix is to copy the exact number of bytes for Symbols. >> >> Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable. > > Hi Ioi, > > This change looks like it solves the bug. I was thinking about this, it seems that we're already doing some special-casing when looking at `MSO::ClassType`. Perhaps it would be good to have all special-cases at the top and have them 'hug' together? Below is a variant of your fix that does that. AFAIU it's "well-known" that AOTCache zeroes out all memory allocated, so we don't need to mention that in the comment. > > ```c++ > address src = src_info->source_addr(); > int bytes_needed = src_info->size_in_bytes(); > char* dest; > char* oldtop; > char* newtop; > > oldtop = dump_region->top(); > > if (src_info->msotype() == MetaspaceObj::ClassType) { > // Allocate space for a pointer directly in front of the future InstanceKlass, so > // we can do a quick lookup from InstanceKlass* -> RunTimeClassInfo* > // without building another hashtable. See RunTimeClassInfo::get_for() > // in systemDictionaryShared.cpp. > Klass* klass = (Klass*)src; > if (klass->is_instance_klass()) { > SystemDictionaryShared::validate_before_archiving(InstanceKlass::cast(klass)); > bytes_needed += sizeof(address); > } > // Allocate space for the future InstanceKlass with proper alignment > const size_t alignment = > #ifdef _LP64 > UseCompressedClassPointers ? > nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift()) : > SharedSpaceObjectAlignment; > #else > SharedSpaceObjectAlignment; > #endif > } else if (src_info->msotype() == MetaspaceObj::SymbolType) { > // Symbols may be allocated by using AllocateHeap, so their sizes > // may be less than size_in_bytes() indicates. > bytes_needed = ((Symbol*)src)->byte_size(); > } else { > // All other cases need no special-handling. > } > dest = dump_region->allocate(bytes_needed); > newtop = dump_region->top(); > > memcpy(dest, src, bytes_needed); Thanks @jdksjolen @MBaesken for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27508#issuecomment-3404002587 From iklam at openjdk.org Tue Oct 14 23:54:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Oct 2025 23:54:11 GMT Subject: Integrated: 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 02:32:12 GMT, Ioi Lam wrote: > The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan. > > The fix is to copy the exact number of bytes for Symbols. > > Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable. This pull request has now been integrated. Changeset: 3d95c83b Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/3d95c83b14cf9a6f683776053e57c07b1847cc17 Stats: 19 lines in 1 file changed: 3 ins; 6 del; 10 mod 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols Reviewed-by: mbaesken, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27508 From ysuenaga at openjdk.org Wed Oct 15 00:53:17 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 15 Oct 2025 00:53:17 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Tue, 14 Oct 2025 05:27:46 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update TestJhsdbJstackWithVirtualThread.java I guess `jhsdb jstack --mixed` might have potential bug(s) in `-Xcomp` regardless of continuation stub handling. I ran `jhsdb jstack --mixed` with this PR to attach to the process running with `-Xcomp` on Linux x86_64, I got similar strange stack traces (without error) as following. It seems not to unwind completely in `-Xcomp`. LWP 1332 was failed to find sender frame from 0x7f9debcd96c0, LWP 1331 and 1330 are not compiled frame, but they couldn't find sender frame (maybe stack unwinder in jhsdb decide to stop unwinding because sender frame is NULL). ----------------- 1332 ----------------- "ForkJoinPool-1-worker-2" #29 daemon prio=5 tid=0x00007f9dfc2ad7b0 nid=1332 runnable [0x00007f9dd19fd000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f9e0337e462 __syscall_cancel_arch + 0x32 0x00007f9e0337275c __internal_syscall_cancel + 0x5c 0x00007f9e033cec37 __GI___nanosleep + 0x17 0x00007f9e033e114e __sleep + 0x3e 0x00007f9deb4b361e 0x00007f9debcd96c0 * java.lang.invoke.LambdaForm$MH+0x000000000f047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) 0x8b486428ec834853 ???????? ----------------- 1331 ----------------- "ForkJoinPool-1-worker-1" #27 daemon prio=5 tid=0x00007f9dfc2ac5b0 nid=1331 runnable [0x00007f9dd1afd000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f9e0337e462 __syscall_cancel_arch + 0x32 0x00007f9e0337275c __internal_syscall_cancel + 0x5c 0x00007f9e033cec37 __GI___nanosleep + 0x17 0x00007f9e033e114e __sleep + 0x3e 0x00007f9deb4b361e 0x00007f9de45d5c2c * java.lang.invoke.LambdaForm$MH+0x000000000f047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) * java.lang.invoke.LambdaForm$MH+0x000000000f04f000.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame) * jdk.internal.foreign.abi.DowncallStub+0x000000000f048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) ----------------- 1330 ----------------- "VirtualThread-unblocker" #25 daemon prio=5 tid=0x00007f9dfc297b50 nid=1330 runnable [0x00007f9dd1bfd000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f9e0337e462 __syscall_cancel_arch + 0x32 0x00007f9e0337275c __internal_syscall_cancel + 0x5c 0x00007f9e0337549e __GI___pthread_cond_wait + 0x14e 0x00007f9e01f0d834 PlatformEvent::park() + 0xe4 0x00007f9e019889ca JVM_TakeVirtualThreadListToUnblock + 0x1ba 0x00007f9debc9cc16 java.lang.VirtualThread.takeVirtualThreadListToUnblock() + 0x96 (Native method) In addition, I saw following error when I added both `-Xcomp` and `-XX:+PreserveFramePointer` in Linux x86_64. Note that I haven't seen this with `-XX:+PreserveFramePointer` only. java.lang.RuntimeException: newSP(0x00007f345cb14690) is not above oldSP(0x00007f345cb14690) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:156) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) ----------------- 1425 ----------------- "ForkJoinPool-1-worker-4" #33 daemon prio=5 tid=0x00007f34782bac50 nid=1425 runnable [0x00007f345ca14000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f3482592462 __syscall_cancel_arch + 0x32 0x00007f348258675c __internal_syscall_cancel + 0x5c 0x00007f34825e2c37 __GI___nanosleep + 0x17 0x00007f34825f514e __sleep + 0x3e 0x00007f34673a899e 0x00007f3467ce4d44 * java.lang.invoke.LambdaForm$MH+0x0000000034047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) 0x00007f3467ce5094 * java.lang.invoke.LambdaForm$MH+0x000000003404e800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame) 0x00007f346733fe48 * jdk.internal.foreign.abi.DowncallStub+0x0000000034048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x00007f3460674744 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame) 0x00007f3460739944 * java.lang.invoke.LambdaForm$MH+0x000000003404c800.invoke(java.lang.Object, int) bci:44 (Compiled frame) 0x00007f346072f3ac * java.lang.invoke.LambdaForm$MH+0x000000003404b800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame) 0x00007f346733fd00 * Test.run() bci:9 line:40 (Interpreted frame) 0x00007f346733e098 0x00007f3467cbeb50 * jdk.internal.vm.Continuation.run() bci:152 line:251 (Compiled frame) 0x00007f3467cd0eb8 * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Compiled frame) 0x00007f3467cbbf40 * java.lang.VirtualThread$$Lambda+0x000000003402a848.run() bci:4 (Compiled frame) 0x00007f3467cd13e8 * java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec() bci:4 line:1596 (Compiled frame) 0x00007f3467cd01e0 * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Compiled frame) * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Compiled frame) 0x00007f346733fd00 * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame) 0x00007f3467cb6b04 * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Compiled frame) 0x00007f34673386fd 0x00007f34809c0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce 0x00007f34809c11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3 0x00007f34809c17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab 0x00007f3480b83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0 0x00007f3480a02806 JavaThread::thread_main_inner() + 0x256 0x00007f3481665b57 Thread::call_run() + 0xb7 0x00007f34810fc588 thread_native_entry(Thread*) + 0x128 0x00007f3482589f54 start_thread + 0x2e4 ----------------- 1424 ----------------- "ForkJoinPool-1-worker-3" #31 daemon prio=5 tid=0x00007f34782b6d00 nid=1424 runnable [0x00007f345cb14000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native 0x00007f3482592462 __syscall_cancel_arch + 0x32 0x00007f348258675c __internal_syscall_cancel + 0x5c 0x00007f34825e2c37 __GI___nanosleep + 0x17 0x00007f34825f514e __sleep + 0x3e 0x00007f34673a899e 0x00007f3467ce4d44 * java.lang.invoke.LambdaForm$MH+0x0000000034047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame) 0x00007f346074ed84 * java.lang.invoke.LambdaForm$MH+0x000000003404e800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame) 0x00007f346733fe48 * jdk.internal.foreign.abi.DowncallStub+0x0000000034048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame) 0x00007f3467cda978 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame) 0x00007f3467cd9118 * java.lang.invoke.LambdaForm$MH+0x000000003404d000.invoke(java.lang.Object, int) bci:44 (Compiled frame) 0x00007f3467cd5c94 * java.lang.invoke.LambdaForm$MH+0x000000003404b800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame) 0x00007f34607129fc * Test.run() bci:9 line:40 (Compiled frame) 0x00007f346733e098 0x00007f3467cbeb50 0x00007f3467cd0eb8 0x00007f3467cbbf40 0x00007f3460726924 0x00007f3460723b24 0x00007f346733fd00 return entry points 0x00007f3467cb6b04 0x00007f34673386fd 0x00007f34809c0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce 0x00007f34809c11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3 0x00007f34809c17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab 0x00007f3480b83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0 0x00007f3480a02806 JavaThread::thread_main_inner() + 0x256 0x00007f3481665b57 Thread::call_run() + 0xb7 0x00007f34810fc588 thread_native_entry(Thread*) + 0x128 0x00007f3482589f54 start_thread + 0x2e4 This is a problem in restoring Java frame, not native frame - native frame unwinding depends on DWARF in Linux x86_64, on FP ( `X29` ) in AArch64. Thus we might need to fix unwinder for Java frames. But it is another issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3404126783 From kbarrett at openjdk.org Wed Oct 15 00:58:07 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 15 Oct 2025 00:58:07 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Tue, 14 Oct 2025 20:20:18 GMT, David Holmes wrote: >> src/hotspot/os/posix/signals_posix.cpp line 172: >> >>> 170: static OSXSemaphore* sr_semaphore; >>> 171: #else >>> 172: static PosixSemaphore* sr_semaphore; >> >> I don't think consistency with the other semaphore is a great reason for >> avoiding the use of `DeferredStatic` here. Indeed, I would prefer that >> `DeferredStatic` be used for both semaphores. >> >> I think the only change from what's already being proposed here to make >> `sr_semaphore` be `DeferredStatic` is the declaration and the initialization. >> >> The changes needed for `sig_semaphore` to be `DeferredStatic` are pretty >> small. Change the declaration and initialization, and os::signal_notify needs >> to be adjusted. The last I think actually makes the code clearer and more >> consistent. >> >> >> void os::signal_notify(int sig) { >> - if (sig_semaphore != nullptr) { >> + if (!ReduceSignalUsage) { >> AtomicAccess::inc(&pending_signals[sig]); >> sig_semaphore->signal(); >> - } else { >> - // Signal thread is not created with ReduceSignalUsage and jdk_misc_signal_init >> - // initialization isn't called. >> - assert(ReduceSignalUsage, "signal semaphore should be created"); >> } >> } >> >> >> That would change a too-early signal to a crash in a product build, except our >> signal handlers are installed after the semaphores are initialized. > > Thanks for taking a look @kimbarrett . I expected someone would say "why not switch both to DeferredStatic?" and I don't have an issue doing that (missing init checks notwithstanding), but it wasn't my immediate goto because I don't see `DeferredStatic as really being any superior to declaring a pointer instead (which is how we do lazy initialization in 99.9% of the VM). DeferredStatic avoids the memory allocation for initialization, and removes a memory dereference when using. We use pointers at least in part because the technology on which DeferredStatic is based requires C++11 (which we've not been using for all that long). And it took a while for someone to get sufficiently annoyed with the pointer idiom to try to do better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430851278 From kbarrett at openjdk.org Wed Oct 15 00:58:08 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 15 Oct 2025 00:58:08 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: <4KE6YvcEaC26rgsJYmC-6B4tXejF_WuSNfJHdlFpAyQ=.2b642a2f-91f4-4eb0-914a-f7ec58407155@github.com> On Wed, 15 Oct 2025 00:54:36 GMT, Kim Barrett wrote: >> Thanks for taking a look @kimbarrett . I expected someone would say "why not switch both to DeferredStatic?" and I don't have an issue doing that (missing init checks notwithstanding), but it wasn't my immediate goto because I don't see `DeferredStatic as really being any superior to declaring a pointer instead (which is how we do lazy initialization in 99.9% of the VM). > > DeferredStatic avoids the memory allocation for initialization, and removes a > memory dereference when using. > > We use pointers at least in part because the technology on which > DeferredStatic is based requires C++11 (which we've not been using for all > that long). And it took a while for someone to get sufficiently annoyed with > the pointer idiom to try to do better. I won't block the change as-is if you really don't want to do DeferredStatic, but I think you should. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430852385 From ysuenaga at openjdk.org Wed Oct 15 01:03:57 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 15 Oct 2025 01:03:57 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Move Thread.yield() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/b82bb9aa..e64d696b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=08-09 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From dholmes at openjdk.org Wed Oct 15 01:27:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 01:27:37 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: > Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. > > Testing: > - tiers 1-3 sanity > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Switch to DeferredStatic per Kim's request ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27762/files - new: https://git.openjdk.org/jdk/pull/27762/files/be87f8e9..a8982e70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27762&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27762&range=00-01 Stats: 20 lines in 1 file changed: 5 ins; 8 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27762/head:pull/27762 PR: https://git.openjdk.org/jdk/pull/27762 From dholmes at openjdk.org Wed Oct 15 01:30:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 01:30:06 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Tue, 14 Oct 2025 06:57:34 GMT, Stefan Karlsson wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to DeferredStatic per Kim's request > > Looks good. I don't understand how those semaphore were guaranteed to be correctly initialized before, so I'm happy to see this change that explicitly initialization of them. Thanks for the review @stefank - somehow I didn't see your review before I saw Kim's request to use `DeferredStatic` which I have now done. > I don't understand how those semaphore were guaranteed to be correctly initialized before It was statically initialized as part of loading libjvm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27762#issuecomment-3404186490 From kbarrett at openjdk.org Wed Oct 15 02:10:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 15 Oct 2025 02:10:03 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Wed, 15 Oct 2025 01:27:37 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DeferredStatic per Kim's request src/hotspot/os/posix/signals_posix.cpp line 356: > 354: // Initialize signal semaphore > 355: int sem_count = 0; > 356: sig_semaphore.initialize(sem_count); Just `sig_semaphore.initialize();` should be work. And the variable declaration looks kind of odd in context. src/hotspot/os/posix/signals_posix.cpp line 363: > 361: // initialization isn't called. This code is also never called. > 362: assert(!ReduceSignalUsage, "Should not reach here if ReduceSignalUsage is set"); > 363: Even better than my suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430923042 PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2430920380 From cjplummer at openjdk.org Wed Oct 15 03:03:03 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 15 Oct 2025 03:03:03 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Wed, 15 Oct 2025 01:03:57 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Move Thread.yield() The changes look good. Thanks for taking care of this. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3338179214 From darcy at openjdk.org Wed Oct 15 04:45:33 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Oct 2025 04:45:33 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests Message-ID: Updating tests I've wrote to conform to current conventions of not having author tags. ------------- Commit messages: - JDK-8369858: Remove darcy author tags from jdk tests Changes: https://git.openjdk.org/jdk/pull/27813/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27813&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369858 Stats: 130 lines in 63 files changed: 0 ins; 67 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/27813.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27813/head:pull/27813 PR: https://git.openjdk.org/jdk/pull/27813 From alanb at openjdk.org Wed Oct 15 06:08:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 15 Oct 2025 06:08:02 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 04:37:50 GMT, Joe Darcy wrote: > Updating tests I've wrote to conform to current conventions of not having author tags. I think it's always okay to remove oneself but I see some of the `@author` tags list others (Stuart, Kumar, even madbot). I didn't check the history but I will guess that you created these tests, others added their name when they modified the test at some point later, is that right? test/jdk/java/lang/reflect/Generics/getAnnotationTest.java line 2: > 1: /* > 2: * Copyright (c) 2004, 2025,Oracle and/or its affiliates. All rights reserved. The skara bot has spotted the formatting issue here. ------------- PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3338492969 PR Review Comment: https://git.openjdk.org/jdk/pull/27813#discussion_r2431217576 From stefank at openjdk.org Wed Oct 15 06:22:01 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 15 Oct 2025 06:22:01 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: <_fbfezfsG-aCuWLAnZfLwp_V-YR4LztH_r-LxO72n84=.2732c7dd-38db-4d74-9563-3f358a5404c5@github.com> On Wed, 15 Oct 2025 01:26:58 GMT, David Holmes wrote: > > I don't understand how those semaphore were guaranteed to be correctly initialized before > > It was statically initialized as part of loading libjvm. I understand that part. I still don't understand how it was *correctly* initialized with a proper call to the C++ constructor. Maybe I'll see if I can catch that in the debugger. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27762#issuecomment-3404732262 From sspitsyn at openjdk.org Wed Oct 15 06:22:05 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 15 Oct 2025 06:22:05 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi wrote: > `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`. > > Passes tier1 and tier2 (fastdebug). David posted: > I'd be more inclined to treat the has_been_modified aspect of JvmtiClassFileLoadHookPoster as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ? I agree with David. It is better to treat the the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3404733969 From stefank at openjdk.org Wed Oct 15 06:26:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 15 Oct 2025 06:26:05 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Wed, 15 Oct 2025 01:27:37 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DeferredStatic per Kim's request Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27762#pullrequestreview-3338563434 From duke at openjdk.org Wed Oct 15 06:27:05 2025 From: duke at openjdk.org (duke) Date: Wed, 15 Oct 2025 06:27:05 GMT Subject: RFR: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output In-Reply-To: References: Message-ID: <_hAr05SnLGZ19Gq-GSKSLetjZ57bWUQ-yp3ZZIwBg7Q=.b422ad29-f05e-4310-ac01-04ec1e60ff29@github.com> On Fri, 10 Oct 2025 11:27:30 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369559 > > Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: > > > $ cat aot.map | grep MethodTrainingData > 0x00000008019d54c0: @@ MethodTrainingData 96 > 0x00000008019dcec8: @@ MethodTrainingData 96 > [...] > > $ cat aot.map | grep CompileTrainingData > [...] > 0x000000080079c8a0: @@ CompileTrainingData 80 > 0x00000008007a7660: @@ CompileTrainingData 80 > > > Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. > > The output should look like the following: > > > $ cat aot.map | grep CompileTrainingData > 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() > 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() > 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() > [...] > > $ cat aot.map | grep MethodTrainingData > 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) > 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() > 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) > [...] > > > Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. > > Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). @Delawen Your change (at version de83ccbb8fcb33eb752aba43e4222aa14401ba27) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27740#issuecomment-3404749361 From azafari at openjdk.org Wed Oct 15 07:31:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 07:31:58 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v11] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: another NOT_LP64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/06281646..e62655d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From jsjolen at openjdk.org Wed Oct 15 07:49:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 07:49:03 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v11] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 07:31:58 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > another NOT_LP64 Changes requested by jsjolen (Reviewer). src/hotspot/share/nmt/mallocHeader.hpp line 96: > 94: public: > 95: AsanPoisoningHelper() = delete; > 96: AsanPoisoningHelper(U* addr) : _memory_region(addr) { This is what I meant, then you don't need any casting when passing along the args. ```c++ template class AsanPoisoningHelper { public: AsanPoisoningHelper(T* addr) : _memory_region(addr) { #if INCLUDE_ASAN ASAN_UNPOISON_MEMORY_REGION(reinterpret_cast(_memory_region), sizeof(T)); #endif } }; test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 330: > 328: a = 3; > 329: EXPECT_EQ(a, 3); > 330: } If the intent of this test is to test ASAN when it's disabled, then move the test to before the ASAN-inclusion test, and delete the `APH` template specialization. ------------- PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3338843340 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431468499 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431452168 From jsjolen at openjdk.org Wed Oct 15 07:49:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 07:49:07 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v7] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 13:11:26 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/mallocHeader.hpp line 120: >> >>> 118: static void unregister_memory(char* addr) { } >>> 119: ~AsanPoisoner() { } >>> 120: }; >> >> I think you can delete this definition > > Kept. to be used in gtests. See comment about the `using` statements. >> src/hotspot/share/nmt/mallocHeader.hpp line 130: >> >>> 128: using SizeType = void; >>> 129: NOT_LP64(using AltCanaryType = void;) >>> 130: #endif >> >> Surely this won't work, as we're using some of these types as return types in functions? > > return values removed. Then we're doing a lot of special code in the implementation only for the purpose of testing. That's going to be quite surprising for the next reader. If anything, we *should* use these typedefs in the implementation. >> src/hotspot/share/sanitizers/address.hpp line 29: >> >>> 27: >>> 28: #ifdef ADDRESS_SANITIZER >>> 29: #define __SANITIZE_ADDRESS__ >> >> Why not just check for `ADDRESS_SANITIZER` in the test, and skip this definition? > > In `.../clang/15.0.0/include/sanitizer/asan_interface.h`, the ASAN_(UN)POISON_MEMORY_REGION macros would be empty as > ```C++ > // Macros provided for convenience. > #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__) > /// Marks a memory region as unaddressable. > /// > /// \note Macro provided for convenience; defined as a no-op if ASan is not > /// enabled. > /// > /// \param addr Start of memory region. > /// \param size Size of memory region. > #define ASAN_POISON_MEMORY_REGION(addr, size) \ > __asan_poison_memory_region((addr), (size)) > > /// Marks a memory region as addressable. > /// > /// \note Macro provided for convenience; defined as a no-op if ASan is not > /// enabled. > /// > /// \param addr Start of memory region. > /// \param size Size of memory region. > #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \ > __asan_unpoison_memory_region((addr), (size)) > #else > #define ASAN_POISON_MEMORY_REGION(addr, size) \ > ((void)(addr), (void)(size)) > #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \ > ((void)(addr), (void)(size)) > #endif > > > I couldn't find yet why is that. So a fast/certain solution was to define the `__SANITIZE_ADDRESS__` explicitly. > Should be found before integrating this PR. Surely if `INCLUDE_ASAN` is true/present, then the definitions of `ASAN_POISION_MEMORY_REGION` etc is also present? Or are you saying that the tests failed without this code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431470281 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431458817 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431478214 From fandreuzzi at openjdk.org Wed Oct 15 08:57:56 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 08:57:56 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v2] In-Reply-To: References: Message-ID: > `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`. > > Passes tier1 and tier2 (fastdebug). Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - remove dead code - revert - Merge branch 'master' into JDK-8369734 - use ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27777/files - new: https://git.openjdk.org/jdk/pull/27777/files/ad416a98..8fbf7599 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=00-01 Stats: 5110 lines in 177 files changed: 1555 ins; 3254 del; 301 mod Patch: https://git.openjdk.org/jdk/pull/27777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777 PR: https://git.openjdk.org/jdk/pull/27777 From clanger at openjdk.org Wed Oct 15 09:00:01 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 09:00:01 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 00:52:08 GMT, David Holmes wrote: > Seems reasonable but the JBS issue does not indicate how/why the test fails on Musl debug. The parent issue of JBS item (it's a subtask) shows the symptom of the failing test quite clear, I think, no? https://bugs.openjdk.org/browse/JDK-8366133 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3405298559 From fandreuzzi at openjdk.org Wed Oct 15 09:00:03 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 09:00:03 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used In-Reply-To: References: Message-ID: <7bwGb0-sxPKYEcK7XXUa9XiPjeft5hUAsh_fX2VFTVI=.67b62c75-c78f-4d3c-8b9a-de63f213c2b9@github.com> On Tue, 14 Oct 2025 05:37:43 GMT, David Holmes wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Sorry for ping-ponging on the serviceability labeling. I'm not sure this is the right fix. The logic to return a value from `post_class_file_load_hook` was added way back in JDK 9 by [JDK-8171008](https://bugs.openjdk.org/browse/JDK-8171008) as part of the original AOT compiler effort. But at that time no changes were made to any of the callers to use the new return value! That means this aspect of the code is completely untested - and it is also completely undocumented. > > I'd be more inclined to treat the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ? Thanks for the feedback @dholmes-ora and @sspitsyn, I removed the dead code in 8fbf759. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405308607 From duke at openjdk.org Wed Oct 15 09:20:32 2025 From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=) Date: Wed, 15 Oct 2025 09:20:32 GMT Subject: Integrated: 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 11:27:30 GMT, Mar?a Arias de Reyna Dom?nguez wrote: > Provides part of fixes for: https://bugs.openjdk.org/browse/JDK-8363440 > Fixes: https://bugs.openjdk.org/browse/JDK-8369559 > > Right now, MethodTrainingData and CompileTrainingData do not show to what Method they belong to: > > > $ cat aot.map | grep MethodTrainingData > 0x00000008019d54c0: @@ MethodTrainingData 96 > 0x00000008019dcec8: @@ MethodTrainingData 96 > [...] > > $ cat aot.map | grep CompileTrainingData > [...] > 0x000000080079c8a0: @@ CompileTrainingData 80 > 0x00000008007a7660: @@ CompileTrainingData 80 > > > Add the method name to those lines in the AOT map to add more context. Also, for CompileTrainingData, add the level of compilation. > > The output should look like the following: > > > $ cat aot.map | grep CompileTrainingData > 0x000000080079c8a0: @@ CompileTrainingData 80 3 int java.lang.Byte.hashCode() > 0x00000008007a7660: @@ CompileTrainingData 80 3 java.lang.Object java.lang.ref.Reference.get() > 0x00000008007a76b0: @@ CompileTrainingData 80 4 java.lang.Object java.lang.ref.Reference.get() > [...] > > $ cat aot.map | grep MethodTrainingData > 0x00000008007864c0: @@ MethodTrainingData 96 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) > 0x00000008007884f0: @@ MethodTrainingData 96 boolean java.lang.Module.isNamed() > 0x00000008007892f8: @@ MethodTrainingData 96 boolean java.lang.Module.implIsExportedOrOpen(java.lang.String, java.lang.Module, boolean) > [...] > > > Note the number before the method signature on CompileTrainingData that represents the level, important because there are two CompileTrainingData for the same method with different compilation levels. > > Some elements have a nullpointer instead of a valid Method, and those will be represented without method signature (as they appear currently, with no changes). This pull request has now been integrated. Changeset: 355cb459 Author: Mar?a Arias de Reyna Dom?nguez Committer: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/355cb45943797ff2e8f2634c20100e85a53096d0 Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output Reviewed-by: adinn, iklam ------------- PR: https://git.openjdk.org/jdk/pull/27740 From sspitsyn at openjdk.org Wed Oct 15 09:27:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 15 Oct 2025 09:27:41 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - remove dead code > - revert > - Merge branch 'master' into JDK-8369734 > - use Thank you for taking care about this and update! Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3339340217 From aturbanov at openjdk.org Wed Oct 15 09:17:01 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 15 Oct 2025 09:17:01 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: <9VZzFn1G5rtO1imn3pPRMNN4MoCq6VXkCMkrzuXwTGc=.3a248323-d912-4fef-853f-128d028d1266@github.com> On Wed, 15 Oct 2025 01:03:57 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Move Thread.yield() test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 70: > 68: try { > 69: hndSleep.invoke(sleepArg); > 70: } catch(Throwable t) { Suggestion: } catch (Throwable t) { test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 83: > 81: signal.await(); > 82: LingeredApp.main(args); > 83: } catch(Exception e) { Suggestion: } catch (Exception e) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2431780907 PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2431781235 From fandreuzzi at openjdk.org Wed Oct 15 09:32:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 09:32:19 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v3] In-Reply-To: References: Message-ID: > The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. > > Passes tier1 and tier2 (fastdebug). Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: don't return ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27777/files - new: https://git.openjdk.org/jdk/pull/27777/files/8fbf7599..8f7f0feb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777 PR: https://git.openjdk.org/jdk/pull/27777 From fandreuzzi at openjdk.org Wed Oct 15 09:32:22 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 09:32:22 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - remove dead code > - revert > - Merge branch 'master' into JDK-8369734 > - use Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405455797 From mbaesken at openjdk.org Wed Oct 15 10:08:20 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Oct 2025 10:08:20 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 12:54:30 GMT, Christoph Langer wrote: > Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. looks okay but why the blanks in the added ` ( ... ) ` they look a bit unusual ? ------------- PR Review: https://git.openjdk.org/jdk/pull/27770#pullrequestreview-3339513730 From mbaesken at openjdk.org Wed Oct 15 10:11:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Oct 2025 10:11:19 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:54:52 GMT, Christoph Langer wrote: > Seems reasonable but the JBS issue does not indicate how/why the test fails on Musl debug. Maybe we should refer to https://bugs.openjdk.org/browse/JDK-8366133 8366133: Test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine fastdebug after JDK-8363949 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3405618293 From azafari at openjdk.org Wed Oct 15 10:16:54 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 10:16:54 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v12] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: - include order - clean ups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/e62655d7..fadd9d6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=10-11 Stats: 66 lines in 2 files changed: 6 ins; 36 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Wed Oct 15 10:16:56 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 10:16:56 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v11] In-Reply-To: References: Message-ID: <07IfC3kYECdx2mNdptZyouB8PE2NyeHbeWJOuVpG9EQ=.5c12bf01-f183-48ec-927a-d1d249596852@github.com> On Wed, 15 Oct 2025 07:31:58 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > another NOT_LP64 I prefer to put the APH in `sanitizers/address.hpp`. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3405645829 From azafari at openjdk.org Wed Oct 15 10:16:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 10:16:58 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v11] In-Reply-To: References: Message-ID: <_CQk-4uiT8P-KeTQ7yvDDgLnPLaAFj2qZ4DtqgM8dGY=.e00139fd-4f80-4838-86c3-cbbc49706f7b@github.com> On Wed, 15 Oct 2025 07:43:04 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> another NOT_LP64 > > src/hotspot/share/nmt/mallocHeader.hpp line 96: > >> 94: public: >> 95: AsanPoisoningHelper() = delete; >> 96: AsanPoisoningHelper(U* addr) : _memory_region(addr) { > > This is what I meant, then you don't need any casting when passing along the args. > > ```c++ > template > class AsanPoisoningHelper { > > public: > AsanPoisoningHelper(T* addr) : _memory_region(addr) { > #if INCLUDE_ASAN > ASAN_UNPOISON_MEMORY_REGION(reinterpret_cast(_memory_region), sizeof(T)); > #endif > } > }; since we are using `const ...` types for `T`, we cannot use `reinterpret_cast`. Casting is avoided everywhere by introducing second template parameter `U`. > test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 330: > >> 328: a = 3; >> 329: EXPECT_EQ(a, 3); >> 330: } > > If the intent of this test is to test ASAN when it's disabled, then move the test to before the ASAN-inclusion test, and delete the `APH` template specialization. Not needed. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431982731 PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2431975022 From ysuenaga at openjdk.org Wed Oct 15 10:27:24 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 15 Oct 2025 10:27:24 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11] In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Cosmetic change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27728/files - new: https://git.openjdk.org/jdk/pull/27728/files/e64d696b..a8e3f4f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728 PR: https://git.openjdk.org/jdk/pull/27728 From azafari at openjdk.org Wed Oct 15 10:42:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 10:42:42 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Tue, 14 Oct 2025 07:05:01 GMT, Stefan Karlsson wrote: > I don't know the reason for NMT trying to take the look recursively NMT report gets the current amounts of allocations for Chunks, so it uses the lock to stop others from changing the values. The deadlock happens, for example, when `ChunkPool::prune()` is free-ing a memory that is already corrupted. At `os::free()` time, NMT detects the corruption and tries to report it while the lock is already taken by ChunkPool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3405786443 From azafari at openjdk.org Wed Oct 15 11:37:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 15 Oct 2025 11:37:57 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v13] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer - include order - clean ups - another NOT_LP64 - NOT_LP64 code fix - register_memory -> poison_memory - reviews applied - better style - a step back - alternative impl - ... and 6 more: https://git.openjdk.org/jdk/compare/e95b2670...2b143527 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/fadd9d6e..2b143527 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=11-12 Stats: 20849 lines in 508 files changed: 13342 ins; 5969 del; 1538 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From jsjolen at openjdk.org Wed Oct 15 11:50:22 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 11:50:22 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Tue, 14 Oct 2025 13:47:13 GMT, Stefan Karlsson wrote: >> The style guide doesn't mention it because I don't think we have consistent >> usage, and I haven't felt like stirring that pot. (Others are, of course, free >> to do so.) Personally I use no-indent unless the surrounding code uses >> 1sp-indent. And only change an existing 1sp-indent to no-indent if it seems >> out of place compared to surrounding code and I happen to be touching >> something nearby. (switch/case labels are similarly inconsistent in our code.) > > FWIW, I've been removing one-space indents for years now. It's my experience that the no-space indent for access modifiers is what we're moving towards. Obviously, this has clearly been done through an informal and ad-hoc process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2432259511 From jsjolen at openjdk.org Wed Oct 15 11:58:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 11:58:01 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <-UnbsYzVUxdVJGgkrChNQypJtYUCXQx782lEpT8uROU=.373ff05b-61eb-4398-ad59-618f0e37dda4@github.com> Message-ID: On Tue, 14 Oct 2025 05:11:23 GMT, David Holmes wrote: >> I don't see how it can work without recursion count ... > > Doh! Yep Zhengyu is right. Aaah right, we must only unlock on `recursion_count == 0`. I completely missed this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2432279429 From jsjolen at openjdk.org Wed Oct 15 12:03:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 12:03:09 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len wrote: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. Afshin's description is correct. It would be preferable to have a recursive mutex in this case, imho. It's unfortunate that we have to implement another type of lock. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3406046992 From dholmes at openjdk.org Wed Oct 15 12:17:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:17:53 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 11:47:33 GMT, Johan Sj?len wrote: >> FWIW, I've been removing one-space indents for years now. > > It's my experience that the no-space indent for access modifiers is what we're moving towards. Obviously, this has clearly been done through an informal and ad-hoc process. Pity this was never discussed. I loathe having constructs that mean something not being indented. I have been using one-space indent for access modifiers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2432332687 From clanger at openjdk.org Wed Oct 15 12:22:26 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 12:22:26 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v2] In-Reply-To: References: Message-ID: > Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Remove blanks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27770/files - new: https://git.openjdk.org/jdk/pull/27770/files/e5916e7d..a2e1a554 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27770&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27770&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27770/head:pull/27770 PR: https://git.openjdk.org/jdk/pull/27770 From clanger at openjdk.org Wed Oct 15 12:22:27 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 12:22:27 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 10:05:04 GMT, Matthias Baesken wrote: > looks okay but why the blanks in the added `( ... ) ` they look a bit unusual ? Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3406119207 From clanger at openjdk.org Wed Oct 15 12:22:29 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 12:22:29 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: <_YTGGwAyAccp444eib8lglRA4C82qcQlb5WiCxXYMWA=.3fd62ade-0609-4d2e-a8c5-02ed0fa5ff0e@github.com> On Wed, 15 Oct 2025 10:08:15 GMT, Matthias Baesken wrote: > > Seems reasonable but the JBS issue does not indicate how/why the test fails on Musl debug. > > Maybe we should refer to https://bugs.openjdk.org/browse/JDK-8366133 8366133: Test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine fastdebug after JDK-8363949 ? I'd like to add a comment in the jtreg directives section pointing to JDK-8366133 but I'm not sure how that would work syntactically... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3406124233 From dholmes at openjdk.org Wed Oct 15 12:23:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:23:53 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Wed, 15 Oct 2025 01:27:37 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DeferredStatic per Kim's request > > > I don't understand how those semaphore were guaranteed to be correctly initialized before > > > > > > It was statically initialized as part of loading libjvm. > > I understand that part. I still don't understand how it was _correctly_ initialized with a proper call to the C++ constructor. Maybe I'll see if I can catch that in the debugger. I assumed the constructor was automagically called the same way the destructor gets called at process exit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27762#issuecomment-3406134459 From dholmes at openjdk.org Wed Oct 15 12:26:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:26:55 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: <_MCcka1pfmFxc75l6VikDBdyX2flNBZof-5FEZMTBFI=.c77c1a53-3cfa-4ee2-bb1a-51bd8a997288@github.com> On Wed, 15 Oct 2025 02:03:43 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to DeferredStatic per Kim's request > > src/hotspot/os/posix/signals_posix.cpp line 356: > >> 354: // Initialize signal semaphore >> 355: int sem_count = 0; >> 356: sig_semaphore.initialize(sem_count); > > Just `sig_semaphore.initialize();` should be work. And the variable declaration looks kind of odd in context. I was not sure how the "magic" of initialization worked in this case with default constructor arguments - plus I wanted to be explicit about the initial count. Unfortunately the template requires a reference hence the local was introduced - if there is a better way to do this please advise me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2432357823 From dholmes at openjdk.org Wed Oct 15 12:29:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:29:52 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:54:52 GMT, Christoph Langer wrote: > > Seems reasonable but the JBS issue does not indicate how/why the test fails on Musl debug. > > The parent issue of JBS item (it's a subtask) shows the symptom of the failing test quite clear, I think, no? > > https://bugs.openjdk.org/browse/JDK-8366133 Sorry I only saw the JBS issue as a notification email and then jumped to the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3406158488 From dholmes at openjdk.org Wed Oct 15 12:34:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:34:50 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 12:22:26 GMT, Christoph Langer wrote: >> Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove blanks test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 42: > 40: /* > 41: * @test id=DumpThreadsBeforeDetach > 42: * @requires os.family != "windows" & os.family != "aix" & (!vm.musl | !vm.debug) Suggestion: * @comment Temporarily exclude on Musl-C debug until JDK-8366133 is fixed. * @requires os.family != "windows" & os.family != "aix" & (!vm.musl | !vm.debug) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27770#discussion_r2432382430 From dholmes at openjdk.org Wed Oct 15 12:40:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Oct 2025 12:40:00 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v3] In-Reply-To: References: Message-ID: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com> On Wed, 15 Oct 2025 09:32:19 GMT, Francesco Andreuzzi wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > don't return LGTM. Thanks src/hotspot/share/prims/jvmtiExport.cpp line 985: > 983: } > 984: if (new_data != nullptr) { > 985: // this agent has modified class data. The comment could stay. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3340151397 PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432392717 From fandreuzzi at openjdk.org Wed Oct 15 13:52:11 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 13:52:11 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v4] In-Reply-To: References: Message-ID: > The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. > > Passes tier1 and tier2 (fastdebug). Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: restore comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27777/files - new: https://git.openjdk.org/jdk/pull/27777/files/8f7f0feb..37817420 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777 PR: https://git.openjdk.org/jdk/pull/27777 From fandreuzzi at openjdk.org Wed Oct 15 13:52:13 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 15 Oct 2025 13:52:13 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v4] In-Reply-To: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com> References: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com> Message-ID: <8ofLOCG9laKHDsIkzUfXzP8om2uYZ8ouWT72U5gXI5s=.cbffb1ba-244b-4fbb-ad2e-cf036613422d@github.com> On Wed, 15 Oct 2025 12:35:15 GMT, David Holmes wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> restore comment > > src/hotspot/share/prims/jvmtiExport.cpp line 985: > >> 983: } >> 984: if (new_data != nullptr) { >> 985: // this agent has modified class data. > > The comment could stay. 378174203615473d5216cc67fbde50933c3c1c87 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432637267 From matsaave at openjdk.org Wed Oct 15 14:37:55 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 15 Oct 2025 14:37:55 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: References: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> Message-ID: On Fri, 5 Sep 2025 19:44:34 GMT, Dean Long wrote: >> Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered? > >> Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered? > > I think Oracle has enough test coverage in closed tests, but it wouldn't hurt to have more open tests. All I could find in a quick search was open/test/hotspot/jtreg/runtime/handlerInTry. Thanks for the reviews @dean-long and @liach! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3406766050 From matsaave at openjdk.org Wed Oct 15 14:37:56 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 15 Oct 2025 14:37:56 GMT Subject: Integrated: 8364660: ClassVerifier::ends_in_athrow() should be removed In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 18:02:29 GMT, Matias Saavedra Silva wrote: > The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. This pull request has now been integrated. Changeset: 1bd814c3 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/1bd814c3b24eb7ef5633ee34bb418e0981ca1708 Stats: 251 lines in 3 files changed: 0 ins; 250 del; 1 mod 8364660: ClassVerifier::ends_in_athrow() should be removed Reviewed-by: liach, dlong ------------- PR: https://git.openjdk.org/jdk/pull/27107 From clanger at openjdk.org Wed Oct 15 15:11:23 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 15:11:23 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v3] In-Reply-To: References: Message-ID: > Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27770/files - new: https://git.openjdk.org/jdk/pull/27770/files/a2e1a554..393aebff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27770&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27770&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27770/head:pull/27770 PR: https://git.openjdk.org/jdk/pull/27770 From clanger at openjdk.org Wed Oct 15 15:11:26 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Oct 2025 15:11:26 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 12:22:26 GMT, Christoph Langer wrote: >> Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove blanks Thanks, let's see if this causes no syntax errors ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3406927152 From mbaesken at openjdk.org Wed Oct 15 16:56:33 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Oct 2025 16:56:33 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 15:11:23 GMT, Christoph Langer wrote: >> Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27770#pullrequestreview-3341437398 From iklam at openjdk.org Wed Oct 15 17:03:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 15 Oct 2025 17:03:40 GMT Subject: RFR: 8369856: AOT map does not include unregistered classes Message-ID: Thanks to @ashu-mehra for providing the fix! I also updated the test cases: - Use a custom class loader to load unregistered classes - Check that all classes loaded from the AOT cache have an entry in the map file - Rename "CDS" to "AOT" ------------- Commit messages: - added more checks - 8369856: AOT map does not include unregistered classes Changes: https://git.openjdk.org/jdk/pull/27828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369856 Stats: 814 lines in 5 files changed: 443 ins; 351 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27828/head:pull/27828 PR: https://git.openjdk.org/jdk/pull/27828 From jsjolen at openjdk.org Wed Oct 15 17:05:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 17:05:41 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Recur again! ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27759/files - new: https://git.openjdk.org/jdk/pull/27759/files/8cd6d9ff..4fb0bae1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27759&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27759&range=00-01 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27759/head:pull/27759 PR: https://git.openjdk.org/jdk/pull/27759 From jsjolen at openjdk.org Wed Oct 15 17:21:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Oct 2025 17:21:24 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Tue, 14 Oct 2025 07:05:01 GMT, Stefan Karlsson wrote: > > In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > FWIW, in ZGC we deal with similar situations by using this construct instead of a recursive lock: > > ``` > static bool try_lock_on_error(ZLock* lock) { > if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) { > return lock->try_lock(); > } > > lock->lock(); > > return true; > } > > void ZPageAllocator::print_usage_on(outputStream* st) const { > const bool locked = try_lock_on_error(&_lock); > > if (!locked) { > st->print_cr(""); > } > > // Print information even though we may not have successfully taken the lock. > // This is thread-safe, but may produce inconsistent results. > > print_total_usage_on(st); > > StreamIndentor si(st, 1); > print_partition_usage_on(st); > > if (locked) { > _lock.unlock(); > } > } > ``` > > I don't know the reason for NMT trying to take the look recursively in the error reporter, but maybe something similar to the above would work without adding a new RecursivePlatformMutex? > > Here's another example that simply skips some hs_err logging if the lock is being held (This time with Mutex, though): > > ``` > void GCLogPrecious::print_on_error(outputStream* st) { > st->print_cr("GC Precious Log:"); > > if (_lines == nullptr) { > st->print_cr("\n"); > return; > } > > if (!_lock->try_lock_without_rank_check()) { > st->print_cr("\n"); > return; > } > > if (_lines->size() == 0) { > st->print_cr("\n"); > } else { > st->print_cr("%s", _lines->base()); > } > > _lock->unlock(); > } > ``` That pattern may work for us, as we do not take the lock often. I'll look into this as an alternative path forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3407496411 From kvn at openjdk.org Wed Oct 15 17:23:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 15 Oct 2025 17:23:16 GMT Subject: RFR: 8369856: AOT map does not include unregistered classes In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 16:56:37 GMT, Ioi Lam wrote: > Thanks to @ashu-mehra for providing the fix! > > I also updated the test cases: > > - Use a custom class loader to load unregistered classes > - Check that all classes loaded from the AOT cache have an entry in the map file > - Rename "CDS" to "AOT" Looks good. I suggest to add @ashu-mehra as contributor. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27828#pullrequestreview-3341524941 PR Comment: https://git.openjdk.org/jdk/pull/27828#issuecomment-3407505326 From sspitsyn at openjdk.org Wed Oct 15 17:39:10 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 15 Oct 2025 17:39:10 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 09:28:40 GMT, Francesco Andreuzzi wrote: > Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere? It is because minimal does not include JVMTI. A tweak is needed in `jvmtiExport.hpp` at line 383 as for all other functions returning `void`: `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN` ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3407564232 From cjplummer at openjdk.org Wed Oct 15 17:48:32 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 15 Oct 2025 17:48:32 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Cosmetic change Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3341612959 From darcy at openjdk.org Wed Oct 15 17:49:05 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Oct 2025 17:49:05 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: > Updating tests I've wrote to conform to current conventions of not having author tags. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix formatting typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27813/files - new: https://git.openjdk.org/jdk/pull/27813/files/10aef0dc..4f5360da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27813&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27813&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27813.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27813/head:pull/27813 PR: https://git.openjdk.org/jdk/pull/27813 From darcy at openjdk.org Wed Oct 15 17:49:07 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Oct 2025 17:49:07 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 06:05:30 GMT, Alan Bateman wrote: > I think it's always okay to remove oneself but I see some of the `@author` tags list others (Stuart, Kumar, even madbot). I didn't check the history but I will guess that you created these tests, others added their name when they modified the test at some point later, is that right? Yeah, I wasn't sure of the best way forward for the files will shared authorship and was going to check with Stuart, etc. A few of the shared test files I was the primary author. For some of the old java.math files, madbot was the initial author and I updated the tests later. I can restored the listed author tags for people other than myself if we're not comfortable at this point in just removing author tags. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3407596375 From rriggs at openjdk.org Wed Oct 15 18:28:38 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 15 Oct 2025 18:28:38 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: <0YnCZqVcEN1uNGmfF-ffhV-8KQBG7_24JAlWwoblRw4=.500106dc-aac8-46d3-9540-47b7551bdc2a@github.com> On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341746324 From iris at openjdk.org Wed Oct 15 18:34:48 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 15 Oct 2025 18:34:48 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341762902 From lancea at openjdk.org Wed Oct 15 18:34:48 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 15 Oct 2025 18:34:48 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341768330 From pchilanomate at openjdk.org Wed Oct 15 20:02:14 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 15 Oct 2025 20:02:14 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Cosmetic change Looks good to me too, thanks for fixing this. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3342034292 From prr at openjdk.org Wed Oct 15 20:37:37 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 15 Oct 2025 20:37:37 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo In the client area, when updating a test, as a TOO we usually remove the author tag regardless of who it references. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408178799 From coleenp at openjdk.org Wed Oct 15 20:51:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 20:51:47 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 17:05:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Recur again! I still think it can use RecursiveMutex if you allow RecursiveMutex to have a null Thread*. src/hotspot/share/memory/arena.cpp line 54: > 52: > 53: void lock() { > 54: intx current = os::current_thread_id(); So this is okay but not Thread::current() ? ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3342036013 PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2433793862 From coleenp at openjdk.org Wed Oct 15 20:51:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 20:51:49 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Tue, 14 Oct 2025 05:10:41 GMT, David Holmes wrote: >> But you can't use that one because we may not have a current thread and we don't want safepoint interactions for JavaThreads IIUC. > > It is a `RecursiveMutex` not `RecursivePlatformMutex` RecursiveMutex has safepoint interactions only if the current thread is a JavaThread. It could be modified to have a no-owner sentinel and maybe use os::current_thread() like this equivalent one does. With this deferred static mechanism, I think it can allocate the semaphore which might not be allowed to be allocated with static linkage. This code is almost a copy of that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2433781074 From coleenp at openjdk.org Wed Oct 15 20:51:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 20:51:50 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 12:15:19 GMT, David Holmes wrote: >> It's my experience that the no-space indent for access modifiers is what we're moving towards. Obviously, this has clearly been done through an informal and ad-hoc process. > > Pity this was never discussed. I loathe having constructs that mean something not being indented. I have been using one-space indent for access modifiers. I've been using one-space indent for access modifiers also, and sometimes find two space indentation which doesn't really bother me that much. 0 space indentation doesn't seem that bothersome either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2433787405 From coleenp at openjdk.org Wed Oct 15 20:51:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 20:51:51 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 20:03:09 GMT, Coleen Phillimore wrote: >> Pity this was never discussed. I loathe having constructs that mean something not being indented. I have been using one-space indent for access modifiers. > > I've been using one-space indent for access modifiers also, and sometimes find two space indentation which doesn't really bother me that much. 0 space indentation doesn't seem that bothersome either. In any case, I don't think the number of spaces for the access modifiers should be part of this change here and in arena.hpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2433791219 From coleenp at openjdk.org Wed Oct 15 20:54:32 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 20:54:32 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <-UnbsYzVUxdVJGgkrChNQypJtYUCXQx782lEpT8uROU=.373ff05b-61eb-4398-ad59-618f0e37dda4@github.com> Message-ID: On Wed, 15 Oct 2025 11:55:16 GMT, Johan Sj?len wrote: >> Doh! Yep Zhengyu is right. > > Aaah right, we must only unlock on `recursion_count == 0`. I completely missed this. Thread == nullptr is pre-initialization so is only one thread (the null thread) I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2433913552 From prappo at openjdk.org Wed Oct 15 20:59:16 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 15 Oct 2025 20:59:16 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com> On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo This is a very self-deprecating change. We should ask Dr. Deprecator what he thinks about it, especially since he's acquainted with Stuart Marks, whose authorship is also being removed. In all seriousness, people can be touchy about changes like this. FWIW, when we made a similar change in the `jdk.javadoc` area, we carefully captured authors being removed; see https://bugs.openjdk.org/browse/JDK-8235435 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408249260 From coleenp at openjdk.org Wed Oct 15 21:51:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Oct 2025 21:51:02 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Wed, 15 Oct 2025 20:00:15 GMT, Coleen Phillimore wrote: >> It is a `RecursiveMutex` not `RecursivePlatformMutex` > > RecursiveMutex has safepoint interactions only if the current thread is a JavaThread. It could be modified to have a no-owner sentinel and maybe use os::current_thread() like this equivalent one does. > > With this deferred static mechanism, I think it can allocate the semaphore which might not be allowed to be allocated with static linkage. > > This code is almost a copy of that. I tried making RecursiveLock a template but it's sort of a pain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2434066613 From smarks at openjdk.org Wed Oct 15 23:35:10 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 15 Oct 2025 23:35:10 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: References: Message-ID: <9EdKIXagldkPpMhdKBUbIVr3m8lHBGLXkRPvIWl2Y-Q=.f4bffa4f-1eb5-4263-a2bd-fbc16dc5e919@github.com> On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy wrote: >> Updating tests I've wrote to conform to current conventions of not having author tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting typo test/jdk/java/io/Serializable/cloneArray/CloneArray.java line 28: > 26: * @bug 6990094 > 27: * @summary Verify ObjectInputStream.cloneArray works on many kinds of arrays > 28: * @author Stuart Marks, Joseph D. Darcy No objection to removing my name too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27813#discussion_r2434209645 From prr at openjdk.org Thu Oct 16 00:24:03 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 16 Oct 2025 00:24:03 GMT Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2] In-Reply-To: <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com> References: <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com> Message-ID: On Wed, 15 Oct 2025 20:56:57 GMT, Pavel Rappo wrote: > This is a very self-deprecating change. We should ask Dr. Deprecator what he thinks about it, especially since he's acquainted with Stuart Marks, whose authorship is also being removed. Joe isn't being deprecated for removal. If he were there'd need to be a CSR, and I expect he'd pend it ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408712064 From dholmes at openjdk.org Thu Oct 16 07:20:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Oct 2025 07:20:09 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 20:06:01 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Recur again! > > src/hotspot/share/memory/arena.cpp line 54: > >> 52: >> 53: void lock() { >> 54: intx current = os::current_thread_id(); > > So this is okay but not Thread::current() ? Yes this becomes e.g. `pthread_self()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2434833569 From dholmes at openjdk.org Thu Oct 16 07:37:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Oct 2025 07:37:15 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 17:05:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Recur again! I'm unclear if this particular lock will only encounter a null thread during VM init, or whether it can also be encountered during thread attach? If the former and we really don't need mutual exclusion when the thread is null, then a `ConditionalMutexLocker` might help with that aspect and we could go back to using `Thread::current()`. If `RecursiveMutex` were actually a `Mutex` then we might have been able to use it in conjunction with a `ConditionalMutexLocker`. Otherwise this custom implementation seems okay to me now. ------------- PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3343446645 From dholmes at openjdk.org Thu Oct 16 07:38:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Oct 2025 07:38:20 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 15:11:23 GMT, Christoph Langer wrote: >> Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> LGTM! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27770#pullrequestreview-3343453138 From dholmes at openjdk.org Thu Oct 16 07:42:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Oct 2025 07:42:19 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v4] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > restore comment Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3343463795 From jsjolen at openjdk.org Thu Oct 16 07:55:06 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 07:55:06 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Wed, 15 Oct 2025 21:48:25 GMT, Coleen Phillimore wrote: >> RecursiveMutex has safepoint interactions only if the current thread is a JavaThread. It could be modified to have a no-owner sentinel and maybe use os::current_thread() like this equivalent one does. >> >> With this deferred static mechanism, I think it can allocate the semaphore which might not be allowed to be allocated with static linkage. >> >> This code is almost a copy of that. > > I tried making RecursiveLock a template but it's sort of a pain. It is basically a copy. The reason I went the longer (lines of code-wise) is because I'd prefer it if we didn't spread this implementation around, so having this handmade one in `arena.cpp` seems like an acceptable trade-off to having the RecursiveLock being templated and so on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2434930029 From jsjolen at openjdk.org Thu Oct 16 07:56:21 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 07:56:21 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v13] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 11:37:57 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer > - include order > - clean ups > - another NOT_LP64 > - NOT_LP64 code fix > - register_memory -> poison_memory > - reviews applied > - better style > - a step back > - alternative impl > - ... and 6 more: https://git.openjdk.org/jdk/compare/4e89bd3f...2b143527 As you say, I think it's good to have this as a more general tool in the ASAN support source file. ------------- Changes requested by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3339830605 From jsjolen at openjdk.org Thu Oct 16 07:56:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 07:56:24 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v11] In-Reply-To: <_CQk-4uiT8P-KeTQ7yvDDgLnPLaAFj2qZ4DtqgM8dGY=.e00139fd-4f80-4838-86c3-cbbc49706f7b@github.com> References: <_CQk-4uiT8P-KeTQ7yvDDgLnPLaAFj2qZ4DtqgM8dGY=.e00139fd-4f80-4838-86c3-cbbc49706f7b@github.com> Message-ID: On Wed, 15 Oct 2025 10:12:39 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/mallocHeader.hpp line 96: >> >>> 94: public: >>> 95: AsanPoisoningHelper() = delete; >>> 96: AsanPoisoningHelper(U* addr) : _memory_region(addr) { >> >> This is what I meant, then you don't need any casting when passing along the args. >> >> ```c++ >> template >> class AsanPoisoningHelper { >> >> public: >> AsanPoisoningHelper(T* addr) : _memory_region(addr) { >> #if INCLUDE_ASAN >> ASAN_UNPOISON_MEMORY_REGION(reinterpret_cast(_memory_region), sizeof(T)); >> #endif >> } >> }; > > since we are using `const ...` types for `T`, we cannot use `reinterpret_cast`. > Casting is avoided everywhere by introducing second template parameter `U`. `U` is `T` with `const`, right? Just make `_memory_region` `const T*` and remove `U`. If the `reinterpret_cast` isn't needed for the macro to work, then don't use it. If you need some more advanced modifications of the types involved, then look at the `` header, example: https://en.cppreference.com/w/cpp/types/remove_cv.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2432160165 From clanger at openjdk.org Thu Oct 16 07:57:36 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 16 Oct 2025 07:57:36 GMT Subject: Integrated: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 12:54:30 GMT, Christoph Langer wrote: > Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. This pull request has now been integrated. Changeset: 17c13e53 Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/17c13e53aff16b294c7c0286ccb6ea3054b1de91 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug Reviewed-by: mbaesken, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27770 From clanger at openjdk.org Thu Oct 16 07:57:34 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 16 Oct 2025 07:57:34 GMT Subject: RFR: 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 15:11:23 GMT, Christoph Langer wrote: >> Since the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach is constantly failing for debug builds on Linux Alpine [JDK-8366133](https://bugs.openjdk.org/browse/JDK-8366133), let's exclude it there for the time being. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27770#issuecomment-3409640224 From mbaesken at openjdk.org Thu Oct 16 08:04:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Oct 2025 08:04:19 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 03:41:05 GMT, David Holmes wrote: > Of course you proposed changes as a potential consumer of this information, so how would you like to procure it? I think my support colleague would set the needed UL flags in case her wants to find out more about perfmem issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3409681867 From zgu at openjdk.org Thu Oct 16 08:08:21 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 16 Oct 2025 08:08:21 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Thu, 16 Oct 2025 07:17:23 GMT, David Holmes wrote: >> src/hotspot/share/memory/arena.cpp line 54: >> >>> 52: >>> 53: void lock() { >>> 54: intx current = os::current_thread_id(); >> >> So this is okay but not Thread::current() ? > > Yes this becomes e.g. `pthread_self()` I think it also prevents from the scenarios that having `nullptr` current thread from the first call, then current thread becomes not `nullptr` in subsequent recursive calls. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2434966560 From fandreuzzi at openjdk.org Thu Oct 16 08:15:32 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 16 Oct 2025 08:15:32 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:36:09 GMT, Serguei Spitsyn wrote: >> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere? > >> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere? > > It is because minimal does not include JVMTI. > A tweak is needed in `jvmtiExport.hpp` at line 383 to follow other functions returning `void`: > `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN` Thanks for the review @sspitsyn and @dholmes-ora. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409720063 From duke at openjdk.org Thu Oct 16 08:15:35 2025 From: duke at openjdk.org (duke) Date: Thu, 16 Oct 2025 08:15:35 GMT Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value is never used [v4] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi wrote: >> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. >> >> Passes tier1 and tier2 (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > restore comment @fandreuz Your change (at version 378174203615473d5216cc67fbde50933c3c1c87) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409722637 From zgu at openjdk.org Thu Oct 16 08:16:36 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 16 Oct 2025 08:16:36 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Wed, 15 Oct 2025 17:05:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Recur again! LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3343598597 From jsjolen at openjdk.org Thu Oct 16 08:32:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 08:32:17 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v3] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 07:36:48 GMT, Afshin Zafari wrote: >> On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > style fixed. I'd like to see a JTReg test for this instead, where we actually confirm that the stack is being printed. ------------- PR Review: https://git.openjdk.org/jdk/pull/27764#pullrequestreview-3343655277 From azafari at openjdk.org Thu Oct 16 08:48:56 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 16 Oct 2025 08:48:56 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 08:29:21 GMT, Johan Sj?len wrote: > I'd like to see a JTReg test for this instead, where we actually confirm that the stack is being printed. There is already a JTReg test : `test/hotspot/jtreg/gtest/NMTGtests.java` that runs 3 tests for NMT off, summary and detail modes. In the jtr file of the NMT detail mode, one can see both the call-stack output AND the output when the malloc-site marker is corrupted too. The examples of this output given in previous comments, are copied from there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27764#issuecomment-3409840452 From jsikstro at openjdk.org Thu Oct 16 08:52:29 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 16 Oct 2025 08:52:29 GMT Subject: RFR: 8369983: Remove expired ZGC flags for JDK 26 Message-ID: Hello, The ZGenerational flag was obsoleted in JDK 24 as part of removing the non-generational mode of ZGC in JEP 490. The flag was still obsolete in JDK 25, which is a LTS version, so that user's that might specify/try to use it are prompted with a warning. Now that we're past JDK 25, the flag should be expired. Likewise, the ZMarkStackSpaceLimit flag was obsoleted in JDK 25 and can now be expired in JDK 26. Since neither of these flags were documented in `java.md` I haven't added them to the "Removed Java Options" section in that file. ------------- Commit messages: - 8369983: Remove expired ZGC flags for JDK 26 Changes: https://git.openjdk.org/jdk/pull/27838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369983 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27838/head:pull/27838 PR: https://git.openjdk.org/jdk/pull/27838 From jsjolen at openjdk.org Thu Oct 16 08:58:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 08:58:03 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 08:46:08 GMT, Afshin Zafari wrote: > > I'd like to see a JTReg test for this instead, where we actually confirm that the stack is being printed. > > There is already a JTReg test : `test/hotspot/jtreg/gtest/NMTGtests.java` that runs 3 tests for NMT off, summary and detail modes. In the jtr file of the NMT detail mode, one can see both the call-stack output AND the output when the malloc-site marker is corrupted too. The examples of this output given in previous comments, are copied from there. That's good. Can we make it so that we confirm the presence of the callstack programmatically in a test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27764#issuecomment-3409873522 From azafari at openjdk.org Thu Oct 16 09:31:41 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 16 Oct 2025 09:31:41 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v14] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: AHP -> sanitizers/address.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/2b143527..c644a84a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=12-13 Stats: 62 lines in 2 files changed: 27 ins; 27 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From ayang at openjdk.org Thu Oct 16 09:35:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 16 Oct 2025 09:35:34 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded Message-ID: Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. The failure rate is ~60% before the fix and no failure for 2000 runs. Test: tier1-5 ------------- Commit messages: - test-unload Changes: https://git.openjdk.org/jdk/pull/27840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342659 Stats: 42 lines in 2 files changed: 8 ins; 27 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27840/head:pull/27840 PR: https://git.openjdk.org/jdk/pull/27840 From jsjolen at openjdk.org Thu Oct 16 11:12:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 11:12:09 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v14] In-Reply-To: References: Message-ID: <39QL__6wNYwCha-HI44BrDRZyv7EipvJ2pejbycA6hY=.4b658989-3579-4d3e-9544-7fa90276958c@github.com> On Thu, 16 Oct 2025 09:31:41 GMT, Afshin Zafari wrote: >> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. >> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > AHP -> sanitizers/address.hpp Hi Afshin, please have a look at this change set: https://github.com/jdksjolen/jdk/commit/3688d28b52eda05a39c4c1881932db85b09ce168 - I use `aph` instead of `_temp`, this is the typical naming style in Hotspot for RAII-objects which are solely for temporarily altering state. - I use Class template argument deduction (CTAD) to not have to specify the types. Unfortunately, we can't do this for the static method calls - I remove the `using` types. we might want to have that back in, but it should be used consistently over all of the code. The original use case (setting them to void when ASAN isn't present) is no longer valid, so I removed them. - I separated out the poisoning method into both `poison` and `unpoison` variants instead of using a boolean, and I also mention `asan` in the name. This is to be extra clear that this is code is only relevant for asan, and also avoids having the user understand a boolean. I also made it private, as it's only used internally now - I made the input args to the helper `const T*`, as we never plan to actually touch the memory. This is consistent with the ASAN API function prototype: `void __asan_poison_memory_region(void const volatile *addr, size_t size);` Please consider taking this as a patch, it should apply cleanly to commit [c644a84](https://github.com/openjdk/jdk/pull/27685/commits/c644a84a4377d984c66bf9168f8cb4c115a8e13d) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3410347790 From coleenp at openjdk.org Thu Oct 16 11:53:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 16 Oct 2025 11:53:04 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <3S6JMRc3hErT5I2Ym0kh93Qog5JexAdsszEwV1k6Vs8=.5602a410-97a1-4650-b2b3-8844da4d7a88@github.com> Message-ID: On Thu, 16 Oct 2025 07:52:23 GMT, Johan Sj?len wrote: >> I tried making RecursiveLock a template but it's sort of a pain. > > It is basically a copy. The reason I went the longer (lines of code-wise) is because I'd prefer it if we didn't spread this implementation around, so having this handmade one in `arena.cpp` seems like an acceptable trade-off to having the RecursiveLock being templated and so on. I agree with this. Templating RecursiveLock is pretty horrible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2435607768 From ayang at openjdk.org Thu Oct 16 12:23:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 16 Oct 2025 12:23:28 GMT Subject: RFR: 8369983: Remove expired ZGC flags for JDK 26 In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 08:44:04 GMT, Joel Sikstr?m wrote: > Hello, > > The ZGenerational flag was obsoleted in JDK 24 as part of removing the non-generational mode of ZGC in JEP 490. The flag was still obsolete in JDK 25, which is a LTS version, so that user's that might specify/try to use it are prompted with a warning. Now that we're past JDK 25, the flag should be expired. Likewise, the ZMarkStackSpaceLimit flag was obsoleted in JDK 25 and can now be expired in JDK 26. > > Since neither of these flags were documented in `java.md` I haven't added them to the "Removed Java Options" section in that file. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27838#pullrequestreview-3344559499 From ysuenaga at openjdk.org Thu Oct 16 12:48:37 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 16 Oct 2025 12:48:37 GMT Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11] In-Reply-To: References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga wrote: >> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: >> >> >> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> And also I got following (strange) stacks which causes `AssersionFailure` in above: >> >> >> ----------------- 70094 ----------------- >> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_native >> 0x00007f8f64658462 __syscall_cancel_arch + 0x32 >> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c >> 0x00007f8f646a8c37 __GI___nanosleep + 0x17 >> 0x00007f8f646bb14e __sleep + 0x3e >> 0x00007f8f4b3a8e1e >> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Cosmetic change Thanks everyone for involving this PR! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3410726254 From ysuenaga at openjdk.org Thu Oct 16 12:48:39 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 16 Oct 2025 12:48:39 GMT Subject: Integrated: 8369505: jhsdb jstack cannot handle continuation stub In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com> Message-ID: On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga wrote: > I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message: > > > sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > > > And also I got following (strange) stacks which causes `AssersionFailure` in above: > > > ----------------- 70094 ----------------- > "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_native > 0x00007f8f64658462 __syscall_cancel_arch + 0x32 > 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c > 0x00007f8f646a8c37 __GI___nanosleep + 0x17 > 0x00007f8f646bb14e __sleep + 0x3e > 0x00007f8f4b3a8e1e > 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame) > 0x00007f8f4b33fe48... This pull request has now been integrated. Changeset: 16539998 Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/1653999871c8d7b1e61b44f8525e09b2cd0bdb6b Stats: 297 lines in 10 files changed: 293 ins; 0 del; 4 mod 8369505: jhsdb jstack cannot handle continuation stub Reviewed-by: cjplummer, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/27728 From jsjolen at openjdk.org Thu Oct 16 13:21:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Oct 2025 13:21:41 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3] In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: > The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. > > This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. > > Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Revert access modifier style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27759/files - new: https://git.openjdk.org/jdk/pull/27759/files/4fb0bae1..93e796cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27759&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27759&range=01-02 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27759/head:pull/27759 PR: https://git.openjdk.org/jdk/pull/27759 From mbaesken at openjdk.org Thu Oct 16 14:05:03 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Oct 2025 14:05:03 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 03:41:05 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Make EnhanceErrorWarningLogging DIAGNOSTIC > > We already have some UL in PerfMemory: >> 8168122: Update logging in perfMemory to Unified Logging > Summary: -XX:+PerfTraceMemOps replaced with -Xlog:perf+memops=debug, -XX:+PerfTraceDataCreation replaced with -Xlog:perf+datacreation=debug > > but for some reason that effort completely ignored the PrintMiscellaneous/Verbose "warnings". To keep things simple I suggest the following pattern: > > diff --git a/src/hotspot/os/posix/perfMemory_posix.cpp b/src/hotspot/os/posix/perfMemory_posix.cpp > index ed83487265c..968f3cea249 100644 > --- a/src/hotspot/os/posix/perfMemory_posix.cpp > +++ b/src/hotspot/os/posix/perfMemory_posix.cpp > @@ -447,10 +447,11 @@ static char* get_user_name(uid_t uid) { > int result = getpwuid_r(uid, &pwent, pwbuf, (size_t)bufsize, &p); > > if (result != 0 || p == nullptr || p->pw_name == nullptr || *(p->pw_name) == '\0') { > - if (PrintMiscellaneous && Verbose) { > + if (log_is_enabled(Debug, perf)) { > + LogStreamHandle(Debug, perf) log; > if (result != 0) { > - warning("Could not retrieve passwd entry: %s\n", > - os::strerror(result)); > + log.print_cr("Could not retrieve passwd entry: %s", > + os::strerror(result)); > } > else if (p == nullptr) { > // this check is added to protect against an observed problem > @@ -463,13 +464,13 @@ static char* get_user_name(uid_t uid) { > // message may result in an erroneous message. > // Bug Id 89052 was opened with RedHat. > // > - warning("Could not retrieve passwd entry: %s\n", > - os::strerror(errno)); > + log.print_cr("Could not retrieve passwd entry: %s", > + os::strerror(errno)); > } > else { > - warning("Could not determine user name: %s\n", > - p->pw_name == nullptr ? "pw_name = null" : > - "pw_name zero length"); > + log.print_cr("Could not determine user name: %s", > + p->pw_name == nullptr ? "pw_name = null" : > + "pw_name zero length"); > } > } > FREE_C_HEAP_ARRAY(char, pwbuf); > > Of course you proposed changes as a potential consumer of this information, so how would you like to procure it? @dholmes-ora while looking into the Windows perfmem code, I noticed we are using SetSecurityDescriptorControl https://github.com/openjdk/jdk/blob/1653999871c8d7b1e61b44f8525e09b2cd0bdb6b/src/hotspot/os/windows/perfMemory_windows.cpp#L1016 but we use still handling for ancient Windows versions (we use dynamic handling of the function at runtime), should we remove this ? Looking at the description https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol it is available at least since Win2003/XP so the function can be called directly (would do this in a separate JBS issue). What do you think ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3411049767 From mbaesken at openjdk.org Thu Oct 16 14:56:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Oct 2025 14:56:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v3] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust perf logging, remove EnhanceErrorWarningLogging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/0ce49518..1ca30a1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=01-02 Stats: 233 lines in 4 files changed: 61 ins; 10 del; 162 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From mbaesken at openjdk.org Thu Oct 16 15:52:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Oct 2025 15:52:35 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 14:56:04 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust perf logging, remove EnhanceErrorWarningLogging Do we need to include more? It seems not to work in e.g. the zero of minimal builds ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3411539374 From kbarrett at openjdk.org Thu Oct 16 16:12:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 16 Oct 2025 16:12:59 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Wed, 15 Oct 2025 01:27:37 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DeferredStatic per Kim's request src/hotspot/os/posix/signals_posix.cpp line 173: > 171: static DeferredStatic sr_semaphore; > 172: #else > 173: static DeferredStatic sr_semaphore; [pre-existing] Oh, ick. Please remove the indentation for the definitions of sr_semaphore. In the context of this diff I thought these were declarations at class scope, and was quite confused because I couldn't find a definition. Nope, these are at file scope, and *are* definitions. (This might be what is confusing @stefank about how they are/were being constructed.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2436605887 From kbarrett at openjdk.org Thu Oct 16 16:13:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 16 Oct 2025 16:13:01 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: <_MCcka1pfmFxc75l6VikDBdyX2flNBZof-5FEZMTBFI=.c77c1a53-3cfa-4ee2-bb1a-51bd8a997288@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> <_MCcka1pfmFxc75l6VikDBdyX2flNBZof-5FEZMTBFI=.c77c1a53-3cfa-4ee2-bb1a-51bd8a997288@github.com> Message-ID: On Wed, 15 Oct 2025 12:24:04 GMT, David Holmes wrote: >> src/hotspot/os/posix/signals_posix.cpp line 356: >> >>> 354: // Initialize signal semaphore >>> 355: int sem_count = 0; >>> 356: sig_semaphore.initialize(sem_count); >> >> Just `sig_semaphore.initialize();` should be work. And the variable declaration looks kind of odd in context. > > I was not sure how the "magic" of initialization worked in this case with default constructor arguments - plus I wanted to be explicit about the initial count. Unfortunately the template requires a reference hence the local was introduced - if there is a better way to do this please advise me. There is a better way. `initialize` should use perfect forwarding. Sigh. OK, leave it as is. It can be fixed later, once we allow perfect forwarding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2436590698 From darcy at openjdk.org Thu Oct 16 16:41:27 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 16 Oct 2025 16:41:27 GMT Subject: Integrated: 8369858: Remove darcy author tags from jdk tests In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 04:37:50 GMT, Joe Darcy wrote: > Updating tests I've wrote to conform to current conventions of not having author tags. This pull request has now been integrated. Changeset: 7e032409 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/7e03240974cd66c471f5d02e14fd77971fe6d173 Stats: 130 lines in 63 files changed: 0 ins; 67 del; 63 mod 8369858: Remove darcy author tags from jdk tests Reviewed-by: rriggs, iris, lancea ------------- PR: https://git.openjdk.org/jdk/pull/27813 From cjplummer at openjdk.org Thu Oct 16 16:43:16 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 16 Oct 2025 16:43:16 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:25:42 GMT, Albert Mingkun Yang wrote: > Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. > > The failure rate is ~60% before the fix and no failure for 2000 runs. > > Test: tier1-5 test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 250: > 248: > 249: // free references to class and class loader to be able for collecting by GC > 250: long waitTimeout = (customClassLoader == null) ? 0 : WAIT_TIMEOUT; waitTimeout is no longer needed. You can also remove WAIT_TIMEOUT and WAIT_DELTA. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2436689604 From cjplummer at openjdk.org Thu Oct 16 16:50:50 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 16 Oct 2025 16:50:50 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 16:40:38 GMT, Chris Plummer wrote: >> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. >> >> The failure rate is ~60% before the fix and no failure for 2000 runs. >> >> Test: tier1-5 > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 250: > >> 248: >> 249: // free references to class and class loader to be able for collecting by GC >> 250: long waitTimeout = (customClassLoader == null) ? 0 : WAIT_TIMEOUT; > > waitTimeout is no longer needed. You can also remove WAIT_TIMEOUT and WAIT_DELTA. Sorry, looks like I misread the diff and waitTimeout was already removed. WAIT_TIMEOUT and WAIT_DELTA still need removing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2436707826 From stefank at openjdk.org Thu Oct 16 17:52:50 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 16 Oct 2025 17:52:50 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Thu, 16 Oct 2025 16:09:27 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to DeferredStatic per Kim's request > > src/hotspot/os/posix/signals_posix.cpp line 173: > >> 171: static DeferredStatic sr_semaphore; >> 172: #else >> 173: static DeferredStatic sr_semaphore; > > [pre-existing] Oh, ick. Please remove the indentation for the definitions of sr_semaphore. In the context of this diff I thought these were declarations at class scope, and was quite confused because I couldn't find a definition. Nope, these are at file scope, and *are* definitions. (This might be what is confusing @stefank about how they are/were being constructed.) Ahh. Thanks for solving that conundrum. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2436914930 From matsaave at openjdk.org Thu Oct 16 19:29:13 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 16 Oct 2025 19:29:13 GMT Subject: RFR: 8369856: AOT map does not include unregistered classes In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 16:56:37 GMT, Ioi Lam wrote: > Thanks to @ashu-mehra for providing the fix! > > I also updated the test cases: > > - Use a custom class loader to load unregistered classes > - Check that all classes loaded from the AOT cache have an entry in the map file > - Rename "CDS" to "AOT" Change looks good! Seeing that we're moving class and file names from CDS to AOT, should the directory eventually be changed to aot as well? ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27828#pullrequestreview-3346663345 From azafari at openjdk.org Thu Oct 16 19:53:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 16 Oct 2025 19:53:57 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v4] In-Reply-To: References: Message-ID: > On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: - copyright year of new file - new JTReg test added. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27764/files - new: https://git.openjdk.org/jdk/pull/27764/files/e4957bd0..fd333d3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=02-03 Stats: 166 lines in 2 files changed: 166 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27764/head:pull/27764 PR: https://git.openjdk.org/jdk/pull/27764 From ayang at openjdk.org Thu Oct 16 20:09:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 16 Oct 2025 20:09:19 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: > Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. > > The failure rate is ~60% before the fix and no failure for 2000 runs. > > Test: tier1-5 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 four additional commits since the last revision: - Merge branch 'master' into test-unload - copyright - review - test-unload ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27840/files - new: https://git.openjdk.org/jdk/pull/27840/files/36004136..49720706 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27840&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27840&range=00-01 Stats: 2242 lines in 139 files changed: 1027 ins; 654 del; 561 mod Patch: https://git.openjdk.org/jdk/pull/27840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27840/head:pull/27840 PR: https://git.openjdk.org/jdk/pull/27840 From cjplummer at openjdk.org Thu Oct 16 20:09:20 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 16 Oct 2025 20:09:20 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 20:05:58 GMT, Albert Mingkun Yang wrote: >> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. >> >> The failure rate is ~60% before the fix and no failure for 2000 runs. >> >> Test: tier1-5 > > 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 four additional commits since the last revision: > > - Merge branch 'master' into test-unload > - copyright > - review > - test-unload The changes look good. Copyrights need updating. Thanks for providing the fix for this! ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3346819019 From fandreuzzi at openjdk.org Thu Oct 16 22:07:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 16 Oct 2025 22:07:19 GMT Subject: Integrated: 8369734: JvmtiExport::post_class_file_load_hook return value is never used In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi wrote: > The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code. > > Passes tier1 and tier2 (fastdebug). This pull request has now been integrated. Changeset: 0bdd6f06 Author: Francesco Andreuzzi Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/0bdd6f0640fc25667f911228eed6a0fa118e8ff8 Stats: 12 lines in 2 files changed: 0 ins; 7 del; 5 mod 8369734: JvmtiExport::post_class_file_load_hook return value is never used Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/27777 From sspitsyn at openjdk.org Thu Oct 16 22:25:04 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 16 Oct 2025 22:25:04 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang wrote: >> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. >> >> The failure rate is ~60% before the fix and no failure for 2000 runs. >> >> Test: tier1-5 > > 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 four additional commits since the last revision: > > - Merge branch 'master' into test-unload > - copyright > - review > - test-unload Looks okay to me but I've posted a question. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251: > 249: > 250: // force GC to unload marked class loader and its classes > 251: if (isClassLoaderReclaimed()) { Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed. How does this work now with the `isClassLoaderReclaimed()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3347195845 PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437598897 From pchilanomate at openjdk.org Thu Oct 16 22:48:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 16 Oct 2025 22:48:29 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait Message-ID: If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. Testing in mach5 tiers1-5. Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/27856/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27856&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369944 Stats: 12 lines in 2 files changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27856/head:pull/27856 PR: https://git.openjdk.org/jdk/pull/27856 From cjplummer at openjdk.org Thu Oct 16 22:56:05 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 16 Oct 2025 22:56:05 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com> On Thu, 16 Oct 2025 22:21:19 GMT, Serguei Spitsyn wrote: >> 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 four additional commits since the last revision: >> >> - Merge branch 'master' into test-unload >> - copyright >> - review >> - test-unload > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251: > >> 249: >> 250: // force GC to unload marked class loader and its classes >> 251: if (isClassLoaderReclaimed()) { > > Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed. > How does this work now with the `isClassLoaderReclaimed()`? The previous approach relied on an async notification by the Cleaner thread that the class had been gc'd, so some waiting was needed (but probably not 15 seconds). There were also bugs in this support. unloadClass() is first called by the test to make sure that the class **does not** unload due to an intentional reference. This first call sets customClassLoader to null. That means when later unloadClass() is used again to this time make sure the class unloads, there will be no waiting, because for some reason unloadClass() chose to set waitingTime to 0 when customClassLoader is null. This meant that often unloadClass() would exit before the unloading completed. This is probably why the caller used to try up to 5 times. That left a race condition with the setting of is_reclaimed. It could be set sometime after unloadClass() finished and before it was entered again, but upon entry is_reclaimed is always set to false, and it will never be set true again after that. Thus the test thinks the class never unloaded even though it did. There are other ways to fix this issue (mainly always wait for 15 seconds and make sure unloadClass() always works on the first try). However, Albert's PhantomReference approach is a cleaner implementation and no longer relies waiting for some async process to complete the unloading of the class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437639816 From sspitsyn at openjdk.org Thu Oct 16 23:11:05 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 16 Oct 2025 23:11:05 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang wrote: >> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. >> >> The failure rate is ~60% before the fix and no failure for 2000 runs. >> >> Test: tier1-5 > > 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 four additional commits since the last revision: > > - Merge branch 'master' into test-unload > - copyright > - review > - test-unload Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3347280549 From sspitsyn at openjdk.org Thu Oct 16 23:11:07 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 16 Oct 2025 23:11:07 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com> References: <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com> Message-ID: On Thu, 16 Oct 2025 22:53:00 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251: >> >>> 249: >>> 250: // force GC to unload marked class loader and its classes >>> 251: if (isClassLoaderReclaimed()) { >> >> Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed. >> How does this work now with the `isClassLoaderReclaimed()`? > > The previous approach relied on an async notification by the Cleaner thread that the class had been gc'd, so some waiting was needed (but probably not 15 seconds). There were also bugs in this support. unloadClass() is first called by the test to make sure that the class **does not** unload due to an intentional reference. This first call sets customClassLoader to null. That means when later unloadClass() is used again to this time make sure the class unloads, there will be no waiting, because for some reason unloadClass() chose to set waitingTime to 0 when customClassLoader is null. This meant that often unloadClass() would exit before the unloading completed. This is probably why the caller used to try up to 5 times. That left a race condition with the setting of is_reclaimed. It could be set sometime after unloadClass() finished and before it was entered again, but upon entry is_reclaimed is always set to false, and it will never be set true again after that. Thus the test thin ks the class never unloaded even though it did. > > There are other ways to fix this issue (mainly always wait for 15 seconds and make sure unloadClass() always works on the first try). However, Albert's PhantomReference approach is a cleaner implementation and no longer relies waiting for some async process to complete the unloading of the class. Okay. Thank you, Chris. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437679608 From wkemper at openjdk.org Thu Oct 16 23:52:15 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 16 Oct 2025 23:52:15 GMT Subject: RFR: 8370050: Shenandoah: Obsolete ShenandoahPacing option Message-ID: ShenandoahPacing was removed in this release (26). Rather than have the JVM refuse to start if this option is given, it should give a warning that the option is removed and is ignored and will reject the option in JDK27. Testing: [0] % ./build/linux-x86_64-server-release/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahPacing --version OpenJDK 64-Bit Server VM warning: Ignoring option ShenandoahPacing; support was removed in 26.0 ------------- Commit messages: - Obsolete ShenandoahPacing option in 26 (pacing was removed in 26) Changes: https://git.openjdk.org/jdk/pull/27859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370050 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27859.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27859/head:pull/27859 PR: https://git.openjdk.org/jdk/pull/27859 From ysr at openjdk.org Fri Oct 17 00:10:03 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Fri, 17 Oct 2025 00:10:03 GMT Subject: RFR: 8370050: Shenandoah: Obsolete ShenandoahPacing option In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:46:23 GMT, William Kemper wrote: > ShenandoahPacing was removed in this release (26). Rather than have the JVM refuse to start if this option is given, it should give a warning that the option is removed and is ignored and will reject the option in JDK27. > > Testing: > > [0] % ./build/linux-x86_64-server-release/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahPacing --version > OpenJDK 64-Bit Server VM warning: Ignoring option ShenandoahPacing; support was removed in 26.0 Thank you for cleaning up _mea culpa_. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27859#pullrequestreview-3347485969 From wkemper at openjdk.org Fri Oct 17 00:18:10 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 17 Oct 2025 00:18:10 GMT Subject: Integrated: 8370050: Shenandoah: Obsolete ShenandoahPacing option In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:46:23 GMT, William Kemper wrote: > ShenandoahPacing was removed in this release (26). Rather than have the JVM refuse to start if this option is given, it should give a warning that the option is removed and is ignored and will reject the option in JDK27. > > Testing: > > [0] % ./build/linux-x86_64-server-release/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahPacing --version > OpenJDK 64-Bit Server VM warning: Ignoring option ShenandoahPacing; support was removed in 26.0 This pull request has now been integrated. Changeset: 4d20f769 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/4d20f7696c015bc0e59544ff064fe0c640d61edf Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8370050: Shenandoah: Obsolete ShenandoahPacing option Reviewed-by: ysr ------------- PR: https://git.openjdk.org/jdk/pull/27859 From iklam at openjdk.org Fri Oct 17 00:41:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 17 Oct 2025 00:41:23 GMT Subject: Integrated: 8369856: AOT map does not include unregistered classes In-Reply-To: References: Message-ID: <8OmJgsS2DIOedx5PsFsu68RNqs-g2-LBFcapNldHnxw=.2159cfdb-f46e-4c90-a9c3-6cf022d93255@github.com> On Wed, 15 Oct 2025 16:56:37 GMT, Ioi Lam wrote: > Thanks to @ashu-mehra for providing the fix! > > I also updated the test cases: > > - Use a custom class loader to load unregistered classes > - Check that all classes loaded from the AOT cache have an entry in the map file > - Rename "CDS" to "AOT" This pull request has now been integrated. Changeset: bd731564 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/bd7315648f2bb18cba9cfbeca00e6132b8eb95ef Stats: 814 lines in 5 files changed: 443 ins; 351 del; 20 mod 8369856: AOT map does not include unregistered classes Co-authored-by: Ashutosh Mehra Reviewed-by: kvn, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/27828 From iklam at openjdk.org Fri Oct 17 00:41:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 17 Oct 2025 00:41:21 GMT Subject: RFR: 8369856: AOT map does not include unregistered classes In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 19:26:23 GMT, Matias Saavedra Silva wrote: >> Thanks to @ashu-mehra for providing the fix! >> >> I also updated the test cases: >> >> - Use a custom class loader to load unregistered classes >> - Check that all classes loaded from the AOT cache have an entry in the map file >> - Rename "CDS" to "AOT" > > Change looks good! Seeing that we're moving class and file names from CDS to AOT, should the directory eventually be changed to aot as well? Thanks @matias9927 @vnkozlov for the review > Change looks good! Seeing that we're moving class and file names from CDS to AOT, should the directory eventually be changed to aot as well? Yes, that's the plan but it's kind of low priority now. I hope to do more refactoring of both the code and tests after JEP 516 (https://github.com/openjdk/jdk/pull/27732/) is integrate, to avoid creating conflicts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27828#issuecomment-3413367852 PR Comment: https://git.openjdk.org/jdk/pull/27828#issuecomment-3413372070 From dholmes at openjdk.org Fri Oct 17 02:13:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 02:13:01 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 14:02:08 GMT, Matthias Baesken wrote: > would do this in a separate JBS issue Yes please file a separate JBS issue for that ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3413510399 From dholmes at openjdk.org Fri Oct 17 02:20:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 02:20:06 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 14:56:04 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust perf logging, remove EnhanceErrorWarningLogging You need to include: #include "logging/logStream.hpp" to get `LogStream`. But note that simple cases don't need to use `LogStream`. I gave that example for the more complex cases. Thanks src/hotspot/os/posix/perfMemory_posix.cpp line 76: > 74: if (log_is_enabled(Debug, perf)) { > 75: LogStreamHandle(Debug, perf) log; > 76: log.print_cr("Could not commit PerfData memory\n"); For simple usages like this you can simplify. Suggestion: log_debug(perf)("Could not commit PerfData memory"); also note to get rid of the explicit `\n` in the strings. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3347717174 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2438031597 From dholmes at openjdk.org Fri Oct 17 02:37:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 02:37:52 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v3] In-Reply-To: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: > Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. > > Testing: > - tiers 1-3 sanity > > Thanks. David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Fix misleading indent. - Merge branch 'master' into 8369631-sr_sem - Switch to DeferredStatic per Kim's request - 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27762/files - new: https://git.openjdk.org/jdk/pull/27762/files/a8982e70..d200692a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27762&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27762&range=01-02 Stats: 9608 lines in 240 files changed: 5571 ins; 3533 del; 504 mod Patch: https://git.openjdk.org/jdk/pull/27762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27762/head:pull/27762 PR: https://git.openjdk.org/jdk/pull/27762 From dholmes at openjdk.org Fri Oct 17 02:37:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 02:37:54 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v2] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: <2rBCyZPTFZasYxrbqvRJrK6rg377lcExrMbYJC-osXw=.818f2776-ac05-4c25-8f5d-2a8dec50b45b@github.com> On Thu, 16 Oct 2025 17:50:04 GMT, Stefan Karlsson wrote: >> src/hotspot/os/posix/signals_posix.cpp line 173: >> >>> 171: static DeferredStatic sr_semaphore; >>> 172: #else >>> 173: static DeferredStatic sr_semaphore; >> >> [pre-existing] Oh, ick. Please remove the indentation for the definitions of sr_semaphore. In the context of this diff I thought these were declarations at class scope, and was quite confused because I couldn't find a definition. Nope, these are at file scope, and *are* definitions. (This might be what is confusing @stefank about how they are/were being constructed.) > > Ahh. Thanks for solving that conundrum. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27762#discussion_r2438052402 From dholmes at openjdk.org Fri Oct 17 02:41:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 02:41:00 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 22:03:51 GMT, Patricio Chilano Mateo wrote: > This could have been a timed-wait that timed-out, and only after that, the thread was interrupted This is a feature not a bug. It is preferable to return via IE if the interrupt was detected, even if we originally timed-out of the wait itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27856#issuecomment-3413552915 From dholmes at openjdk.org Fri Oct 17 03:09:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 03:09:02 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 22:03:51 GMT, Patricio Chilano Mateo wrote: > If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. > This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: > > `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` > > There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. > Testing in mach5 tiers1-5. > > Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). > > Thanks, > Patricio Great find - but now I find myself second guessing a lot of the code I thought I understood. src/hotspot/share/runtime/objectMonitor.cpp line 1885: > 1883: if (interrupted || HAS_PENDING_EXCEPTION) { > 1884: // Intentionally empty > 1885: } else if (node.TState == ObjectWaiter::TS_WAIT) { I must have misread the code previously, as I thought this was read under the wait_set_lock, but it isn't. So what stops us from seeing a stale TS_WAIT here and continuing with the park even though we were already notified? I'm assuming the implicit barriers in the TBIVMP? Or is it much more subtle than that, and the successor protocol will unpark us once the monitor could be available? src/hotspot/share/runtime/objectMonitor.cpp line 1925: > 1923: OrderAccess::loadload(); > 1924: if (has_successor(current)) clear_successor(); > 1925: WasNotified = node.TState == ObjectWaiter::TS_ENTER; We don't really need the `WasNotified` local any more as it is only used once below (which saves me from asking you to rename it `was_notified`.) src/hotspot/share/runtime/objectMonitor.hpp line 70: > 68: bool is_wait() const { return _is_wait; } > 69: bool at_reenter() const { return _at_reenter; } > 70: bool at_monitorenter() const { return !_is_wait || TState != TS_WAIT; } Why did we drop the check of `_at_reenter` here? ------------- PR Review: https://git.openjdk.org/jdk/pull/27856#pullrequestreview-3347757143 PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2438090869 PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2438072112 PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2438064864 From dholmes at openjdk.org Fri Oct 17 03:13:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 03:13:00 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 02:53:26 GMT, David Holmes wrote: >> If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. >> This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: >> >> `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` >> >> There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. >> Testing in mach5 tiers1-5. >> >> Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/objectMonitor.cpp line 1885: > >> 1883: if (interrupted || HAS_PENDING_EXCEPTION) { >> 1884: // Intentionally empty >> 1885: } else if (node.TState == ObjectWaiter::TS_WAIT) { > > I must have misread the code previously, as I thought this was read under the wait_set_lock, but it isn't. So what stops us from seeing a stale TS_WAIT here and continuing with the park even though we were already notified? I'm assuming the implicit barriers in the TBIVMP? Or is it much more subtle than that, and the successor protocol will unpark us once the monitor could be available? I think it is the latter. We could read a stale TState value no matter what, as it may have only just been set before we read it. But not seeing TS_WAIT is just an optimisation to skip the park. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2438143384 From kbarrett at openjdk.org Fri Oct 17 04:21:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 17 Oct 2025 04:21:03 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v3] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Fri, 17 Oct 2025 02:37:52 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Fix misleading indent. > - Merge branch 'master' into 8369631-sr_sem > - Switch to DeferredStatic per Kim's request > - 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27762#pullrequestreview-3348200889 From dholmes at openjdk.org Fri Oct 17 04:40:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Oct 2025 04:40:10 GMT Subject: RFR: 8370050: Shenandoah: Obsolete ShenandoahPacing option In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 23:46:23 GMT, William Kemper wrote: > ShenandoahPacing was removed in this release (26). Rather than have the JVM refuse to start if this option is given, it should give a warning that the option is removed and is ignored and will reject the option in JDK27. > > Testing: > > [0] % ./build/linux-x86_64-server-release/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahPacing --version > OpenJDK 64-Bit Server VM warning: Ignoring option ShenandoahPacing; support was removed in 26.0 src/hotspot/share/runtime/arguments.cpp line 551: > 549: { "ZMarkStackSpaceLimit", JDK_Version::undefined(), JDK_Version::jdk(25), JDK_Version::undefined() }, > 550: { "G1UpdateBufferSize", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > 551: { "ShenandoahPacing", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) }, Nit: you didn't actually deprecate the option in 25 so this should have been left as `undefined()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27859#discussion_r2438349801 From stefank at openjdk.org Fri Oct 17 06:24:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 17 Oct 2025 06:24:02 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v3] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Fri, 17 Oct 2025 02:37:52 GMT, David Holmes wrote: >> Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Fix misleading indent. > - Merge branch 'master' into 8369631-sr_sem > - Switch to DeferredStatic per Kim's request > - 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27762#pullrequestreview-3348479828 From jsjolen at openjdk.org Fri Oct 17 08:04:12 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 17 Oct 2025 08:04:12 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v4] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 19:53:57 GMT, Afshin Zafari wrote: >> On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. > > Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: > > - copyright year of new file > - new JTReg test added. Thank you! This looks good. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27764#pullrequestreview-3348765837 From mbaesken at openjdk.org Fri Oct 17 08:05:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Oct 2025 08:05:22 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 02:10:13 GMT, David Holmes wrote: > > would do this in a separate JBS issue > > Yes please file a separate JBS issue for that I created https://bugs.openjdk.org/browse/JDK-8370065 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3414316281 From mbaesken at openjdk.org Fri Oct 17 08:20:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Oct 2025 08:20:59 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v4] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Include logging/logStream.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/1ca30a1a..72d257c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=02-03 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From jsjolen at openjdk.org Fri Oct 17 08:35:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 17 Oct 2025 08:35:03 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Thu, 16 Oct 2025 13:21:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Revert access modifier style Here's a sketch of Stefan's suggestion, maybe we should go for that instead? I'm vacationing for 2 weeks, so if someone can take over the PR then that'd be highly appreciated. https://github.com/jdksjolen/jdk/commit/80f58d3979b8d9e99a4caeb21935edbcbff4c7ac ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3414425419 From coffeys at openjdk.org Fri Oct 17 08:58:46 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 08:58:46 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message Message-ID: Simple tweak to jcmd Thread.print help message jdk_svc test group ran and green ------------- Commit messages: - 8370071 Changes: https://git.openjdk.org/jdk/pull/27861/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370071 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27861/head:pull/27861 PR: https://git.openjdk.org/jdk/pull/27861 From ayang at openjdk.org Fri Oct 17 09:05:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 17 Oct 2025 09:05:21 GMT Subject: RFR: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang wrote: >> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. >> >> The failure rate is ~60% before the fix and no failure for 2000 runs. >> >> Test: tier1-5 > > 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 four additional commits since the last revision: > > - Merge branch 'master' into test-unload > - copyright > - review > - test-unload Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27840#issuecomment-3414524556 From ayang at openjdk.org Fri Oct 17 09:05:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 17 Oct 2025 09:05:22 GMT Subject: Integrated: 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:25:42 GMT, Albert Mingkun Yang wrote: > Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow. > > The failure rate is ~60% before the fix and no failure for 2000 runs. > > Test: tier1-5 This pull request has now been integrated. Changeset: e62a7fa3 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/e62a7fa3832bbba11e6d630015f85ae945fac824 Stats: 54 lines in 2 files changed: 8 ins; 37 del; 9 mod 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded Co-authored-by: Chris Plummer Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/27840 From coffeys at openjdk.org Fri Oct 17 09:08:26 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 09:08:26 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey wrote: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green Any issues if I add this sentence to the help output ? ?Use Thread.dump_to_file command for extended threads detail including virtual thread information." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414538711 From kevinw at openjdk.org Fri Oct 17 09:23:04 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 17 Oct 2025 09:23:04 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message In-Reply-To: References: Message-ID: <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com> On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey wrote: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green Good idea, this could be clearer. If you want to expand this: Elsewhere for ThreadDumpToFileDCmd we say: "Dump threads, with stack traces, to a file in plain text or JSON format." We could add on: "Includes virtual threads." or add in that fact somehow. There's also a man page ./src/jdk.jcmd/share/man/jcmd.md where we have the same text for both commands. 8-) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27861#pullrequestreview-3349068624 From alanb at openjdk.org Fri Oct 17 09:34:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 17 Oct 2025 09:34:07 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey wrote: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green src/hotspot/share/services/diagnosticCommand.hpp line 359: > 357: static const char* name() { return "Thread.print"; } > 358: static const char* description() { > 359: return "Print all platform threads with stacktraces."; The Thread.print section of the jcmd man page can be updated to align with the update description. If there is space, then it include "all mounted virtual threads". (Note that there was a previous attempt to change this description when the Thread.print was updated to include mounted virtual threads. At the time, the PR feedback was to separate it to a different PR but there wasn't any follow-up on that so good to see it re-visited here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439015833 From coffeys at openjdk.org Fri Oct 17 10:05:39 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 10:05:39 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: References: Message-ID: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: man page and better help messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27861/files - new: https://git.openjdk.org/jdk/pull/27861/files/b7c0a1ba..4d2e42aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27861&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27861&range=00-01 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27861/head:pull/27861 PR: https://git.openjdk.org/jdk/pull/27861 From coffeys at openjdk.org Fri Oct 17 10:05:41 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 10:05:41 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com> References: <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com> Message-ID: On Fri, 17 Oct 2025 09:20:17 GMT, Kevin Walls wrote: > Good idea, this could be clearer. > > If you want to expand this: Elsewhere for ThreadDumpToFileDCmd we say: "Dump threads, with stack traces, to a file in plain text or JSON format." We could add on: "Includes virtual threads." or add in that fact somehow. > > There's also a man page ./src/jdk.jcmd/share/man/jcmd.md where we have the same text for both commands. 8-) Thanks for the man page reminder Kevin. I've added some extra help information also. I think it'll help guide users of these tools. PR updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414735179 From kevinw at openjdk.org Fri Oct 17 10:16:59 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 17 Oct 2025 10:16:59 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > man page and better help messages Saying "extended threads detail", or even "extended thread details" is a bit vague. It's not clear what Thread.print misses out, or if this will always be true. Could it be just: "Use Thread.dump_to_file for virtual thread information." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414789848 From alanb at openjdk.org Fri Oct 17 10:17:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 17 Oct 2025 10:17:02 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: References: Message-ID: <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com> On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > man page and better help messages src/hotspot/share/services/diagnosticCommand.hpp line 361: > 359: return "Print all platform threads with stacktraces. " > 360: "Use Thread.dump_to_file command for extended threads " > 361: "detail including virtual thread information."; Can you try "Print all platform threads, and mounted virtual threads, with stack traces"? Not sure about the second line. I assume you are proposing to add this in order to created awareness but saying "extended threads detail" is confusing. If a second line is added then it could be very simple, e.g. "The Thread.dump_to_file command will print all threads to a file". src/hotspot/share/services/diagnosticCommand.hpp line 773: > 771: } > 772: static const char *description() { > 773: return "Dump threads (including virtual), with stack traces, " If you change it to "Dump all threads" then it would be simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439162626 PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439140850 From coffeys at openjdk.org Fri Oct 17 10:25:39 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 10:25:39 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 10:12:12 GMT, Kevin Walls wrote: > Saying "extended threads detail", or even "extended thread details" is a bit vague. It's not clear what Thread.print misses out, or if this will always be true. Could it be just: "Use Thread.dump_to_file for virtual thread information." Yes - that's a fair point. The dump_to_file option also prints j.u.c Lock information for virtual theads. (hence extended) Thread.print prints details of a virtual thread if it's mounted. but yes, "Use Thread.dump_to_file for virtual thread information." sounds better. Maybe even ""Use Thread.dump_to_file for all thread information." based on Alan's comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414827799 From coffeys at openjdk.org Fri Oct 17 10:25:43 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 10:25:43 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com> References: <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com> Message-ID: On Fri, 17 Oct 2025 10:14:13 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> man page and better help messages > > src/hotspot/share/services/diagnosticCommand.hpp line 361: > >> 359: return "Print all platform threads with stacktraces. " >> 360: "Use Thread.dump_to_file command for extended threads " >> 361: "detail including virtual thread information."; > > Can you try "Print all platform threads, and mounted virtual threads, with stack traces"? > > Not sure about the second line. I assume you are proposing to add this in order to created awareness but saying "extended threads detail" is confusing. If a second line is added then it could be very simple, e.g. "The Thread.dump_to_file command will print all threads to a file". yes - nice to have the "mounted virtual threads" clarity. "The Thread.dump_to_file command will print all threads to a file". --> Will run with that. thanks. I think it's useful to hint at these commands when end users are reading such help messages. (e.g. "I want to print thread information but this command is telling me I only get platform + mounted threads.. what do I use for all threads etc.") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439203942 From kevinw at openjdk.org Fri Oct 17 10:31:10 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 17 Oct 2025 10:31:10 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > man page and better help messages By: "Use Thread.dump_to_file for all thread information." do we mean: "Use Thread.dump_to_file for information on all threads." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414868872 From coffeys at openjdk.org Fri Oct 17 11:11:19 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 17 Oct 2025 11:11:19 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3] In-Reply-To: References: Message-ID: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Further help message tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27861/files - new: https://git.openjdk.org/jdk/pull/27861/files/4d2e42aa..1d688320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27861&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27861&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27861/head:pull/27861 PR: https://git.openjdk.org/jdk/pull/27861 From kevinw at openjdk.org Fri Oct 17 11:15:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 17 Oct 2025 11:15:02 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Further help message tweaks Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27861#pullrequestreview-3349589749 From coleenp at openjdk.org Fri Oct 17 11:47:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Oct 2025 11:47:12 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: <7J8guHYl2UtqybisaKCKKshk-3iWj8PSBR2QumCRO2s=.cce440e1-a4cb-4588-8d43-faf79983d5d5@github.com> On Thu, 16 Oct 2025 13:21:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Revert access modifier style I like this last suggestion. I'll take it over for you while on vacation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3415174258 From mbaesken at openjdk.org Fri Oct 17 12:50:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Oct 2025 12:50:59 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v5] In-Reply-To: References: Message-ID: <7NG-bGMEVR4e5Uzz3s4VsNvzL2lbyCI2IXiup5VAtx4=.d65e6379-b612-45bf-b6f8-8ee296750bf2@github.com> > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust log calls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/72d257c3..30ca96b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=03-04 Stats: 154 lines in 3 files changed: 0 ins; 62 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From pchilanomate at openjdk.org Fri Oct 17 15:24:48 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Oct 2025 15:24:48 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: > If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. > This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: > > `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` > > There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. > Testing in mach5 tiers1-5. > > Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: rename to was_notified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27856/files - new: https://git.openjdk.org/jdk/pull/27856/files/d10c8f9e..9b9e0c69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27856&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27856&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27856/head:pull/27856 PR: https://git.openjdk.org/jdk/pull/27856 From pchilanomate at openjdk.org Fri Oct 17 15:24:50 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Oct 2025 15:24:50 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 02:38:13 GMT, David Holmes wrote: > > This could have been a timed-wait that timed-out, and only after that, the thread was interrupted > > This is a feature not a bug. It is preferable to return via IE if the interrupt was detected, even if we originally timed-out of the wait itself. > I see, I thought IE should be thrown only if the thread was removed from the wait set by the interruption. But I guess that?s just the mandatory case and this behavior is not ruled out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27856#issuecomment-3416024200 From pchilanomate at openjdk.org Fri Oct 17 15:26:54 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Oct 2025 15:26:54 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 03:10:52 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1885: >> >>> 1883: if (interrupted || HAS_PENDING_EXCEPTION) { >>> 1884: // Intentionally empty >>> 1885: } else if (node.TState == ObjectWaiter::TS_WAIT) { >> >> I must have misread the code previously, as I thought this was read under the wait_set_lock, but it isn't. So what stops us from seeing a stale TS_WAIT here and continuing with the park even though we were already notified? I'm assuming the implicit barriers in the TBIVMP? Or is it much more subtle than that, and the successor protocol will unpark us once the monitor could be available? > > I think it is the latter. We could read a stale TState value no matter what, as it may have only just been set before we read it. But not seeing TS_WAIT is just an optimisation to skip the park. Exactly. If the notifier already issued the unpark then the park permit will be set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2440379137 From pchilanomate at openjdk.org Fri Oct 17 15:26:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Oct 2025 15:26:58 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 02:45:59 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> rename to was_notified > > src/hotspot/share/runtime/objectMonitor.cpp line 1925: > >> 1923: OrderAccess::loadload(); >> 1924: if (has_successor(current)) clear_successor(); >> 1925: WasNotified = node.TState == ObjectWaiter::TS_ENTER; > > We don't really need the `WasNotified` local any more as it is only used once below (which saves me from asking you to rename it `was_notified`.) We also use it at the end when checking to throw IE, and by then the state is always `TS_RUN`. But I renamed it to `was_notified`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2440378334 From pchilanomate at openjdk.org Fri Oct 17 15:47:26 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Oct 2025 15:47:26 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 02:42:29 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> rename to was_notified > > src/hotspot/share/runtime/objectMonitor.hpp line 70: > >> 68: bool is_wait() const { return _is_wait; } >> 69: bool at_reenter() const { return _at_reenter; } >> 70: bool at_monitorenter() const { return !_is_wait || TState != TS_WAIT; } > > Why did we drop the check of `_at_reenter` here? It was redundant. If `_at_reenter` is true then it implies we are not in `TS_WAIT` anymore. We only need it for the virtual thread case to know if we need to call `vthread_wait_reenter()` when resuming the monitor operation (needs to be called always after the wait part is done). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2440432153 From sspitsyn at openjdk.org Fri Oct 17 20:11:15 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 17 Oct 2025 20:11:15 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack Message-ID: This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. Testing: - TBD: Run mach5 tiers 1-6 ------------- Commit messages: - 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack Changes: https://git.openjdk.org/jdk/pull/27878/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369609 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27878/head:pull/27878 PR: https://git.openjdk.org/jdk/pull/27878 From coleenp at openjdk.org Fri Oct 17 20:13:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Oct 2025 20:13:23 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling Message-ID: This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. Tested with tier1-4, tier5 on aarch64 (product and debug). ------------- Commit messages: - Fix compilation errors. - 8369622: GlobalChunkPoolMutex is recursively locked during error handling Changes: https://git.openjdk.org/jdk/pull/27869/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369622 Stats: 29 lines in 4 files changed: 19 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27869.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27869/head:pull/27869 PR: https://git.openjdk.org/jdk/pull/27869 From duke at openjdk.org Fri Oct 17 22:25:44 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Fri, 17 Oct 2025 22:25:44 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - add test showing loading symlinked libraries with various combinations - revert dll_load fix - Merge branch 'master' into nativelibraries-fix - add cast - use os::malloc - Merge branch 'master' into nativelibraries-fix - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - Merge remote-tracking branch 'origin/master' into nativelibraries-fix - ... and 5 more: https://git.openjdk.org/jdk/compare/3ebbd323...09de5608 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/d571e826..09de5608 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=07-08 Stats: 26638 lines in 664 files changed: 15736 ins; 8292 del; 2610 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From iklam at openjdk.org Fri Oct 17 22:27:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 17 Oct 2025 22:27:35 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Message-ID: By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. ------------- Commit messages: - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Changes: https://git.openjdk.org/jdk/pull/27880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368199 Stats: 38 lines in 7 files changed: 5 ins; 30 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From duke at openjdk.org Sat Oct 18 00:09:03 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Sat, 18 Oct 2025 00:09:03 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com> References: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com> Message-ID: On Wed, 8 Oct 2025 12:36:23 GMT, Alan Bateman wrote: > A better starting point for discussion would be a test that exercises System.loadLibrary with the a library name that locates a DLL through a sym link to a final target that doesn't have the .dll suffix. To this end, I have updated the PR to add a test `test/jdk/java/lang/ClassLoader/loadLibrarySymlinks/LoadLibrarySymlinksTest.java`. This test exercises the 3 cases discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2025-October/152992.html. Unix platforms pass this test as expected. Since I reverted all of my proposed fixes, Windows fails handling the `test2.dll -> barename` case: java.lang.UnsatisfiedLinkError: D:\\a\\jdk\\jdk\\build\\run-test-prebuilt\\test-support\\jtreg_test_jdk_tier1_part1\\scratch\\barename: Can't find dependent libraries at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:326) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2282) at java.base/java.lang.Runtime.load0(Runtime.java:767) at java.base/java.lang.System.load(System.java:1646) at LoadLibrarySymlinksTest.main(LoadLibrarySymlinksTest.java:48) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474) JavaTest Message: Test threw exception: java.lang.UnsatisfiedLinkError I hope this aids in understanding the issue and review my proposed fix(es). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3417543831 From liach at openjdk.org Sat Oct 18 02:51:01 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Oct 2025 02:51:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69: > 67: public class SharedSecrets { > 68: // This field is not necessarily stable > 69: private static JavaAWTFontAccess javaAWTFontAccess; Does aot initialization work with this field? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441536894 From iklam at openjdk.org Sat Oct 18 04:06:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 18 Oct 2025 04:06:00 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Sat, 18 Oct 2025 02:48:42 GMT, Chen Liang wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69: > >> 67: public class SharedSecrets { >> 68: // This field is not necessarily stable >> 69: private static JavaAWTFontAccess javaAWTFontAccess; > > Does aot initialization work with this field? I think this field is safe. There are two places that could set it, but they will always set it to an instance of `JavaAWTFontAccessImpl`, which is stateless. https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/NumericShaper.java#L148-L149 https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/TextAttribute.java#L251-L252 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441561760 From liach at openjdk.org Sat Oct 18 04:18:00 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Oct 2025 04:18:00 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Archiving the accessors should be fine. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3352526259 From azafari at openjdk.org Sat Oct 18 17:15:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 18 Oct 2025 17:15:45 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v15] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: - Merge remote-tracking branch 'jdksjolen/test-canary' into _20251006_asan_hdr_footer - A different way - NOT_LP64 fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/c644a84a..a0779f47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=13-14 Stats: 44 lines in 3 files changed: 15 ins; 16 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From azafari at openjdk.org Sat Oct 18 17:26:26 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 18 Oct 2025 17:26:26 GMT Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN build [v16] In-Reply-To: References: Message-ID: > NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected. > In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed problem after merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27685/files - new: https://git.openjdk.org/jdk/pull/27685/files/a0779f47..8baffef9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=14-15 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685 PR: https://git.openjdk.org/jdk/pull/27685 From alanb at openjdk.org Sun Oct 19 09:33:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Oct 2025 09:33:04 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com> Message-ID: On Sat, 18 Oct 2025 00:06:11 GMT, Benjamin Peterson wrote: > I hope this aids in understanding the issue and review my proposed fix(es). I think the issue is understood. The original bug report was a bit confusing as it involved replacing the DLLs in the JDK bin directory with sym links. I think we are past that now and the discussion has moved onto sym links with the .dll suffix that are linked to files that don't have the .dll suffix. We don't have an insight as to why the Windows APIs requires "opt-in" for this. It may help to thwart attempts to evade scanners, maybe it makes it harder for smugglers, or maybe there are other reasons. I've asked our security team for some input on the topic before forming an opinion as to whether we should do anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3419516424 From dholmes at openjdk.org Sun Oct 19 21:35:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 19 Oct 2025 21:35:03 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: <1T6SF8fHQQ5l7aLDEopOOZjTsa9Cyi88jyyzotGgywA=.60733166-0cbf-41a9-9a9a-215a3386cfdf@github.com> On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). This is the same kind of strategy used by ZGC. It seems a good idiom to use for dealing with error reporting. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3354680283 From dholmes at openjdk.org Mon Oct 20 00:06:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 00:06:02 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: <1Z6wggZ2A6MMmzFvsAIZCe3JfQzKQ-PE5I3c6wt03Q8=.db019656-1e28-474f-a2f0-db6829c08750@github.com> On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). src/hotspot/share/nmt/mallocTracker.cpp line 71: > 69: if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) { > 70: ls = ChunkPoolLocker::LockStrategy::Try; > 71: } Thinking more, we could simply always do this check in the constructor and do away with the "strategy" flag altogether. Arguably this would be reasonable behaviour for every Mutexlocker (though it may slow things down a little). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2443565738 From dholmes at openjdk.org Mon Oct 20 00:10:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 00:10:16 GMT Subject: RFR: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code [v3] In-Reply-To: References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Fri, 17 Oct 2025 04:18:32 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Fix misleading indent. >> - Merge branch 'master' into 8369631-sr_sem >> - Switch to DeferredStatic per Kim's request >> - 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code > > Looks good. Thanks again for the reviews @kimbarrett and @stefank ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27762#issuecomment-3420079328 From dholmes at openjdk.org Mon Oct 20 00:10:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 00:10:17 GMT Subject: Integrated: 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code In-Reply-To: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> References: <8zuNbzluif5GjOE_vcKwDBK2aT6oUFrM8uLX8fTr9MQ=.9ad15e94-775f-4014-ba2b-7c60c8b406f5@github.com> Message-ID: On Mon, 13 Oct 2025 06:52:32 GMT, David Holmes wrote: > Replace the statically allocated "semaphore" with a pointer and lazily initialize it. I chose this approach as we already have a second Semaphore declared that way. > > Testing: > - tiers 1-3 sanity > > Thanks. This pull request has now been integrated. Changeset: 680414d0 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/680414d0f9ab75d888bcb284cc494124a01a388f Stats: 25 lines in 1 file changed: 8 ins; 5 del; 12 mod 8369631: Assess and remedy any unsafe usage of the sr_semaphore Semaphore in the Posix signal code Reviewed-by: stefank, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/27762 From dholmes at openjdk.org Mon Oct 20 03:02:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 03:02:05 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v5] In-Reply-To: <7NG-bGMEVR4e5Uzz3s4VsNvzL2lbyCI2IXiup5VAtx4=.d65e6379-b612-45bf-b6f8-8ee296750bf2@github.com> References: <7NG-bGMEVR4e5Uzz3s4VsNvzL2lbyCI2IXiup5VAtx4=.d65e6379-b612-45bf-b6f8-8ee296750bf2@github.com> Message-ID: On Fri, 17 Oct 2025 12:50:59 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust log calls Changes requested by dholmes (Reviewer). src/hotspot/os/posix/perfMemory_posix.cpp line 76: > 74: if (!os::commit_memory(mapAddress, size, !ExecMem)) { > 75: if (log_is_enabled(Debug, perf)) { > 76: log_debug(perf)("Could not commit PerfData memory"); You don't need the `log_is_enabled` check with a single logging statement as the `log_debug` is a macro that already contains the check. ------------- PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3354912434 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2443716118 From dholmes at openjdk.org Mon Oct 20 06:53:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 06:53:14 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 Message-ID: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> I missed that the `UserHandler` can still be used even if `-Xrs` is specified, so we have to check for `!ReduceSignalUsage` as per Kim's initial suggestion in JDK-8369631. Testing - tiers 1-4 Thanks ------------- Commit messages: - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 Changes: https://git.openjdk.org/jdk/pull/27888/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27888&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370207 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27888/head:pull/27888 PR: https://git.openjdk.org/jdk/pull/27888 From azafari at openjdk.org Mon Oct 20 07:01:52 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 07:01:52 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v5] In-Reply-To: References: Message-ID: > On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: stdint added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27764/files - new: https://git.openjdk.org/jdk/pull/27764/files/fd333d3e..6f582d4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27764&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27764/head:pull/27764 PR: https://git.openjdk.org/jdk/pull/27764 From azafari at openjdk.org Mon Oct 20 07:10:07 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 07:10:07 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 09:53:28 GMT, Afshin Zafari wrote: >> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. >> Specific casts are used to avoid UBSAN error. >> >> Tests: >> linux-x64-debug: tier1 passed > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix after wrong merge. Dear @iklam , in https://github.com/openjdk/jdk/pull/26955, it is suggested to use `uintptr_t` for addresses in pointer arithmetics and cast them to `address` when we pass them into functions. There are some of this conversions in related code here, do you want me to do this or as a separate RFE? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26983#issuecomment-3420850537 From dholmes at openjdk.org Mon Oct 20 07:38:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 07:38:18 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 [v2] In-Reply-To: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: > I missed that the `UserHandler` can still be used even if `-Xrs` is specified, so we have to check for `!ReduceSignalUsage` as per Kim's initial suggestion in JDK-8369631. > > Testing > - tiers 1-4 > > Thanks David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Un-ProblemList the test - Merge branch 'master' into 8370207-sem_notify-crash - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27888/files - new: https://git.openjdk.org/jdk/pull/27888/files/ed3227a7..9a69dd1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27888&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27888&range=00-01 Stats: 14 lines in 2 files changed: 6 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27888/head:pull/27888 PR: https://git.openjdk.org/jdk/pull/27888 From dholmes at openjdk.org Mon Oct 20 07:59:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 07:59:27 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v5] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 07:01:52 GMT, Afshin Zafari wrote: >> On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > stdint added LGTM2 Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27764#pullrequestreview-3355352415 From dholmes at openjdk.org Mon Oct 20 08:03:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 08:03:33 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 15:24:48 GMT, Patricio Chilano Mateo wrote: >> If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. >> This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: >> >> `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` >> >> There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. >> Testing in mach5 tiers1-5. >> >> Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > rename to was_notified Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27856#pullrequestreview-3355361921 From dholmes at openjdk.org Mon Oct 20 08:03:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Oct 2025 08:03:34 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 15:24:26 GMT, Patricio Chilano Mateo wrote: >> I think it is the latter. We could read a stale TState value no matter what, as it may have only just been set before we read it. But not seeing TS_WAIT is just an optimisation to skip the park. > > Exactly. If the notifier already issued the unpark then the park permit (`PlatformEvent::_event`) will be set. Doh! I was forgetting that park (unlike wait) has a permit. Thanks for clarifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2444084647 From coffeys at openjdk.org Mon Oct 20 09:50:14 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 20 Oct 2025 09:50:14 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Further help message tweaks Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3421292699 From coffeys at openjdk.org Mon Oct 20 09:50:16 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 20 Oct 2025 09:50:16 GMT Subject: Integrated: 8370071: Clarify jcmd Thread.print help message In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey wrote: > Simple tweak to jcmd Thread.print help message > > jdk_svc test group ran and green This pull request has now been integrated. Changeset: ee353201 Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/ee353201d1c3f7521825ea852e37400277101164 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod 8370071: Clarify jcmd Thread.print help message Reviewed-by: kevinw ------------- PR: https://git.openjdk.org/jdk/pull/27861 From alanb at openjdk.org Mon Oct 20 10:06:22 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Oct 2025 10:06:22 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey wrote: >> Simple tweak to jcmd Thread.print help message >> >> jdk_svc test group ran and green > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Further help message tweaks src/hotspot/share/services/diagnosticCommand.hpp line 361: > 359: return "Print all platform threads, and mounted virtual threads, " > 360: "with stack traces. The Thread.dump_to_file command will " > 361: "print all threads to a file."; I'm still in two minds about having it mention Thread.dump_to_file. If it is mentioned then it would be better to put in a line break and use "may be used to" that rather than "will". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2444514929 From mbaesken at openjdk.org Mon Oct 20 11:13:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Oct 2025 11:13:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v5] In-Reply-To: References: <7NG-bGMEVR4e5Uzz3s4VsNvzL2lbyCI2IXiup5VAtx4=.d65e6379-b612-45bf-b6f8-8ee296750bf2@github.com> Message-ID: On Mon, 20 Oct 2025 02:58:43 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust log calls > > src/hotspot/os/posix/perfMemory_posix.cpp line 76: > >> 74: if (!os::commit_memory(mapAddress, size, !ExecMem)) { >> 75: if (log_is_enabled(Debug, perf)) { >> 76: log_debug(perf)("Could not commit PerfData memory"); > > You don't need the `log_is_enabled` check with a single logging statement as the `log_debug` is a macro that already contains the check. That's good, saves us quite a few lines ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2444704430 From coffeys at openjdk.org Mon Oct 20 11:26:43 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 20 Oct 2025 11:26:43 GMT Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 10:03:12 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Further help message tweaks > > src/hotspot/share/services/diagnosticCommand.hpp line 361: > >> 359: return "Print all platform threads, and mounted virtual threads, " >> 360: "with stack traces. The Thread.dump_to_file command will " >> 361: "print all threads to a file."; > > I'm still in two minds about having it mention Thread.dump_to_file. If it is mentioned then it would be better to put in a line break and use "may be used to" that rather than "will". yes - happy to tweak this in follow on issue if necessary. I think it reads fine as is but let me know the final format and I'll file a new PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2444735331 From azafari at openjdk.org Mon Oct 20 11:36:20 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 11:36:20 GMT Subject: RFR: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted [v5] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 07:56:24 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> stdint added > > LGTM2 > > Thanks Thank you @dholmes-ora and @jdksjolen for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27764#issuecomment-3421689577 From azafari at openjdk.org Mon Oct 20 11:36:23 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 11:36:23 GMT Subject: Integrated: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted In-Reply-To: References: Message-ID: <6m2dNq3gMaRkZUOowD-nHURyO4MTOh-RKzq9GOt_kvQ=.cd754f87-20de-4338-99c8-c56cc0154be5@github.com> On Mon, 13 Oct 2025 10:27:26 GMT, Afshin Zafari wrote: > On NMT detail mode, the allocation-sites of malloc'd memory regions are also stored. Using this information, the call-stack of a corrupted memory can also be printed as the error message. This pull request has now been integrated. Changeset: c8679713 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/c8679713402186b24608fa4c91397b6a4fd5ebf3 Stats: 199 lines in 7 files changed: 194 ins; 0 del; 5 mod 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27764 From mbaesken at openjdk.org Mon Oct 20 12:17:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Oct 2025 12:17:45 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v6] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove log_is_enabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/30ca96b1..f0f4e57c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=04-05 Stats: 210 lines in 3 files changed: 0 ins; 123 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From coleenp at openjdk.org Mon Oct 20 12:25:58 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 20 Oct 2025 12:25:58 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: <1Z6wggZ2A6MMmzFvsAIZCe3JfQzKQ-PE5I3c6wt03Q8=.db019656-1e28-474f-a2f0-db6829c08750@github.com> References: <1Z6wggZ2A6MMmzFvsAIZCe3JfQzKQ-PE5I3c6wt03Q8=.db019656-1e28-474f-a2f0-db6829c08750@github.com> Message-ID: On Mon, 20 Oct 2025 00:03:36 GMT, David Holmes wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > src/hotspot/share/nmt/mallocTracker.cpp line 71: > >> 69: if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) { >> 70: ls = ChunkPoolLocker::LockStrategy::Try; >> 71: } > > Thinking more, we could simply always do this check in the constructor and do away with the "strategy" flag altogether. Arguably this would be reasonable behaviour for every Mutexlocker (though it may slow things down a little). I had a version that did this but Johan was worried about global behavior so wanted to limit it to just NMT reporting on error to be safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2444858287 From azafari at openjdk.org Mon Oct 20 12:37:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 12:37:37 GMT Subject: RFR: 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 Message-ID: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> The extra letters removed. ------------- Commit messages: - 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 Changes: https://git.openjdk.org/jdk/pull/27897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370230 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27897/head:pull/27897 PR: https://git.openjdk.org/jdk/pull/27897 From thartmann at openjdk.org Mon Oct 20 12:40:15 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 20 Oct 2025 12:40:15 GMT Subject: RFR: 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 In-Reply-To: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> References: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> Message-ID: <7CHS6qkDcx64zK5pVXZ8z7a48zXtU-XQGdqlrz9BFgU=.4c997f04-62ba-4be9-b73c-65e5ea944f67@github.com> On Mon, 20 Oct 2025 12:30:09 GMT, Afshin Zafari wrote: > The extra letters removed. Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27897#pullrequestreview-3356309273 From mbaesken at openjdk.org Mon Oct 20 12:55:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Oct 2025 12:55:35 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files Message-ID: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). error output is : java.lang.RuntimeException: Expected source information missing from output at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474) ------------- Commit messages: - JDK-8370064 Changes: https://git.openjdk.org/jdk/pull/27899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370064 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899 PR: https://git.openjdk.org/jdk/pull/27899 From clanger at openjdk.org Mon Oct 20 12:55:36 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 20 Oct 2025 12:55:36 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Mon, 20 Oct 2025 12:47:52 GMT, Matthias Baesken wrote: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) Seems reasonable. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27899#pullrequestreview-3356344568 From mbaesken at openjdk.org Mon Oct 20 13:10:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Oct 2025 13:10:37 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Mon, 20 Oct 2025 12:50:17 GMT, Christoph Langer wrote: > Seems reasonable. Thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3421994506 From heidinga at openjdk.org Mon Oct 20 13:56:45 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 13:56:45 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: > 63: > 64: // Static fields in this class are stateless, so the values initialized in the > 65: // AOT assembly phase can be safely cached. Looking through the implementations of the Access classes, and I have concerns about: `setJavaObjectInputFilterAccess` as it is implemented using a lambda: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445087494 From heidinga at openjdk.org Mon Oct 20 13:56:46 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 13:56:46 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 13:51:18 GMT, Dan Heidinga wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: > >> 63: >> 64: // Static fields in this class are stateless, so the values initialized in the >> 65: // AOT assembly phase can be safely cached. > > Looking through the implementations of the Access classes, and I have concerns about: > `setJavaObjectInputFilterAccess` as it is implemented using a lambda: > > SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > > Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? > > `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445095385 From mbaesken at openjdk.org Mon Oct 20 14:24:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Oct 2025 14:24:18 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v6] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 12:17:45 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove log_is_enabled src/hotspot/share/runtime/perfMemory.cpp line 251: > 249: dest_file, JVM_MAXPATHLEN)) { > 250: FREE_C_HEAP_ARRAY(char, dest_file); > 251: log_debug(perf)("Invalid performance data file path name specified, "\ Btw is the ` '' `here really needed ? We had it before but most strings over multiple lines do not use it, from what I see ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2445170092 From azafari at openjdk.org Mon Oct 20 15:12:21 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 15:12:21 GMT Subject: RFR: 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 In-Reply-To: <7CHS6qkDcx64zK5pVXZ8z7a48zXtU-XQGdqlrz9BFgU=.4c997f04-62ba-4be9-b73c-65e5ea944f67@github.com> References: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> <7CHS6qkDcx64zK5pVXZ8z7a48zXtU-XQGdqlrz9BFgU=.4c997f04-62ba-4be9-b73c-65e5ea944f67@github.com> Message-ID: On Mon, 20 Oct 2025 12:37:49 GMT, Tobias Hartmann wrote: >> The extra letters removed. > > Looks good and trivial. Thanks @TobiHartmann ------------- PR Comment: https://git.openjdk.org/jdk/pull/27897#issuecomment-3422499813 From azafari at openjdk.org Mon Oct 20 15:12:22 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 20 Oct 2025 15:12:22 GMT Subject: Integrated: 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 In-Reply-To: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> References: <63DBXCE7BbsjcsUeY942G3nhELeXee9aolEBTm38pTI=.7c3a91ca-29f9-41d4-a3b6-5fe4b4e4d8b6@github.com> Message-ID: On Mon, 20 Oct 2025 12:30:09 GMT, Afshin Zafari wrote: > The extra letters removed. This pull request has now been integrated. Changeset: dc6858f3 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/dc6858f336a9acaac26d302fdc462ac1ed5c94ba Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8370230: Bad copyright in NMTPrintMallocSiteOfCorruptedMemory.java after JDK-8369527 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/jdk/pull/27897 From iklam at openjdk.org Mon Oct 20 16:54:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 20 Oct 2025 16:54:03 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 13:53:52 GMT, Dan Heidinga wrote: >> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: >> >>> 63: >>> 64: // Static fields in this class are stateless, so the values initialized in the >>> 65: // AOT assembly phase can be safely cached. >> >> Looking through the implementations of the Access classes, and I have concerns about: >> `setJavaObjectInputFilterAccess` as it is implemented using a lambda: >> >> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); >> >> Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? >> >> `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. > > There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. > > SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); > SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445577257 From iklam at openjdk.org Mon Oct 20 17:11:08 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 20 Oct 2025 17:11:08 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 09:53:28 GMT, Afshin Zafari wrote: >> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. >> Specific casts are used to avoid UBSAN error. >> >> Tests: >> linux-x64-debug: tier1 passed > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix after wrong merge. > Dear @iklam , in #26955, it is suggested to use `uintptr_t` for addresses in pointer arithmetics and cast them to `address` when we pass them into functions. There are some of this conversions in related code here, do you want me to do this or as a separate RFE? I think we should probably do that in a separate RFE. The CDS code has a mixed use of intptr_t, address and char* for addresses. We should probably change all of them to a single type, and I agree that intptr_t is the best of the three. src/hotspot/share/cds/archiveBuilder.cpp line 1047: > 1045: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { > 1046: // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic. > 1047: address requested_addr = (address)((uintptr_t)_requested_static_archive_bottom + offset); We should avoid this problem altogether with this: - address requested_addr = _requested_static_archive_bottom + offset; - address buffered_addr = requested_addr - _buffer_to_requested_delta; - address buffered_addr = _buffer_bottom + offset; ------------- PR Comment: https://git.openjdk.org/jdk/pull/26983#issuecomment-3423004461 PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2445611871 From iklam at openjdk.org Mon Oct 20 16:59:08 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 20 Oct 2025 16:59:08 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 09:53:28 GMT, Afshin Zafari wrote: >> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. >> Specific casts are used to avoid UBSAN error. >> >> Tests: >> linux-x64-debug: tier1 passed > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix after wrong merge. src/hotspot/share/cds/archiveBuilder.cpp line 1116: > 1114: // As zero is allowed for new_bottom, use integer arithmetic to avoid UB pointer arithmetic. > 1115: address new_bottom = (address)((uintptr_t)bottom + _buffer_to_requested_delta); > 1116: address new_top = (address)((uintptr_t)top + _buffer_to_requested_delta); In these two lines, `new_top`, `top` and `bottom` are never zeros. The only address that may be zero is `new_bottom`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2445590051 From heidinga at openjdk.org Mon Oct 20 17:43:03 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 17:43:03 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> On Mon, 20 Oct 2025 16:51:35 GMT, Ioi Lam wrote: >> There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. >> >> SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); >> SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); > > These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445689913 From karianna at openjdk.org Mon Oct 20 20:17:06 2025 From: karianna at openjdk.org (Martijn Verburg) Date: Mon, 20 Oct 2025 20:17:06 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Wed, 8 Oct 2025 19:30:19 GMT, Saint Wesonga wrote: >> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/ blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. >> >> This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Fix style nits src/hotspot/os/windows/os_windows.cpp line 6286: > 6284: > 6285: /* > 6286: * Windows/x64 does not use stack frames the way expected by Java: Should that comment say /x64 if it's for all aarchs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27680#discussion_r2446012865 From duke at openjdk.org Mon Oct 20 20:25:08 2025 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 20 Oct 2025 20:25:08 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Mon, 20 Oct 2025 20:14:24 GMT, Martijn Verburg wrote: > Should that comment say /x64 if it's for all aarchs? The behavior described in this comment section applies to x64 only (it is the original motivation for introducing this platform printing implementation). This change recognizes that the preexisting Windows x64 solution is essentially platform agnostic (modulo the machine type and registers) and therefore reuses it for Windows AArch64. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27680#discussion_r2446033193 From matsaave at openjdk.org Mon Oct 20 20:35:35 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 20 Oct 2025 20:35:35 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic Message-ID: This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. ------------- Commit messages: - 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic Changes: https://git.openjdk.org/jdk/pull/27904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359057 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27904/head:pull/27904 PR: https://git.openjdk.org/jdk/pull/27904 From vlivanov at openjdk.org Mon Oct 20 20:49:02 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 20 Oct 2025 20:49:02 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 20:29:11 GMT, Matias Saavedra Silva wrote: > This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. src/hotspot/share/interpreter/abstractInterpreter.cpp line 261: > 259: assert(invoke_bc.has_index_u4(code), "sanity"); > 260: int method_index = invoke_bc.get_index_u4(code); > 261: return !cpool->resolved_indy_entry_at(method_index)->is_resolved(); IMO it's hard to read. I recommend to shape it as follows: bool is_resolved = cpool->resolved_indy_entry_at(method_index)->is_resolved(); return !is_resolved; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27904#discussion_r2446082678 From karianna at openjdk.org Mon Oct 20 21:51:02 2025 From: karianna at openjdk.org (Martijn Verburg) Date: Mon, 20 Oct 2025 21:51:02 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Wed, 8 Oct 2025 19:30:19 GMT, Saint Wesonga wrote: >> HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/ blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. >> >> This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. > > Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: > > Fix style nits Marked as reviewed by karianna (no project role). ------------- PR Review: https://git.openjdk.org/jdk/pull/27680#pullrequestreview-3358046000 From karianna at openjdk.org Mon Oct 20 21:51:05 2025 From: karianna at openjdk.org (Martijn Verburg) Date: Mon, 20 Oct 2025 21:51:05 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Mon, 20 Oct 2025 20:22:43 GMT, Saint Wesonga wrote: >> src/hotspot/os/windows/os_windows.cpp line 6286: >> >>> 6284: >>> 6285: /* >>> 6286: * Windows/x64 does not use stack frames the way expected by Java: >> >> Should that comment say /x64 if it's for all aarchs? > >> Should that comment say /x64 if it's for all aarchs? > > The behavior described in this comment section applies to x64 only (it is the original motivation for introducing this platform printing implementation). This change recognizes that the preexisting Windows x64 solution is essentially platform agnostic (modulo the machine type and registers) and therefore reuses it for Windows AArch64. Oh, I missed the comment at the bottom, sorry! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27680#discussion_r2446211909 From liach at openjdk.org Mon Oct 20 22:01:24 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Oct 2025 22:01:24 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 20:29:11 GMT, Matias Saavedra Silva wrote: > This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. Just curious, does this have any observable effect that can surface in a regression test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27904#issuecomment-3423877839 From pchilanomate at openjdk.org Mon Oct 20 22:05:03 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 20 Oct 2025 22:05:03 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 20:05:24 GMT, Serguei Spitsyn wrote: > This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. > > Testing: > - TBD: Run mach5 tiers 1-6 Thanks for fixing this Serguei. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1689: > 1687: log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); > 1688: > 1689: JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); Why not directly in `preempt_epilog`? Is it to cover the freeze fast case too? If that?s the case we should remove the call to `invalidate_jvmti_stack` from `jvmti_yield_cleanup` to avoid calling it twice for the freeze slow case. Also I wonder if this call to `invalidate_jvmti_stack` should just be moved to `JvmtiVTMSTransitionDisabler::VTMS_unmount_end` instead. ------------- PR Review: https://git.openjdk.org/jdk/pull/27878#pullrequestreview-3358066574 PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2446228791 From dholmes at openjdk.org Tue Oct 21 00:19:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 00:19:01 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Mon, 20 Oct 2025 12:47:52 GMT, Matthias Baesken wrote: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) You can't just disable this aspect of the test for Windows because it may fail in your environment. We want to test this aspect as broadly as possible. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27899#pullrequestreview-3358375446 From dholmes at openjdk.org Tue Oct 21 02:16:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 02:16:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v6] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 14:21:00 GMT, Matthias Baesken wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove log_is_enabled > > src/hotspot/share/runtime/perfMemory.cpp line 251: > >> 249: dest_file, JVM_MAXPATHLEN)) { >> 250: FREE_C_HEAP_ARRAY(char, dest_file); >> 251: log_debug(perf)("Invalid performance data file path name specified, "\ > > Btw is the ` '' `here really needed ? We had it before but most strings over multiple lines do not use it, from what I see ? No it isn't needed - string literals across new-lines are concatenated. You don't need an explicit line continuation character. Not that it makes any real difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446547801 From kbarrett at openjdk.org Tue Oct 21 02:18:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 21 Oct 2025 02:18:01 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 [v2] In-Reply-To: References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: On Mon, 20 Oct 2025 07:38:18 GMT, David Holmes wrote: >> I missed that the `UserHandler` can still be used even if `-Xrs` is specified, so we have to check for `!ReduceSignalUsage` as per Kim's initial suggestion in JDK-8369631. >> >> Testing >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Un-ProblemList the test > - Merge branch 'master' into 8370207-sem_notify-crash > - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27888#pullrequestreview-3358528289 From dholmes at openjdk.org Tue Oct 21 05:38:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 05:38:15 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v6] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 02:13:16 GMT, David Holmes wrote: >> src/hotspot/share/runtime/perfMemory.cpp line 251: >> >>> 249: dest_file, JVM_MAXPATHLEN)) { >>> 250: FREE_C_HEAP_ARRAY(char, dest_file); >>> 251: log_debug(perf)("Invalid performance data file path name specified, "\ >> >> Btw is the ` '' `here really needed ? We had it before but most strings over multiple lines do not use it, from what I see ? > > No it isn't needed - string literals across new-lines are concatenated. You don't need an explicit line continuation character. Not that it makes any real difference. I've suggested reformatting most of these anyway as they don't need to be so short in many cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446767012 From dholmes at openjdk.org Tue Oct 21 05:38:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 05:38:13 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v6] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 12:17:45 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove log_is_enabled A few formatting suggestions and one minor fix, but otherwise this looks good to me. Thanks src/hotspot/os/posix/perfMemory_posix.cpp line 464: > 462: else { > 463: log.print_cr("Could not determine user name: %s", > 464: p->pw_name == nullptr ? "pw_name = null" : "pw_name zero length"); Suggestion: log.print_cr("Could not determine user name: %s", p->pw_name == nullptr ? "pw_name = null" : "pw_name zero length"); Fix indent src/hotspot/os/posix/perfMemory_posix.cpp line 678: > 676: if (errno != ENOENT) { > 677: log_debug(perf)("Could not unlink shared memory backing" > 678: " store file %s : %s", path, os::strerror(errno)); Suggestion: log_debug(perf)("Could not unlink shared memory backing store file %s : %s", path, os::strerror(errno)); src/hotspot/os/windows/perfMemory_windows.cpp line 217: > 215: // unexpected error, declare the path insecure > 216: log_debug(perf)("could not get attributes for file %s: " > 217: " lasterror = %d", path, lasterror); Suggestion: log_debug(perf)("could not get attributes for file %s: lasterror = %d", path, lasterror); src/hotspot/os/windows/perfMemory_windows.cpp line 484: > 482: if (errno != ENOENT) { > 483: log_debug(perf)("Could not unlink shared memory backing" > 484: " store file %s : %s", path, os::strerror(errno)); Suggestion: log_debug(perf)("Could not unlink shared memory backing store file %s : %s", path, os::strerror(errno)); src/hotspot/os/windows/perfMemory_windows.cpp line 505: > 503: DWORD lastError = GetLastError(); > 504: if (lastError != ERROR_INVALID_PARAMETER) { > 505: log_debug(perf)("OpenProcess failed: %d", GetLastError()); Suggestion: log_debug(perf)("OpenProcess failed: %d", lastError); src/hotspot/os/windows/perfMemory_windows.cpp line 557: > 555: // we can't get information about the volume, so assume unsafe. > 556: log_debug(perf)("could not get device information for %s: " > 557: " path = %s: lasterror = %d", Suggestion: log_debug(perf)("could not get device information for %s: path = %s: lasterror = %d", src/hotspot/os/windows/perfMemory_windows.cpp line 565: > 563: // file system doesn't support ACLs, declare file system unsafe > 564: log_debug(perf)("file system type %s on device %s does not support" > 565: " ACLs", fs_type, root_path); Suggestion: log_debug(perf)("file system type %s on device %s does not support ACLs", fs_type, root_path); src/hotspot/os/windows/perfMemory_windows.cpp line 764: > 762: if (lasterror != ERROR_INSUFFICIENT_BUFFER) { > 763: log_debug(perf)("GetTokenInformation failure: lasterror = %d," > 764: " rsize = %d", lasterror, rsize); Suggestion: log_debug(perf)("GetTokenInformation failure: lasterror = %d, rsize = %d", lasterror, rsize); src/hotspot/os/windows/perfMemory_windows.cpp line 775: > 773: if (!GetTokenInformation(hAccessToken, TokenUser, token_buf, rsize, &rsize)) { > 774: log_debug(perf)("GetTokenInformation failure: lasterror = %d," > 775: " rsize = %d", GetLastError(), rsize); Suggestion: log_debug(perf)("GetTokenInformation failure: lasterror = %d, rsize = %d", GetLastError(), rsize); src/hotspot/os/windows/perfMemory_windows.cpp line 786: > 784: if (!CopySid(nbytes, pSID, token_buf->User.Sid)) { > 785: log_debug(perf)("GetTokenInformation failure: lasterror = %d," > 786: " rsize = %d", GetLastError(), rsize); Suggestion: log_debug(perf)("GetTokenInformation failure: lasterror = %d, rsize = %d", GetLastError(), rsize); src/hotspot/os/windows/perfMemory_windows.cpp line 952: > 950: if (!SetSecurityDescriptorDacl(pSD, TRUE, newACL, FALSE)) { > 951: log_debug(perf)("SetSecurityDescriptorDacl failure:" > 952: " lasterror = %d", GetLastError()); Suggestion: log_debug(perf)("SetSecurityDescriptorDacl failure: lasterror = %d", GetLastError()); src/hotspot/os/windows/perfMemory_windows.cpp line 970: > 968: SE_DACL_PROTECTED)) { > 969: log_debug(perf)("SetSecurityDescriptorControl failure:" > 970: " lasterror = %d", GetLastError()); Suggestion: log_debug(perf)("SetSecurityDescriptorControl failure: lasterror = %d", GetLastError()); src/hotspot/os/windows/perfMemory_windows.cpp line 1000: > 998: if (!InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION)) { > 999: log_debug(perf)("InitializeSecurityDescriptor failure: " > 1000: "lasterror = %d", GetLastError()); Suggestion: log_debug(perf)("InitializeSecurityDescriptor failure: lasterror = %d", GetLastError()); src/hotspot/os/windows/perfMemory_windows.cpp line 1054: > 1052: 0, 0, 0, 0, 0, 0, &administratorsSid)) { > 1053: log_debug(perf)("AllocateAndInitializeSid failure: " > 1054: "lasterror = %d", GetLastError()); Suggestion: log_debug(perf)("AllocateAndInitializeSid failure: lasterror = %d", GetLastError()); src/hotspot/os/windows/perfMemory_windows.cpp line 1069: > 1067: 0, 0, 0, 0, 0, 0, 0, &everybodySid)) { > 1068: log_debug(perf)("AllocateAndInitializeSid failure: " > 1069: "lasterror = %d", GetLastError()); Suggestion: log_debug(perf)("AllocateAndInitializeSid failure: lasterror = %d", GetLastError()); ------------- PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3358529566 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446751388 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446753186 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446756485 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446757435 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446757971 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446758996 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446759591 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446760492 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446761493 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446761961 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446762711 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446763125 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446763472 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446763862 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2446764141 From mbaesken at openjdk.org Tue Oct 21 07:45:03 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 21 Oct 2025 07:45:03 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Tue, 21 Oct 2025 00:16:05 GMT, David Holmes wrote: > You can't just disable this aspect of the test for Windows because it may fail in your environment. We want to test this aspect as broadly as possible. I could read in pdb file(s) are look at the binary to find out if it is a stripped or full pdb. Or use some external tools to do so. Or transfer the info into the build, that I create stripped pdb files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3425215840 From phubner at openjdk.org Tue Oct 21 11:23:20 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 21 Oct 2025 11:23:20 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). src/hotspot/share/memory/arena.cpp line 52: > 50: GlobalChunkPoolMutex->lock(); > 51: _locked = true; > 52: } else { Possible enhancement: explicitly check for `Try` and then `ShouldNotReachHere` in the else case. I'm not sure if this is necessary for a bandaid fix like this, though. src/hotspot/share/memory/arena.hpp line 41: > 39: > 40: class ChunkPoolLocker : public StackObj { > 41: public: Nitpick FYI: I think the new `public` has a different indentation than the old one. Just wanted to point it out, is this something that should be addressed? I do not have an opinion on the topic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2447748968 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2447764293 From azafari at openjdk.org Tue Oct 21 11:39:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 21 Oct 2025 11:39:15 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). Thank you for taking this PR. I could reproduce the deadlock by this change: --- a/test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp +++ b/test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp @@ -23,6 +23,7 @@ */ #include "memory/allocation.hpp" +#include "memory/arena.hpp" #include "nmt/memTracker.hpp" #include "runtime/os.hpp" #include "sanitizers/address.hpp" @@ -142,6 +143,21 @@ DEFINE_TEST(test_corruption_on_realloc_growing, COMMON_NMT_HEAP_CORRUPTION_MESSA static void test_corruption_on_realloc_shrinking() { test_corruption_on_realloc(0x11, 0x10); } DEFINE_TEST(test_corruption_on_realloc_shrinking, COMMON_NMT_HEAP_CORRUPTION_MESSAGE_PREFIX); + +static void test_chunkpool_lock() { + if (!MemTracker::enabled()) { + tty->print_cr("Skipped"); + return; + } + PrintNMTStatistics = true; + { + ChunkPoolLocker cpl; + char* mem = (char*)os::malloc(100, mtTest); + memset(mem - 16, 0, 100 + 16 + 2); + os::free(mem); + } +} +DEFINE_TEST(test_chunkpool_lock, COMMON_NMT_HEAP_CORRUPTION_MESSAGE_PREFIX); /////// We can add it to the tests if you found it useful. ------------- PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3360133902 From azafari at openjdk.org Tue Oct 21 12:23:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 21 Oct 2025 12:23:13 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v7] In-Reply-To: References: Message-ID: <9EXHz19q0NrN-DldsA_TVXhyX8Hxmd4rRBEh3mv32WE=.01c0dea8-e8a1-4ac6-bfc0-7752c277a380@github.com> > It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. > Specific casts are used to avoid UBSAN error. > > Tests: > linux-x64-debug: tier1 passed Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset - fix after wrong merge. - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset - comment fixed - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset - comments improved - 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp ------------- Changes: https://git.openjdk.org/jdk/pull/26983/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=06 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983 PR: https://git.openjdk.org/jdk/pull/26983 From coleenp at openjdk.org Tue Oct 21 12:36:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Oct 2025 12:36:02 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). Thank you Afshin for the test. I'll add it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27869#issuecomment-3426373192 From coleenp at openjdk.org Tue Oct 21 12:42:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Oct 2025 12:42:12 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 11:15:57 GMT, Paul H?bner wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > src/hotspot/share/memory/arena.cpp line 52: > >> 50: GlobalChunkPoolMutex->lock(); >> 51: _locked = true; >> 52: } else { > > Possible enhancement: explicitly check for `Try` and then `ShouldNotReachHere` in the else case. I'm not sure if this is necessary for a bandaid fix like this, though. I suppose I could add it. The enum only has two choices so it seems like overkill though. > src/hotspot/share/memory/arena.hpp line 41: > >> 39: >> 40: class ChunkPoolLocker : public StackObj { >> 41: public: > > Nitpick FYI: I think the new `public` has a different indentation than the old one. Just wanted to point it out, is this something that should be addressed? I do not have an opinion on the topic. For some reason, much of the code I've seen has one space for access modifiers, so I'm going to stick with that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2448048308 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2448046305 From phubner at openjdk.org Tue Oct 21 12:42:14 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 21 Oct 2025 12:42:14 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: <8oC7HhDj4XsujIafyDTqLNT1DqQktwKuWfXJ67O-Dl4=.30aa39ef-476f-4eaa-b3c0-57031aa4bbeb@github.com> On Tue, 21 Oct 2025 12:37:06 GMT, Coleen Phillimore wrote: >> src/hotspot/share/memory/arena.hpp line 41: >> >>> 39: >>> 40: class ChunkPoolLocker : public StackObj { >>> 41: public: >> >> Nitpick FYI: I think the new `public` has a different indentation than the old one. Just wanted to point it out, is this something that should be addressed? I do not have an opinion on the topic. > > For some reason, much of the code I've seen has one space for access modifiers, so I'm going to stick with that. @coleenp I meant that this indentation here is zero spaces, not one, as far as I can tell. But a very very minor thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2448056000 From dholmes at openjdk.org Tue Oct 21 12:46:25 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 12:46:25 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 [v2] In-Reply-To: References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: On Tue, 21 Oct 2025 02:15:28 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Un-ProblemList the test >> - Merge branch 'master' into 8370207-sem_notify-crash >> - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 > > Looks good. Thanks for the review @kimbarrett ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27888#issuecomment-3426417560 From coleenp at openjdk.org Tue Oct 21 12:49:37 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Oct 2025 12:49:37 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: <8oC7HhDj4XsujIafyDTqLNT1DqQktwKuWfXJ67O-Dl4=.30aa39ef-476f-4eaa-b3c0-57031aa4bbeb@github.com> References: <8oC7HhDj4XsujIafyDTqLNT1DqQktwKuWfXJ67O-Dl4=.30aa39ef-476f-4eaa-b3c0-57031aa4bbeb@github.com> Message-ID: On Tue, 21 Oct 2025 12:39:24 GMT, Paul H?bner wrote: >> For some reason, much of the code I've seen has one space for access modifiers, so I'm going to stick with that. > > @coleenp I meant that this indentation here is zero spaces, not one, as far as I can tell. But a very very minor thing. Sorry, I meant I'm going to fix it back to one space. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2448087051 From azafari at openjdk.org Tue Oct 21 13:27:43 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 21 Oct 2025 13:27:43 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 16:56:44 GMT, Ioi Lam wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix after wrong merge. > > src/hotspot/share/cds/archiveBuilder.cpp line 1116: > >> 1114: // As zero is allowed for new_bottom, use integer arithmetic to avoid UB pointer arithmetic. >> 1115: address new_bottom = (address)((uintptr_t)bottom + _buffer_to_requested_delta); >> 1116: address new_top = (address)((uintptr_t)top + _buffer_to_requested_delta); > > Have you see an actual ubsan error in here? > > `bottom` and `top` are never zeros, as they are from the actually allocated spaces in the output buffer. > > `new_top` should never be zero as we don't archive zero-sized objects. > > I think `new_bottom` will also never be zero as offset zero of the buffer does not contain a valid object, so we will never encode this location into an offset. For this line, the UB is non-null ptr + non-zero offset becomes 0, as this output shows: ----------System.err:(32/2579)---------- TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] stdout content[] stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43: runtime error: applying non-zero offset to non-null pointer 0x0003c0000000 produced null pointer #0 0x1076111f8 in RelocateBufferToRequested::RelocateBufferToRequested(ArchiveBuilder*) archiveBuilder.cpp:1104 #1 0x10760c67c in ArchiveBuilder::relocate_to_requested() archiveBuilder.cpp:1170 #2 0x1075ec2a0 in AOTMetaspace::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) aotMetaspace.cpp:1084 #3 0x1075eb120 in AOTMetaspace::dump_static_archive_impl(StaticArchiveBuilder&, JavaThread*) aotMetaspace.cpp:1067 #4 0x1075ea4cc in AOTMetaspace::dump_static_archive(JavaThread*) aotMetaspace.cpp:850 #5 0x108eb1820 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:903 #6 0x10847d40c in JNI_CreateJavaVM jni.cpp:3678 #7 0x102403a00 in JavaMain java.c:494 #8 0x10240a400 in ThreadJavaMain java_md_macosx.m:679 #9 0x19387fbc4 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6bc4) #10 0x19387ab7c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1b7c) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43 in ] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2448278581 From azafari at openjdk.org Tue Oct 21 13:42:50 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 21 Oct 2025 13:42:50 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 17:06:16 GMT, Ioi Lam wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix after wrong merge. > > src/hotspot/share/cds/archiveBuilder.cpp line 1047: > >> 1045: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { >> 1046: // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic. >> 1047: address requested_addr = (address)((uintptr_t)_requested_static_archive_bottom + offset); > > We should avoid this problem altogether with this: > > > - address requested_addr = _requested_static_archive_bottom + offset; > - address buffered_addr = requested_addr - _buffer_to_requested_delta; > - address buffered_addr = _buffer_bottom + offset; The error for this is: ----------System.err:(41/4910)---------- TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] stdout content[] stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1036:61: runtime error: applying non-zero offset 3723624 to null pointer #0 0x10930c0a4 in ArchiveBuilder::offset_to_buffered_address(unsigned int) const archiveBuilder.cpp:1036 #1 0x1095ce694 in RunTimeClassInfo::enum_klass_static_fields_addr() const runTimeClassInfo.hpp:163 #2 0x10a9337b4 in RunTimeClassInfo::init(DumpTimeClassInfo&) runTimeClassInfo.cpp:75 #3 0x10ab2af34 in CopySharedClassInfoToArchive::do_entry(InstanceKlass*, DumpTimeClassInfo&) systemDictionaryShared.cpp:1296 #4 0x10ab2abb4 in void DumpTimeSharedClassTable::iterate_all_live_classes(CopySharedClassInfoToArchive*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(CopySharedClassInfoToArchive) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)::operator()(InstanceKlass*, DumpTimeClassInfo&) const dumpTimeClassInfo.inline.hpp:51 #5 0x10ab2a9f4 in void HashTableBase, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate_all(InstanceKlass*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) const: :'lambda'(InstanceKlass*&, DumpTimeClassInfo&)>(InstanceKlass) const hashTable.hpp:273 #6 0x10ab2a914 in void DumpTimeSharedClassTable::iterate_all_live_classes(CopySharedClassInfoToArchive*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(CopySharedClassInfoToArchive) const dumpTimeClassInfo.inline.hpp:60 #7 0x10ab26c84 in SystemDictionaryShared::write_dictionary(RunTimeSharedDictionary*, bool) systemDictionaryShared.cpp:1327 #8 0x10ab26da0 in SystemDictionaryShared::write_to_archive(bool) systemDictionaryShared.cpp:1334 #9 0x1092e899c in VM_PopulateDumpSharedSpace::dump_read_only_tables(AOTClassLocationConfig*&) aotMetaspace.cpp:627 #10 0x1092e8ebc in VM_PopulateDumpSharedSpace::doit() aotMetaspace.cpp:696 #11 0x10acb7d18 in VM_Operation::evaluate() vmOperations.cpp:74 #12 0x10acd9694 in VMThread::evaluate_operation(VM_Operation*) vmThread.cpp:284 #13 0x10acda358 in VMThread::inner_execute(VM_Operation*) vmThread.cpp:421 #14 0x10acd92cc in VMThread::loop() vmThread.cpp:487 #15 0x10acd8ec8 in VMThread::run() vmThread.cpp:177 #16 0x10ab8dd64 in Thread::call_run() thread.cpp:243 #17 0x10a79e998 in thread_native_entry(Thread*) os_bsd.cpp:604 #18 0x19387fbc4 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6bc4) #19 0x19387ab7c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1b7c) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2448348759 From azafari at openjdk.org Tue Oct 21 13:42:51 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 21 Oct 2025 13:42:51 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 13:38:05 GMT, Afshin Zafari wrote: >> src/hotspot/share/cds/archiveBuilder.cpp line 1047: >> >>> 1045: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { >>> 1046: // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic. >>> 1047: address requested_addr = (address)((uintptr_t)_requested_static_archive_bottom + offset); >> >> We should avoid this problem altogether with this: >> >> >> - address requested_addr = _requested_static_archive_bottom + offset; >> - address buffered_addr = requested_addr - _buffer_to_requested_delta; >> - address buffered_addr = _buffer_bottom + offset; > > The error for this is: > > ----------System.err:(41/4910)---------- > TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] > stdout content[] > stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1036:61: runtime error: applying non-zero offset 3723624 to null pointer > #0 0x10930c0a4 in ArchiveBuilder::offset_to_buffered_address(unsigned int) const archiveBuilder.cpp:1036 > #1 0x1095ce694 in RunTimeClassInfo::enum_klass_static_fields_addr() const runTimeClassInfo.hpp:163 > #2 0x10a9337b4 in RunTimeClassInfo::init(DumpTimeClassInfo&) runTimeClassInfo.cpp:75 > #3 0x10ab2af34 in CopySharedClassInfoToArchive::do_entry(InstanceKlass*, DumpTimeClassInfo&) systemDictionaryShared.cpp:1296 > #4 0x10ab2abb4 in void DumpTimeSharedClassTable::iterate_all_live_classes(CopySharedClassInfoToArchive*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(CopySharedClassInfoToArchive) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)::operator()(InstanceKlass*, DumpTimeClassInfo&) const dumpTimeClassInfo.inline.hpp:51 > #5 0x10ab2a9f4 in void HashTableBase, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate_all(InstanceKlass*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) cons t::'lambda'(InstanceKlass*&, DumpTimeClassInfo&)>(InstanceKlass) const hashTable.hpp:273 > #6 0x10ab2a914 in void DumpTime... You may already noticed that the root of all these UB complains is the option `-XX:SharedBaseAddress` as zero which is a corner case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2448357081 From coleenp at openjdk.org Tue Oct 21 13:52:14 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Oct 2025 13:52:14 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: Message-ID: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add assert, fix access modifiers and add Afshin's test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27869/files - new: https://git.openjdk.org/jdk/pull/27869/files/9a27e598..9f1525db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27869&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27869&range=00-01 Stats: 20 lines in 3 files changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27869.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27869/head:pull/27869 PR: https://git.openjdk.org/jdk/pull/27869 From phubner at openjdk.org Tue Oct 21 13:52:14 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 21 Oct 2025 13:52:14 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 13:48:48 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add assert, fix access modifiers and add Afshin's test. Thank you for looking into this! Looks good. ------------- Marked as reviewed by phubner (Author). PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3360887586 From mbaesken at openjdk.org Tue Oct 21 14:35:28 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 21 Oct 2025 14:35:28 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: - Reformatting suggested by David - unneeded \ removed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/f0f4e57c..27a4ad6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=05-06 Stats: 30 lines in 3 files changed: 0 ins; 7 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From mbaesken at openjdk.org Tue Oct 21 15:18:32 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 21 Oct 2025 15:18:32 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v2] In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27899/files - new: https://git.openjdk.org/jdk/pull/27899/files/090fcf27..13a1b423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=00-01 Stats: 25 lines in 4 files changed: 23 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899 PR: https://git.openjdk.org/jdk/pull/27899 From iklam at openjdk.org Tue Oct 21 15:45:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 21 Oct 2025 15:45:01 GMT Subject: RFR: 8370248: AOTMapLogger should check if pointer is in AOTMetaspace Message-ID: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> This fixes a recent bug in `AOTMapLogger` that's exposed in macOS 26 testing. When running the JVM with a valid AOT cache (or AOT cache) with the flag `-Xlog:aot+map=debug`, we use `AOTMapLogger::RuntimeGatherArchivedMetaspaceObjs` to discover all metaspace objects that are contained in the AOT cache. However, this code is executed after some of the AOT-cached classes are linked. As a result, `RuntimeGatherArchivedMetaspaceObjs::do_unique_ref()` could see instances of `AdapterHandlerEntry` which are dynamically allocated and their addresses are outside of the AOT cache. In all platforms except macOS 26, the `AdapterHandlerEntry` pointers are all above the address range of the AOT cache, and they are filtered out by subsequent code in `AOTMapLogger`. However, on macOS 26, the `AdapterHandlerEntry` pointers are below the AOT cache, and they caused this assert to fail: https://github.com/openjdk/jdk/blob/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e/src/hotspot/share/cds/aotMapLogger.cpp#L240-L242 The fix is simple: filter out all pointers that are outside of the address range of the AOT cache in `do_unique_ref()`. ------------- Commit messages: - 8370248: AOTMapLogger should check if pointer is in AOTMetaspace Changes: https://git.openjdk.org/jdk/pull/27918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370248 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27918/head:pull/27918 PR: https://git.openjdk.org/jdk/pull/27918 From kvn at openjdk.org Tue Oct 21 16:05:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 21 Oct 2025 16:05:30 GMT Subject: RFR: 8370248: AOTMapLogger should check if pointer is in AOTMetaspace In-Reply-To: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> References: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> Message-ID: On Tue, 21 Oct 2025 15:37:06 GMT, Ioi Lam wrote: > This fixes a recent bug in `AOTMapLogger` that's exposed in macOS 26 testing. > > When running the JVM with a valid AOT cache (or AOT cache) with the flag `-Xlog:aot+map=debug`, we use `AOTMapLogger::RuntimeGatherArchivedMetaspaceObjs` to discover all metaspace objects that are contained in the AOT cache. > > However, this code is executed after some of the AOT-cached classes are linked. As a result, `RuntimeGatherArchivedMetaspaceObjs::do_unique_ref()` could see instances of `AdapterHandlerEntry` which are dynamically allocated and their addresses are outside of the AOT cache. > > In all platforms except macOS 26, the `AdapterHandlerEntry` pointers are all above the address range of the AOT cache, and they are filtered out by subsequent code in `AOTMapLogger`. However, on macOS 26, the `AdapterHandlerEntry` pointers are below the AOT cache, and they caused this assert to fail: > > https://github.com/openjdk/jdk/blob/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e/src/hotspot/share/cds/aotMapLogger.cpp#L240-L242 > > The fix is simple: filter out all pointers that are outside of the address range of the AOT cache in `do_unique_ref()`. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27918#pullrequestreview-3361548446 From adinn at openjdk.org Tue Oct 21 16:08:41 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 21 Oct 2025 16:08:41 GMT Subject: RFR: 8370248: AOTMapLogger should check if pointer is in AOTMetaspace In-Reply-To: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> References: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> Message-ID: On Tue, 21 Oct 2025 15:37:06 GMT, Ioi Lam wrote: > This fixes a recent bug in `AOTMapLogger` that's exposed in macOS 26 testing. > > When running the JVM with a valid AOT cache (or AOT cache) with the flag `-Xlog:aot+map=debug`, we use `AOTMapLogger::RuntimeGatherArchivedMetaspaceObjs` to discover all metaspace objects that are contained in the AOT cache. > > However, this code is executed after some of the AOT-cached classes are linked. As a result, `RuntimeGatherArchivedMetaspaceObjs::do_unique_ref()` could see instances of `AdapterHandlerEntry` which are dynamically allocated and their addresses are outside of the AOT cache. > > In all platforms except macOS 26, the `AdapterHandlerEntry` pointers are all above the address range of the AOT cache, and they are filtered out by subsequent code in `AOTMapLogger`. However, on macOS 26, the `AdapterHandlerEntry` pointers are below the AOT cache, and they caused this assert to fail: > > https://github.com/openjdk/jdk/blob/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e/src/hotspot/share/cds/aotMapLogger.cpp#L240-L242 > > The fix is simple: filter out all pointers that are outside of the address range of the AOT cache in `do_unique_ref()`. Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27918#pullrequestreview-3361564674 From matsaave at openjdk.org Tue Oct 21 16:47:32 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 21 Oct 2025 16:47:32 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 21:58:51 GMT, Chen Liang wrote: > Just curious, does this have any observable effect that can surface in a regression test? The initial reporter did not offer a test case that displays this issue and I have not been able to write such a test either. It looks like this code cannot be normally executed so I omitted a test case here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27904#issuecomment-3427647171 From bchristi at openjdk.org Tue Oct 21 17:38:42 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 21 Oct 2025 17:38:42 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 Message-ID: This brings in cpu25_10 changes. ------------- Commit messages: - 8360937: Enhance certificate handling - 8359454: Enhance String handling - 8356294: Enhance Path Factories - 8352637: Enhance bytecode verification The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/27922/files Stats: 225 lines in 15 files changed: 174 ins; 9 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/27922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27922/head:pull/27922 PR: https://git.openjdk.org/jdk/pull/27922 From kcr at openjdk.org Tue Oct 21 17:41:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Oct 2025 17:41:46 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian wrote: > This brings in cpu25_10 changes. You have the wrong hash for the HEAD of the merge. It should be `e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7`, so the PR title should be: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27922#issuecomment-3428190818 From kcr at openjdk.org Tue Oct 21 17:52:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Oct 2025 17:52:43 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian wrote: > This brings in cpu25_10 changes. Marked as reviewed by kcr (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27922#pullrequestreview-3361993121 From kcr at openjdk.org Tue Oct 21 17:52:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Oct 2025 17:52:44 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 17:39:34 GMT, Kevin Rushforth wrote: > the PR title should be: > > ``` > Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 > ``` nm. it is correct (not sure what I saw earlier). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27922#issuecomment-3428289570 From prr at openjdk.org Tue Oct 21 18:09:04 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Oct 2025 18:09:04 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 In-Reply-To: References: Message-ID: <5ENfgCBS3J-p3Y5MeFKr9iS3qeynVdYaVuCaBBqDqFA=.fea0376f-2eb3-47c4-af3b-a33e79a21456@github.com> On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian wrote: > This brings in cpu25_10 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27922#pullrequestreview-3362065525 From bchristi at openjdk.org Tue Oct 21 18:44:07 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 21 Oct 2025 18:44:07 GMT Subject: Integrated: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian wrote: > This brings in cpu25_10 changes. This pull request has now been integrated. Changeset: b68fa435 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/b68fa4354c1ba1826ec0bb8b6e0a81e2c01de6b0 Stats: 225 lines in 15 files changed: 174 ins; 9 del; 42 mod Merge Reviewed-by: kcr, prr ------------- PR: https://git.openjdk.org/jdk/pull/27922 From bchristi at openjdk.org Tue Oct 21 18:44:06 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 21 Oct 2025 18:44:06 GMT Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 [v2] In-Reply-To: References: Message-ID: > This brings in cpu25_10 changes. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27922/files - new: https://git.openjdk.org/jdk/pull/27922/files/e1d1fa91..e1d1fa91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27922&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27922&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27922/head:pull/27922 PR: https://git.openjdk.org/jdk/pull/27922 From coleenp at openjdk.org Tue Oct 21 20:25:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Oct 2025 20:25:03 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 [v2] In-Reply-To: References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: On Mon, 20 Oct 2025 07:38:18 GMT, David Holmes wrote: >> I missed that the `UserHandler` can still be used even if `-Xrs` is specified, so we have to check for `!ReduceSignalUsage` as per Kim's initial suggestion in JDK-8369631. >> >> Testing >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Un-ProblemList the test > - Merge branch 'master' into 8370207-sem_notify-crash > - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 Looks good. src/hotspot/os/posix/signals_posix.cpp line 365: > 363: AtomicAccess::inc(&pending_signals[sig]); > 364: sig_semaphore->signal(); > 365: } So this makes sense because the old code did get there: https://github.com/openjdk/jdk/commit/680414d0f9ab75d888bcb284cc494124a01a388f#diff-810ea508a8b69c83a17b3f641ac67d9b571324e0a7d66426e4a18580413b3d9aL172-L361 ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27888#pullrequestreview-3362578709 PR Review Comment: https://git.openjdk.org/jdk/pull/27888#discussion_r2449606171 From dholmes at openjdk.org Tue Oct 21 20:49:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 20:49:09 GMT Subject: RFR: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 [v2] In-Reply-To: References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: On Tue, 21 Oct 2025 20:22:09 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Un-ProblemList the test >> - Merge branch 'master' into 8370207-sem_notify-crash >> - 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 > > Looks good. Thanks for the review @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27888#issuecomment-3429497817 From dholmes at openjdk.org Tue Oct 21 20:52:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Oct 2025 20:52:43 GMT Subject: Integrated: 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 In-Reply-To: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> References: <0_Y-5x0y-hY9P2xllJJWNaHBPdHKtAuZNPehlZssUPo=.282f386e-0ef8-4b2d-ac22-7a24977529fd@github.com> Message-ID: <9BEsOioXOF1dd1Rz8MEB_d1afEecyftSm4-3_Py0Nq0=.3554dc13-7b6e-4353-ad6a-358f8deb470e@github.com> On Mon, 20 Oct 2025 06:47:51 GMT, David Holmes wrote: > I missed that the `UserHandler` can still be used even if `-Xrs` is specified, so we have to check for `!ReduceSignalUsage` as per Kim's initial suggestion in JDK-8369631. > > Testing > - tiers 1-4 > > Thanks This pull request has now been integrated. Changeset: aab3fc54 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/aab3fc54e6689dfa90ba097847a92d508c970be6 Stats: 7 lines in 2 files changed: 1 ins; 3 del; 3 mod 8370207: Test sun/misc/SunMiscSignalTest.java crashes after JDK-8369631 Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27888 From vlivanov at openjdk.org Tue Oct 21 21:11:01 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 21 Oct 2025 21:11:01 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 16:44:22 GMT, Matias Saavedra Silva wrote: > Just curious, does this have any observable effect that can surface in a regression test? I took a closer look and the bug is benign since, as the code is shaped now, it doesn't affect inlining decisions in any way. Indy instructions are linked to invokers which are force inlined and it overrides `AbstractInterpreter::is_not_reached() == true` case when it comes to deciding whether to inline through the indy call or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27904#issuecomment-3429557582 From sspitsyn at openjdk.org Wed Oct 22 01:52:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 22 Oct 2025 01:52:44 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v2] In-Reply-To: References: Message-ID: > This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. > > Testing: > - TBD: Run mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: remove now unneeded call to invalidate_jvmti_stack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27878/files - new: https://git.openjdk.org/jdk/pull/27878/files/c30793f3..1b5a0572 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27878/head:pull/27878 PR: https://git.openjdk.org/jdk/pull/27878 From sspitsyn at openjdk.org Wed Oct 22 02:00:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 22 Oct 2025 02:00:11 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v2] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 21:59:40 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: remove now unneeded call to invalidate_jvmti_stack > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1689: > >> 1687: log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); >> 1688: >> 1689: JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); > > Why not directly in `preempt_epilog`? Is it to cover the freeze fast case too? If that?s the case we should remove the call to `invalidate_jvmti_stack` from `jvmti_yield_cleanup` to avoid calling it twice for the freeze slow case. Also I wonder if this call to `invalidate_jvmti_stack` should just be moved to `JvmtiVTMSTransitionDisabler::VTMS_unmount_end` instead. Yes, I had in mind but forgot to remove the call to `invalidate_jvmti_stack()` from `jvmti_yield_cleanup()`. I've pushed the update now. > Also I wonder if this call to invalidate_jvmti_stack should just be moved to JvmtiVTMSTransitionDisabler::VTMS_unmount_end instead. Unfortunately, this is not going to work for plain/pure continuations as `mount/unmount` code path does not work for them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2450180606 From dholmes at openjdk.org Wed Oct 22 05:57:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 05:57:04 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 14:35:28 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: > > - Reformatting suggested by David > - unneeded \ removed Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3363805979 From iklam at openjdk.org Wed Oct 22 06:04:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 22 Oct 2025 06:04:12 GMT Subject: RFR: 8370248: AOTMapLogger should check if pointer is in AOTMetaspace In-Reply-To: References: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> Message-ID: On Tue, 21 Oct 2025 16:02:27 GMT, Vladimir Kozlov wrote: >> This fixes a recent bug in `AOTMapLogger` that's exposed in macOS 26 testing. >> >> When running the JVM with a valid AOT cache (or AOT cache) with the flag `-Xlog:aot+map=debug`, we use `AOTMapLogger::RuntimeGatherArchivedMetaspaceObjs` to discover all metaspace objects that are contained in the AOT cache. >> >> However, this code is executed after some of the AOT-cached classes are linked. As a result, `RuntimeGatherArchivedMetaspaceObjs::do_unique_ref()` could see instances of `AdapterHandlerEntry` which are dynamically allocated and their addresses are outside of the AOT cache. >> >> In all platforms except macOS 26, the `AdapterHandlerEntry` pointers are all above the address range of the AOT cache, and they are filtered out by subsequent code in `AOTMapLogger`. However, on macOS 26, the `AdapterHandlerEntry` pointers are below the AOT cache, and they caused this assert to fail: >> >> https://github.com/openjdk/jdk/blob/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e/src/hotspot/share/cds/aotMapLogger.cpp#L240-L242 >> >> The fix is simple: filter out all pointers that are outside of the address range of the AOT cache in `do_unique_ref()`. > > Good. Thanks @vnkozlov @adinn for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27918#issuecomment-3430614512 From iklam at openjdk.org Wed Oct 22 06:04:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 22 Oct 2025 06:04:13 GMT Subject: Integrated: 8370248: AOTMapLogger should check if pointer is in AOTMetaspace In-Reply-To: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> References: <39yQIBdA4cia4brQI-0UF0AFYRIr2h_c8KeZJchP4oo=.ac56a366-5115-4915-a8b7-d38075d51513@github.com> Message-ID: On Tue, 21 Oct 2025 15:37:06 GMT, Ioi Lam wrote: > This fixes a recent bug in `AOTMapLogger` that's exposed in macOS 26 testing. > > When running the JVM with a valid AOT cache (or AOT cache) with the flag `-Xlog:aot+map=debug`, we use `AOTMapLogger::RuntimeGatherArchivedMetaspaceObjs` to discover all metaspace objects that are contained in the AOT cache. > > However, this code is executed after some of the AOT-cached classes are linked. As a result, `RuntimeGatherArchivedMetaspaceObjs::do_unique_ref()` could see instances of `AdapterHandlerEntry` which are dynamically allocated and their addresses are outside of the AOT cache. > > In all platforms except macOS 26, the `AdapterHandlerEntry` pointers are all above the address range of the AOT cache, and they are filtered out by subsequent code in `AOTMapLogger`. However, on macOS 26, the `AdapterHandlerEntry` pointers are below the AOT cache, and they caused this assert to fail: > > https://github.com/openjdk/jdk/blob/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e/src/hotspot/share/cds/aotMapLogger.cpp#L240-L242 > > The fix is simple: filter out all pointers that are outside of the address range of the AOT cache in `do_unique_ref()`. This pull request has now been integrated. Changeset: 70e78615 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/70e786154fae78c0dacaa3e29c7aa4d3d14b892b Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod 8370248: AOTMapLogger should check if pointer is in AOTMetaspace Reviewed-by: kvn, adinn ------------- PR: https://git.openjdk.org/jdk/pull/27918 From mbaesken at openjdk.org Wed Oct 22 07:03:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 07:03:17 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 14:35:28 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: > > - Reformatting suggested by David > - unneeded \ removed Thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3430754445 From dholmes at openjdk.org Wed Oct 22 07:49:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 07:49:19 GMT Subject: RFR: 8369322: Implement native stack printing for Windows-AArch64 [v2] In-Reply-To: References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Mon, 20 Oct 2025 21:48:28 GMT, Martijn Verburg wrote: >> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix style nits > > Marked as reviewed by karianna (no project role). I'm okay with @karianna being the second "reviewer". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27680#issuecomment-3430871748 From duke at openjdk.org Wed Oct 22 07:49:20 2025 From: duke at openjdk.org (Saint Wesonga) Date: Wed, 22 Oct 2025 07:49:20 GMT Subject: Integrated: 8369322: Implement native stack printing for Windows-AArch64 In-Reply-To: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> References: <3iDJOAbqpBKcoOssm9fR-N7m9r9qvTlyk-eLngsYTT0=.6b0e601d-9d22-4f71-aa20-af757fc4863d@github.com> Message-ID: On Tue, 7 Oct 2025 22:19:47 GMT, Saint Wesonga wrote: > HAVE_PLATFORM_PRINT_NATIVE_STACK is not defined on Windows AArch64. Consequently, Windows AArch64 uses the [implementation of os::platform_print_native_stack that returns false](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/runtime/os.inline.hpp#L36-L41). This results in [NativeStackPrinter::print_stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.cpp#L32) having to call [NativeStackPrinter::print_stack_from_frame](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L99-L106) instead. However, the context is null in that case. As a result, the [frame used for printing the stack](https://github.com/openjdk/jdk/blob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/share/utilities/nativeStackPrinter.hpp#L103) is obtained from [os::current_frame()](https://github.com/openjdk/jdk/b lob/b50c11f9077f071cf5639de7e82ec261e0338532/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L165-L168), which returns an empty frame. The frame's pc() method returns `nullptr` and `Native frames: ` is printed. > > This change defines the `os::platform_print_native_stack` method for Windows AArch64 and adapts the implementation of the Windows x64 `os::win32::platform_print_native_stack` method to support Windows AArch64. This pull request has now been integrated. Changeset: eff4b110 Author: Saint Wesonga Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/eff4b1103396dc8e383d86472435ff983e298b61 Stats: 202 lines in 3 files changed: 110 ins; 92 del; 0 mod 8369322: Implement native stack printing for Windows-AArch64 Reviewed-by: dholmes, karianna ------------- PR: https://git.openjdk.org/jdk/pull/27680 From goetz at openjdk.org Wed Oct 22 07:52:45 2025 From: goetz at openjdk.org (Goetz Lindenmaier) Date: Wed, 22 Oct 2025 07:52:45 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: References: Message-ID: <_-Nqo_2hkKL6SZ-GciYeTO5Z1L7gmk24afPF9A3vaSs=.3e0c8114-24fe-4a5a-8655-147648770e15@github.com> On Tue, 21 Oct 2025 14:35:28 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: > > - Reformatting suggested by David > - unneeded \ removed A general remark: A few messages start with a capital letter. Personally, I prefer proper sentences or text close to that, but I think it is more common in the code base to not capitalize single phrases. Maybe we can harmonize this here, as we touch the messages anyways. Also, I think the JBS issue should be Enhancement, and I would appreciate a sentence in the description of how to retrieve the messages after the change. src/hotspot/os/posix/perfMemory_posix.cpp line 1042: > 1040: > 1041: if (mapAddress == MAP_FAILED) { > 1042: log_debug(perf)("mmap failed - %s", os::strerror(errno)); You might fix the double whitespace here ... or is this intended? src/hotspot/os/windows/perfMemory_windows.cpp line 99: > 97: if (fd == OS_ERR) { > 98: log_debug(perf)("Could not create Perfdata save file: %s: %s", > 99: destfile, os::strerror(errno)); Should we spell Perfdata camel-case as above? src/hotspot/os/windows/perfMemory_windows.cpp line 105: > 103: int nbytes = ::_write(fd, addr, (unsigned int)remaining); > 104: if (nbytes == OS_ERR) { > 105: log_debug(perf)("Could not write Perfdata save file: %s: %s", Camel-case? src/hotspot/os/windows/perfMemory_windows.cpp line 246: > 244: // > 245: log_debug(perf)("%s is not a directory, file attributes = " > 246: INTPTR_FORMAT, path, fa); Maybe use : instead of = for consistency src/hotspot/os/windows/perfMemory_windows.cpp line 1176: > 1174: if (!SetFileSecurity(dirname, secInfo, pDirSA->lpSecurityDescriptor)) { > 1175: lasterror = GetLastError(); > 1176: log_debug(perf)("SetFileSecurity failed for %s directory. lasterror %d", dirname, lasterror); Maybe add = after lasterror. ------------- PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3364026379 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450685542 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450724408 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450724966 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450730281 PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450736621 From dholmes at openjdk.org Wed Oct 22 07:56:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 07:56:03 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 13:52:14 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add assert, fix access modifiers and add Afshin's test. A couple of nitty suggestions but nothing essential. src/hotspot/share/memory/arena.cpp line 53: > 51: _locked = true; > 52: } else { > 53: precond(ls == LockStrategy::Try); Nit: this isn't really a "precond", it is just an assert. src/hotspot/share/memory/arena.hpp line 44: > 42: enum class LockStrategy { Lock, Try }; > 43: private: > 44: bool _locked; Nit: if you place this first you can save one of the "public"s. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3364108739 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2450751142 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2450753191 From dholmes at openjdk.org Wed Oct 22 07:56:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 07:56:06 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: <1Z6wggZ2A6MMmzFvsAIZCe3JfQzKQ-PE5I3c6wt03Q8=.db019656-1e28-474f-a2f0-db6829c08750@github.com> Message-ID: <6sIyedBOQfUdL52i5xlUXQ9MXJg38ycgvNiPW3daI8A=.b7dfbe93-ca3c-4cb2-b71b-f89c85beb021@github.com> On Mon, 20 Oct 2025 12:23:07 GMT, Coleen Phillimore wrote: >> src/hotspot/share/nmt/mallocTracker.cpp line 71: >> >>> 69: if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) { >>> 70: ls = ChunkPoolLocker::LockStrategy::Try; >>> 71: } >> >> Thinking more, we could simply always do this check in the constructor and do away with the "strategy" flag altogether. Arguably this would be reasonable behaviour for every Mutexlocker (though it may slow things down a little). > > I had a version that did this but Johan was worried about global behavior so wanted to limit it to just NMT reporting on error to be safe. Okay. Worth having a discussion whether all "lockers" should adopt this error reporting behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2450756082 From mbaesken at openjdk.org Wed Oct 22 08:27:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 08:27:39 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v8] In-Reply-To: References: Message-ID: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust following suggestions by Goetz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27602/files - new: https://git.openjdk.org/jdk/pull/27602/files/27a4ad6d..a9addba3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27602&range=06-07 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27602/head:pull/27602 PR: https://git.openjdk.org/jdk/pull/27602 From mbaesken at openjdk.org Wed Oct 22 08:27:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 08:27:41 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 14:35:28 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: > > - Reformatting suggested by David > - unneeded \ removed I added one more commit following the suggestions from Goetz . ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3431050398 From mbaesken at openjdk.org Wed Oct 22 08:27:42 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 08:27:42 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v7] In-Reply-To: <_-Nqo_2hkKL6SZ-GciYeTO5Z1L7gmk24afPF9A3vaSs=.3e0c8114-24fe-4a5a-8655-147648770e15@github.com> References: <_-Nqo_2hkKL6SZ-GciYeTO5Z1L7gmk24afPF9A3vaSs=.3e0c8114-24fe-4a5a-8655-147648770e15@github.com> Message-ID: On Wed, 22 Oct 2025 07:40:50 GMT, Goetz Lindenmaier wrote: >> Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision: >> >> - Reformatting suggested by David >> - unneeded \ removed > > src/hotspot/os/windows/perfMemory_windows.cpp line 105: > >> 103: int nbytes = ::_write(fd, addr, (unsigned int)remaining); >> 104: if (nbytes == OS_ERR) { >> 105: log_debug(perf)("Could not write Perfdata save file: %s: %s", > > Camel-case? Probably yes; it is a bit inconsistent , in perfMemory.cpp we once write 'performance data file path name specified' in some messages. But mostly we write PerfData . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27602#discussion_r2450883022 From cnorrbin at openjdk.org Wed Oct 22 08:58:15 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 22 Oct 2025 08:58:15 GMT Subject: RFR: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu Message-ID: Hi everyone, The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. Testing: - Repeated runs of `TestSystemMetrics.java` without any observed failures. - Oracle tiers 1-5 ------------- Commit messages: - changed io.stat to use < Changes: https://git.openjdk.org/jdk/pull/27934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313770 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27934/head:pull/27934 PR: https://git.openjdk.org/jdk/pull/27934 From sgehwolf at openjdk.org Wed Oct 22 09:14:41 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 22 Oct 2025 09:14:41 GMT Subject: RFR: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:49:07 GMT, Casper Norrbin wrote: > Hi everyone, > > The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. > > The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. > > For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. > > Testing: > - Repeated runs of `TestSystemMetrics.java` without any observed failures. > - Oracle tiers 1-5 Looks good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27934#pullrequestreview-3364548250 From dholmes at openjdk.org Wed Oct 22 09:14:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 09:14:44 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v2] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Tue, 21 Oct 2025 15:18:32 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test make/hotspot/lib/CompileJvm.gmk line 163: > 161: ifeq ($(SHIP_DEBUG_SYMBOLS), public) > 162: JVM_CFLAGS += -DHAS_STRIPPED_DEBUGINFO > 163: endif But IIUC building the stripped pdb files doesn't necessarily mean you have deployed them in your image. Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27899#discussion_r2451097941 From goetz at openjdk.org Wed Oct 22 09:39:13 2025 From: goetz at openjdk.org (Goetz Lindenmaier) Date: Wed, 22 Oct 2025 09:39:13 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v8] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:27:39 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust following suggestions by Goetz Thanks for the improvements! ------------- Marked as reviewed by goetz (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3364695319 From dholmes at openjdk.org Wed Oct 22 09:51:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 09:51:56 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v8] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:27:39 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust following suggestions by Goetz Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27602#pullrequestreview-3364794303 From mbaesken at openjdk.org Wed Oct 22 11:14:42 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 11:14:42 GMT Subject: RFR: 8368781: PerfMemory - make issues more transparent [v8] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:27:39 GMT, Matthias Baesken wrote: >> Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. >> >> There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. >> We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust following suggestions by Goetz Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27602#issuecomment-3431845454 From mbaesken at openjdk.org Wed Oct 22 11:14:43 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 11:14:43 GMT Subject: Integrated: 8368781: PerfMemory - make issues more transparent In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 08:25:52 GMT, Matthias Baesken wrote: > Currently issues with perfMemory like problems with the secure tmp subdirectory creation are not very transparent in release JVMs. > > There exists some warnings traces but they are behind develop flags like Verbose so only available in debug JVMs. > We could (in case of issues) store some information and write it later into hsinfo/hserr files ; or make the existing warnings available too in release JVMs. This pull request has now been integrated. Changeset: 763d4252 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/763d4252f8228adb822f6f4ad2d943e8cffb5b18 Stats: 242 lines in 3 files changed: 5 ins; 140 del; 97 mod 8368781: PerfMemory - make issues more transparent Reviewed-by: dholmes, goetz ------------- PR: https://git.openjdk.org/jdk/pull/27602 From mbaesken at openjdk.org Wed Oct 22 11:28:05 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 11:28:05 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v2] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Tue, 21 Oct 2025 15:18:32 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test > But IIUC building the stripped pdb files doesn't necessarily mean you have deployed them in your image. True, but in the end you have the stripped pdbs in place so it is possible you test with those and the test fails (for a good reason). It is better than ALWAYS switching off the source file name check on Windows . > Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp? Yes I could do this, if you prefer ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3431898876 From mbaesken at openjdk.org Wed Oct 22 11:39:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 11:39:59 GMT Subject: RFR: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:49:07 GMT, Casper Norrbin wrote: > Hi everyone, > > The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. > > The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. > > For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. > > Testing: > - Repeated runs of `TestSystemMetrics.java` without any observed failures. > - Oracle tiers 1-5 Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27934#pullrequestreview-3365391980 From coleenp at openjdk.org Wed Oct 22 12:17:30 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Oct 2025 12:17:30 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 07:51:00 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add assert, fix access modifiers and add Afshin's test. > > src/hotspot/share/memory/arena.cpp line 53: > >> 51: _locked = true; >> 52: } else { >> 53: precond(ls == LockStrategy::Try); > > Nit: this isn't really a "precond", it is just an assert. I thought precond was another way of writing assert when there's no meaningful message in the assert, which is why I used it but the name isn't really good here so I'll change it. > src/hotspot/share/memory/arena.hpp line 44: > >> 42: enum class LockStrategy { Lock, Try }; >> 43: private: >> 44: bool _locked; > > Nit: if you place this first you can save one of the "public"s. Done. I agree, I was going to do this - thanks for the push. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2451882989 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2451883796 From coleenp at openjdk.org Wed Oct 22 12:24:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Oct 2025 12:24:04 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Small things. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27869/files - new: https://git.openjdk.org/jdk/pull/27869/files/9f1525db..dabd2083 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27869&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27869&range=01-02 Stats: 6 lines in 2 files changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27869.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27869/head:pull/27869 PR: https://git.openjdk.org/jdk/pull/27869 From phubner at openjdk.org Wed Oct 22 12:39:16 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 22 Oct 2025 12:39:16 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: <8c45jjWHCUyKq0jrJHTXhKPcDt61FpmiYXOSw4PElvc=.f84daf1c-1eef-414c-a8aa-c9c4478089b0@github.com> On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Marked as reviewed by phubner (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3365582724 From coleenp at openjdk.org Wed Oct 22 12:39:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Oct 2025 12:39:18 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: <6sIyedBOQfUdL52i5xlUXQ9MXJg38ycgvNiPW3daI8A=.b7dfbe93-ca3c-4cb2-b71b-f89c85beb021@github.com> References: <1Z6wggZ2A6MMmzFvsAIZCe3JfQzKQ-PE5I3c6wt03Q8=.db019656-1e28-474f-a2f0-db6829c08750@github.com> <6sIyedBOQfUdL52i5xlUXQ9MXJg38ycgvNiPW3daI8A=.b7dfbe93-ca3c-4cb2-b71b-f89c85beb021@github.com> Message-ID: On Wed, 22 Oct 2025 07:52:56 GMT, David Holmes wrote: >> I had a version that did this but Johan was worried about global behavior so wanted to limit it to just NMT reporting on error to be safe. > > Okay. Worth having a discussion whether all "lockers" should adopt this error reporting behaviour. yeah. Not sure about that for this lock or in general. Right now it's ad-hoc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2451942456 From mbaesken at openjdk.org Wed Oct 22 12:48:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Oct 2025 12:48:46 GMT Subject: RFR: 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly Message-ID: We have some 'at runtime' checks for availability of SetSecurityDescriptorControl in the Windows perfmemory coding. But those were done for very old Windows versions like Win98 and can probably be removed. Looking at the description https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol it is available at least since Win2003/XP so the function can be called directly. ------------- Commit messages: - JDK-8370065 Changes: https://git.openjdk.org/jdk/pull/27937/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370065 Stats: 26 lines in 1 file changed: 0 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27937/head:pull/27937 PR: https://git.openjdk.org/jdk/pull/27937 From fbredberg at openjdk.org Wed Oct 22 13:03:13 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 22 Oct 2025 13:03:13 GMT Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out [v3] In-Reply-To: References: Message-ID: <6W6_cnySvMJeXPC2eeF8kpqQP7KDp4PfnMvdGKw5t5I=.3ab29373-0653-4dad-9478-ffd98a3d117b@github.com> On Fri, 3 Oct 2025 15:02:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail. >> >> I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - Remove extra space > - Remove finally block Seems like a step in the right direction. Thank you for fixing. ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27582#pullrequestreview-3365694117 From coleenp at openjdk.org Wed Oct 22 13:23:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Oct 2025 13:23:11 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: <77gTRLaBctQ4vbTmxxIPJDXhlRA7CDYmtQEadkUiaVw=.7116d60d-7110-4ee2-87e0-8306e40da812@github.com> On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Thanks for reviewing David and Paul. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27869#issuecomment-3432338876 From pchilanomate at openjdk.org Wed Oct 22 19:02:59 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 22 Oct 2025 19:02:59 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v2] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 01:57:09 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1689: >> >>> 1687: log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); >>> 1688: >>> 1689: JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); >> >> Why not directly in `preempt_epilog`? Is it to cover the freeze fast case too? If that?s the case we should remove the call to `invalidate_jvmti_stack` from `jvmti_yield_cleanup` to avoid calling it twice for the freeze slow case. Also I wonder if this call to `invalidate_jvmti_stack` should just be moved to `JvmtiVTMSTransitionDisabler::VTMS_unmount_end` instead. > > Thank you for the comment! Yes, I had in mind but forgot to remove the call to `invalidate_jvmti_stack()` from `jvmti_yield_cleanup()`. I've pushed the update now. > >> Also I wonder if this call to invalidate_jvmti_stack should just be moved to JvmtiVTMSTransitionDisabler::VTMS_unmount_end instead. > > Unfortunately, this is not going to work for plain/pure continuations as `mount/unmount` code path does not work for them. I see. What do you think about adding `invalidate_jvmti_stack` in `jvmti_yield_cleanup` if `!cont.entry()->is_virtual_thread()` is true to address that case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2453080175 From matsaave at openjdk.org Wed Oct 22 19:06:41 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Oct 2025 19:06:41 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic [v2] In-Reply-To: References: Message-ID: > This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Vladimir comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27904/files - new: https://git.openjdk.org/jdk/pull/27904/files/192a658b..23bddcbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27904&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27904&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27904/head:pull/27904 PR: https://git.openjdk.org/jdk/pull/27904 From vlivanov at openjdk.org Wed Oct 22 19:15:11 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 22 Oct 2025 19:15:11 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic [v2] In-Reply-To: References: Message-ID: <5ZYwAGcM0A05yRo-uiPZ_zcUdUGw_xXLfnYK96xPJBI=.f63d8505-6d57-4fef-947e-4309e3b82cb6@github.com> On Wed, 22 Oct 2025 19:06:41 GMT, Matias Saavedra Silva wrote: >> This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Vladimir comment Looks good and trivial. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27904#pullrequestreview-3367205132 From sspitsyn at openjdk.org Wed Oct 22 20:17:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 22 Oct 2025 20:17:42 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: Message-ID: > This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. > > Testing: > - TBD: Run mach5 tiers 1-6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - review: remove now unneeded call to invalidate_jvmti_stack - 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27878/files - new: https://git.openjdk.org/jdk/pull/27878/files/1b5a0572..3edebdbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=01-02 Stats: 11382 lines in 303 files changed: 7359 ins; 1828 del; 2195 mod Patch: https://git.openjdk.org/jdk/pull/27878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27878/head:pull/27878 PR: https://git.openjdk.org/jdk/pull/27878 From sspitsyn at openjdk.org Wed Oct 22 20:29:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 22 Oct 2025 20:29:48 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 19:00:10 GMT, Patricio Chilano Mateo wrote: >> Thank you for the comment! Yes, I had in mind but forgot to remove the call to `invalidate_jvmti_stack()` from `jvmti_yield_cleanup()`. I've pushed the update now. >> >>> Also I wonder if this call to invalidate_jvmti_stack should just be moved to JvmtiVTMSTransitionDisabler::VTMS_unmount_end instead. >> >> Unfortunately, this is not going to work for plain/pure continuations as `mount/unmount` code path does not work for them. > > I see. What do you think about adding `invalidate_jvmti_stack` in `jvmti_yield_cleanup` if `!cont.entry()->is_virtual_thread()` is true to address that case? Good idea! It'd be nice to move the `invalidate_jvmti_stack()` calls out of the continuation code. I'll test it and let you know the results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2453275806 From matsaave at openjdk.org Wed Oct 22 21:09:40 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Oct 2025 21:09:40 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 21:08:01 GMT, Vladimir Ivanov wrote: >>> Just curious, does this have any observable effect that can surface in a regression test? >> >> The initial reporter did not offer a test case that displays this issue and I have not been able to write such a test either. It looks like this code cannot be normally executed so I omitted a test case here. > >> Just curious, does this have any observable effect that can surface in a regression test? > > I took a closer look and the bug is benign since, as the code is shaped now, it doesn't affect inlining decisions in any way. Indy instructions are linked to invokers which are force inlined and it overrides `AbstractInterpreter::is_not_reached() == true` case when it comes to deciding whether to inline through the indy call or not. Thanks for the review @iwanowww! I agree that this change is trivial so one review is sufficient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27904#issuecomment-3434199028 From matsaave at openjdk.org Wed Oct 22 21:09:41 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Oct 2025 21:09:41 GMT Subject: Integrated: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: <5rVvve3G_YyPOnW4LZ_0Yrpzshq_WA3bQeWo34ozBMU=.877e8f12-e3bf-4179-b46a-1c35929ca607@github.com> On Mon, 20 Oct 2025 20:29:11 GMT, Matias Saavedra Silva wrote: > This is a trivial change to return the output of `AbstractInterpreter::is_not_reached` in the invokedynamic case to its behavior before [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995). Verified with tier 1-5 tests. This pull request has now been integrated. Changeset: 45e145fa Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/45e145fac2abc90faa56679336ddea4a8cd05446 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic Reviewed-by: vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/27904 From dholmes at openjdk.org Wed Oct 22 21:50:21 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Oct 2025 21:50:21 GMT Subject: RFR: 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:40:58 GMT, Matthias Baesken wrote: > We have some 'at runtime' checks for availability of SetSecurityDescriptorControl in the Windows perfmemory coding. But those were done for very old Windows versions like Win98 and can probably be removed. > Looking at the description > https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol > it is available at least since Win2003/XP so the function can be called directly. This seems fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27937#pullrequestreview-3367641228 From iklam at openjdk.org Wed Oct 22 22:18:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 22 Oct 2025 22:18:36 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 13:39:38 GMT, Afshin Zafari wrote: >> The error for this is: >> >> ----------System.err:(41/4910)---------- >> TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] >> stdout content[] >> stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1036:61: runtime error: applying non-zero offset 3723624 to null pointer >> #0 0x10930c0a4 in ArchiveBuilder::offset_to_buffered_address(unsigned int) const archiveBuilder.cpp:1036 >> #1 0x1095ce694 in RunTimeClassInfo::enum_klass_static_fields_addr() const runTimeClassInfo.hpp:163 >> #2 0x10a9337b4 in RunTimeClassInfo::init(DumpTimeClassInfo&) runTimeClassInfo.cpp:75 >> #3 0x10ab2af34 in CopySharedClassInfoToArchive::do_entry(InstanceKlass*, DumpTimeClassInfo&) systemDictionaryShared.cpp:1296 >> #4 0x10ab2abb4 in void DumpTimeSharedClassTable::iterate_all_live_classes(CopySharedClassInfoToArchive*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(CopySharedClassInfoToArchive) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)::operator()(InstanceKlass*, DumpTimeClassInfo&) const dumpTimeClassInfo.inline.hpp:51 >> #5 0x10ab2a9f4 in void HashTableBase, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate, InstanceKlass*, DumpTimeClassInfo, (AnyObj::allocation_type)2, (MemTag)13, &unsigned int DumpTimeSharedClassTable_hash(InstanceKlass* const&), &bool primitive_equals(InstanceKlass const&, InstanceKlass const&)>::iterate_all(InstanceKlass*) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) const::'lambda'(InstanceKlass*, DumpTimeClassInfo&)>(InstanceKlass) con st::'lambda'(InstanceKlass*&, DumpTimeClassInfo&)>(InstanceKlass) const hashTable.hpp:273 >> #6 0x... > > You may already noticed that the root of all these UB complains is the option `-XX:SharedBaseAddress` as zero which is a corner case. Sorry, my suggested fix had a typo: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { - address requested_addr = _requested_static_archive_bottom + offset; - address buffered_addr = requested_addr - _buffer_to_requested_delta; + address buffered_addr = _buffer_bottom + offset; This way this function will not depend on `-XX:SharedBaseAddress` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2453470972 From iklam at openjdk.org Wed Oct 22 22:18:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 22 Oct 2025 22:18:38 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: <5ZUsKd_RPtNYuy28mXxQqvdN9mGLP_5Xlp_U9TZRhQY=.0ffd3d80-b38b-4137-81b8-dab0eef9e8d9@github.com> On Tue, 21 Oct 2025 13:25:24 GMT, Afshin Zafari wrote: >> src/hotspot/share/cds/archiveBuilder.cpp line 1116: >> >>> 1114: // As zero is allowed for new_bottom, use integer arithmetic to avoid UB pointer arithmetic. >>> 1115: address new_bottom = (address)((uintptr_t)bottom + _buffer_to_requested_delta); >>> 1116: address new_top = (address)((uintptr_t)top + _buffer_to_requested_delta); >> >> Have you see an actual ubsan error in here? >> >> `bottom` and `top` are never zeros, as they are from the actually allocated spaces in the output buffer. >> >> `new_top` should never be zero as we don't archive zero-sized objects. >> >> I think `new_bottom` will also never be zero as offset zero of the buffer does not contain a valid object, so we will never encode this location into an offset. > > For this line, the UB is non-null ptr + non-zero offset becomes 0, as this output shows: > > ----------System.err:(32/2579)---------- > TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] > stdout content[] > stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43: runtime error: applying non-zero offset to non-null pointer 0x0003c0000000 produced null pointer > #0 0x1076111f8 in RelocateBufferToRequested::RelocateBufferToRequested(ArchiveBuilder*) archiveBuilder.cpp:1104 > #1 0x10760c67c in ArchiveBuilder::relocate_to_requested() archiveBuilder.cpp:1170 > #2 0x1075ec2a0 in AOTMetaspace::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) aotMetaspace.cpp:1084 > #3 0x1075eb120 in AOTMetaspace::dump_static_archive_impl(StaticArchiveBuilder&, JavaThread*) aotMetaspace.cpp:1067 > #4 0x1075ea4cc in AOTMetaspace::dump_static_archive(JavaThread*) aotMetaspace.cpp:850 > #5 0x108eb1820 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:903 > #6 0x10847d40c in JNI_CreateJavaVM jni.cpp:3678 > #7 0x102403a00 in JavaMain java.c:494 > #8 0x10240a400 in ThreadJavaMain java_md_macosx.m:679 > #9 0x19387fbc4 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6bc4) > #10 0x19387ab7c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1b7c) > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43 in > ] I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2453472914 From sspitsyn at openjdk.org Wed Oct 22 22:43:17 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 22 Oct 2025 22:43:17 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 20:27:26 GMT, Serguei Spitsyn wrote: >> I see. What do you think about adding `invalidate_jvmti_stack` in `jvmti_yield_cleanup` if `!cont.entry()->is_virtual_thread()` is true to address that case? > > Good idea! It'd be nice to move the `invalidate_jvmti_stack()` calls out of the continuation code. I'll test it and let you know the results. Strangely, the test `serviceability/jvmti/vthread/ContStackDepthTest` is failing with the `assert(_cur_stack_depth == num_frames)`. Obviously, some of the code paths is missed to call `invalidate_jvmti_stack()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2453509024 From dholmes at openjdk.org Thu Oct 23 00:29:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Oct 2025 00:29:14 GMT Subject: RFR: 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 21:05:02 GMT, Matias Saavedra Silva wrote: >>> Just curious, does this have any observable effect that can surface in a regression test? >> >> I took a closer look and the bug is benign since, as the code is shaped now, it doesn't affect inlining decisions in any way. Indy instructions are linked to invokers which are force inlined and it overrides `AbstractInterpreter::is_not_reached() == true` case when it comes to deciding whether to inline through the indy call or not. > > Thanks for the review @iwanowww! > I agree that this change is trivial so one review is sufficient. As a point-of-order @matias9927 and @iwanowww "simple" does not imply "trivial" from a reviewing perspective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27904#issuecomment-3434652370 From dholmes at openjdk.org Thu Oct 23 01:04:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Oct 2025 01:04:02 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Thanks for the tweaks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3367953478 From dholmes at openjdk.org Thu Oct 23 01:07:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Oct 2025 01:07:10 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v2] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:14:22 GMT, Coleen Phillimore wrote: >> src/hotspot/share/memory/arena.cpp line 53: >> >>> 51: _locked = true; >>> 52: } else { >>> 53: precond(ls == LockStrategy::Try); >> >> Nit: this isn't really a "precond", it is just an assert. > > I thought precond was another way of writing assert when there's no meaningful message in the assert, which is why I used it but the name isn't really good here so I'll change it. Thanks. `precond(foo)` is an alternative for checking preconditions (upon method entry) where the assert would typically look like `assert(foo, "precondition")` or `assert(foo, "must be")`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2453678316 From dholmes at openjdk.org Thu Oct 23 01:10:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Oct 2025 01:10:10 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v2] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Wed, 22 Oct 2025 11:25:17 GMT, Matthias Baesken wrote: > > Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp? > > Yes I could do this, if you prefer ? Please - best to always do the most minimal build change. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3434724364 From sspitsyn at openjdk.org Thu Oct 23 03:59:02 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 23 Oct 2025 03:59:02 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 22:40:16 GMT, Serguei Spitsyn wrote: >> Good idea! It'd be nice to move the `invalidate_jvmti_stack()` calls out of the continuation code. I'll test it and let you know the results. > > Strangely, the test `serviceability/jvmti/vthread/ContStackDepthTest` is failing with the `assert(_cur_stack_depth == num_frames)`. Obviously, some of the code paths is missed to call `invalidate_jvmti_stack()`. As I see, the calls to `invalidate_jvmti_stack()` are needed for plain continuations only (under condition `if !cont.entry()->is_virtual_thread()`). The following patch does not cause regressions in mach5 tier 6 (mach5 tiers 1-5 are in progress): diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp index 0884fce2ff7..dbbf5526602 100644 --- a/src/hotspot/share/prims/jvmtiExport.cpp +++ b/src/hotspot/share/prims/jvmtiExport.cpp @@ -1711,7 +1711,6 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati if (state == nullptr) { return; } - state->invalidate_cur_stack_depth(); // Clear frame_pop requests in frames popped by yield if (can_post_frame_pop()) { diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 0750f611876..b7c0c1f3f07 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -1626,11 +1626,14 @@ static void invalidate_jvmti_stack(JavaThread* thread) { } static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { - int num_frames = num_java_frames(cont); + if (!cont.entry()->is_virtual_thread()) { + invalidate_jvmti_stack(thread); + if (JvmtiExport::has_frame_pops(thread)) { + int num_frames = num_java_frames(cont); - ContinuationWrapper::SafepointOp so(Thread::current(), cont); - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); + ContinuationWrapper::SafepointOp so(Thread::current(), cont); + JvmtiExport::continuation_yield_cleanup(thread, num_frames); + } } } @@ -1685,7 +1688,7 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); + JVMTI_ONLY(if (!cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(JavaThread::current())); return freeze_ok; } @@ -1697,7 +1700,7 @@ static freeze_result freeze_epilog(JavaThread* thread, ContinuationWrapper& cont return res; } - JVMTI_ONLY(jvmti_yield_cleanup(thread, cont)); // can safepoint + JVMTI_ONLY(if (!cont.entry()->is_virtual_thread()) jvmti_yield_cleanup(thread, cont)); // can safepoint return freeze_epilog(cont); } @@ -2311,7 +2314,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t assert(_cont.chunk_invariant(), ""); - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); _thread->set_cont_fastpath(_fastpath); ``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2453856096 From syan at openjdk.org Thu Oct 23 06:02:02 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 23 Oct 2025 06:02:02 GMT Subject: RFR: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:49:07 GMT, Casper Norrbin wrote: > Hi everyone, > > The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. > > The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. > > For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. > > Testing: > - Repeated runs of `TestSystemMetrics.java` without any observed failures. > - Oracle tiers 1-5 Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27934#pullrequestreview-3368339730 From azafari at openjdk.org Thu Oct 23 07:13:18 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 23 Oct 2025 07:13:18 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Thank you Coleen, for taking this PR. All good. src/hotspot/share/memory/arena.hpp line 46: > 44: bool _locked; > 45: public: > 46: ChunkPoolLocker(LockStrategy ls = LockStrategy::Lock); If the `LockStrategy` is defaulted to `Lock`, then all the instances of this lock used in `ChunkPool`'s cleaning functions (`return_to_pool`, `take_from_pool`, `prune` and `deallocate_chunk`) would try to lock this explicitly. So, when either of these called while NMT is reporting (acquired the lock), we have deadlock again. src/hotspot/share/nmt/nmtUsage.cpp line 67: > 65: } > 66: ChunkPoolLocker cpl(ls); > 67: ms = MallocMemorySummary::as_snapshot(); Preexisting: The `MMS::as_snapshot()` just returns the pointer to the snapshot structure and does not update/access anything there. The life time of the `ChunkPoolLocker cpl` should be the whole body of the function. ------------- Marked as reviewed by azafari (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3360152979 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2447860103 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2447834489 From stuefe at openjdk.org Thu Oct 23 09:04:15 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 23 Oct 2025 09:04:15 GMT Subject: RFR: 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:40:58 GMT, Matthias Baesken wrote: > We have some 'at runtime' checks for availability of SetSecurityDescriptorControl in the Windows perfmemory coding. But those were done for very old Windows versions like Win98 and can probably be removed. > Looking at the description > https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol > it is available at least since Win2003/XP so the function can be called directly. good ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27937#pullrequestreview-3368909492 From cnorrbin at openjdk.org Thu Oct 23 09:09:30 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 23 Oct 2025 09:09:30 GMT Subject: RFR: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:49:07 GMT, Casper Norrbin wrote: > Hi everyone, > > The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. > > The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. > > For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. > > Testing: > - Repeated runs of `TestSystemMetrics.java` without any observed failures. > - Oracle tiers 1-5 Thank you all for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27934#issuecomment-3435857448 From cnorrbin at openjdk.org Thu Oct 23 09:09:31 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 23 Oct 2025 09:09:31 GMT Subject: Integrated: 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 08:49:07 GMT, Casper Norrbin wrote: > Hi everyone, > > The test `TestSystemMetrics.java` sometimes fails on cgroupv2 when comparing read/write I/O metrics (`rios`/`wios`) because the expected value doesn't match the one read from the `io.stat` file. The current approach in this test is somewhat flawed, it reads from the same `io.stat` file cgroup file twice, once directly and once through `jdk.internal.platform.Metrics`, and assumes the values should be identical. In practice, this assumption does not hold. Unrelated I/O running in the same cgroup may increment the counter between reads, leading to discrepancies. > > The current comparisons have a 25% margin from the original value to account for incidental noise, but this doesn't work well on the I/O operation counters, which can have very small values (sometimes as low as 0), which makes the percentage-based margin useless. As a result, this test is at risk of failing whenever activity happens between the 2 file readings. > > For greater reliability, I suggest we should instead check that the value is increasing rather than expecting equality. This is already done for other metrics, such as CPU and memory usage, and more accurately reflects the expected behaviour of the counters. Switching to this check removes the reliance on error margins and results in a more stable and meaningful test. > > Testing: > - Repeated runs of `TestSystemMetrics.java` without any observed failures. > - Oracle tiers 1-5 This pull request has now been integrated. Changeset: aec13888 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/aec138886ec2dff765ed810059a1c7b9905c43ca Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu Reviewed-by: sgehwolf, mbaesken, syan ------------- PR: https://git.openjdk.org/jdk/pull/27934 From coleenp at openjdk.org Thu Oct 23 10:47:06 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Oct 2025 10:47:06 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3] In-Reply-To: References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> Message-ID: On Thu, 16 Oct 2025 13:21:41 GMT, Johan Sj?len wrote: >> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this. >> >> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented. >> >> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Revert access modifier style Note that PR https://github.com/openjdk/jdk/pull/27869 overrides this one. This one should be closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3436252377 From stuefe at openjdk.org Thu Oct 23 11:06:05 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 23 Oct 2025 11:06:05 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3] In-Reply-To: <7J8guHYl2UtqybisaKCKKshk-3iWj8PSBR2QumCRO2s=.cce440e1-a4cb-4588-8d43-faf79983d5d5@github.com> References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com> <7J8guHYl2UtqybisaKCKKshk-3iWj8PSBR2QumCRO2s=.cce440e1-a4cb-4588-8d43-faf79983d5d5@github.com> Message-ID: On Fri, 17 Oct 2025 11:44:55 GMT, Coleen Phillimore wrote: > I like this last suggestion. I'll take it over for you while on vacation. I like this too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3436335274 From coleenp at openjdk.org Thu Oct 23 11:29:08 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Oct 2025 11:29:08 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: <1bpOpZyeP3tTMGml77h92xpLETC-ei0JpThTa1NK7Oo=.d6903403-4341-41f3-b7dd-843dd307ebd2@github.com> On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Thank you for reviewing and your comments, Afshin. ------------- PR Review: https://git.openjdk.org/jdk/pull/27869#pullrequestreview-3369424399 From coleenp at openjdk.org Thu Oct 23 11:29:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Oct 2025 11:29:11 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 11:48:58 GMT, Afshin Zafari wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Small things. > > src/hotspot/share/memory/arena.hpp line 46: > >> 44: bool _locked; >> 45: public: >> 46: ChunkPoolLocker(LockStrategy ls = LockStrategy::Lock); > > If the `LockStrategy` is defaulted to `Lock`, then all the instances of this lock used in `ChunkPool`'s cleaning functions (`return_to_pool`, `take_from_pool`, `prune` and `deallocate_chunk`) would try to lock this explicitly. So, when either of these called while NMT is reporting (acquired the lock), we have deadlock again. This isn't the problem that we've seen though. These shouldn't be called during error reporting explicitly like the NMT code. The NMT code is reporting the error while holding the lock, thus needing the lock to be taken again. > src/hotspot/share/nmt/nmtUsage.cpp line 67: > >> 65: } >> 66: ChunkPoolLocker cpl(ls); >> 67: ms = MallocMemorySummary::as_snapshot(); > > Preexisting: > The `MMS::as_snapshot()` just returns the pointer to the snapshot structure and does not update/access anything there. The life time of the `ChunkPoolLocker cpl` should be the whole body of the function. I don't think this should change with this PR. It could be that the lock is needed to gather the chunk pool information but the NMT reporting and subsequent adjustments should only be local to NMT and not lock the chunk pool. I'll leave this to another CR to investigate further. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2454770767 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2454782880 From azafari at openjdk.org Thu Oct 23 11:44:12 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 23 Oct 2025 11:44:12 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 11:15:20 GMT, Coleen Phillimore wrote: >> src/hotspot/share/memory/arena.hpp line 46: >> >>> 44: bool _locked; >>> 45: public: >>> 46: ChunkPoolLocker(LockStrategy ls = LockStrategy::Lock); >> >> If the `LockStrategy` is defaulted to `Lock`, then all the instances of this lock used in `ChunkPool`'s cleaning functions (`return_to_pool`, `take_from_pool`, `prune` and `deallocate_chunk`) would try to lock this explicitly. So, when either of these called while NMT is reporting (acquired the lock), we have deadlock again. > > This isn't the problem that we've seen though. These shouldn't be called during error reporting explicitly like the NMT code. The NMT code is reporting the error while holding the lock, thus needing the lock to be taken again. OK. >> src/hotspot/share/nmt/nmtUsage.cpp line 67: >> >>> 65: } >>> 66: ChunkPoolLocker cpl(ls); >>> 67: ms = MallocMemorySummary::as_snapshot(); >> >> Preexisting: >> The `MMS::as_snapshot()` just returns the pointer to the snapshot structure and does not update/access anything there. The life time of the `ChunkPoolLocker cpl` should be the whole body of the function. > > I don't think this should change with this PR. It could be that the lock is needed to gather the chunk pool information but the NMT reporting and subsequent adjustments should only be local to NMT and not lock the chunk pool. I'll leave this to another CR to investigate further. OK ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2454835297 PR Review Comment: https://git.openjdk.org/jdk/pull/27869#discussion_r2454835804 From coleenp at openjdk.org Thu Oct 23 11:48:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Oct 2025 11:48:18 GMT Subject: RFR: 8369622: GlobalChunkPoolMutex is recursively locked during error handling [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:24:04 GMT, Coleen Phillimore wrote: >> This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. >> Tested with tier1-4, tier5 on aarch64 (product and debug). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Small things. Thank you for the reviews and test, Afshin, David and Paul. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27869#issuecomment-3436501354 From coleenp at openjdk.org Thu Oct 23 11:48:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Oct 2025 11:48:20 GMT Subject: Integrated: 8369622: GlobalChunkPoolMutex is recursively locked during error handling In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 17:04:58 GMT, Coleen Phillimore wrote: > This change disables recursive locking for the ChunkPoolLocker during error handling for NMT callers. The patch is written by Johan as an alternative to supporting another recursive locker for this lock. > Tested with tier1-4, tier5 on aarch64 (product and debug). This pull request has now been integrated. Changeset: 3fdb15fc Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/3fdb15fc5203a559a5e6951a5a9505160057f258 Stats: 44 lines in 5 files changed: 35 ins; 0 del; 9 mod 8369622: GlobalChunkPoolMutex is recursively locked during error handling Co-authored-by: Johan Sj?len Co-authored-by: Afshin Zafari Reviewed-by: dholmes, azafari, phubner ------------- PR: https://git.openjdk.org/jdk/pull/27869 From mbaesken at openjdk.org Thu Oct 23 11:51:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Oct 2025 11:51:38 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v3] In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Build only whitebox.cpp with new cflag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27899/files - new: https://git.openjdk.org/jdk/pull/27899/files/13a1b423..fec2180d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899 PR: https://git.openjdk.org/jdk/pull/27899 From mbaesken at openjdk.org Thu Oct 23 13:06:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Oct 2025 13:06:52 GMT Subject: Integrated: 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly In-Reply-To: References: Message-ID: <-9rvTR_xfG74znFO1EwXzndF-8uJuOeulP0FYyjO5x0=.58b4b475-8cf8-4640-8ec3-3ce51c5f2b88@github.com> On Wed, 22 Oct 2025 12:40:58 GMT, Matthias Baesken wrote: > We have some 'at runtime' checks for availability of SetSecurityDescriptorControl in the Windows perfmemory coding. But those were done for very old Windows versions like Win98 and can probably be removed. > Looking at the description > https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol > it is available at least since Win2003/XP so the function can be called directly. This pull request has now been integrated. Changeset: b597b655 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b597b6556dbd18360423c29c784a5fbb792a8899 Stats: 26 lines in 1 file changed: 0 ins; 14 del; 12 mod 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/27937 From mbaesken at openjdk.org Thu Oct 23 13:06:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Oct 2025 13:06:51 GMT Subject: RFR: 8370065: Windows perfmemory coding - use SetSecurityDescriptorControl directly In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:40:58 GMT, Matthias Baesken wrote: > We have some 'at runtime' checks for availability of SetSecurityDescriptorControl in the Windows perfmemory coding. But those were done for very old Windows versions like Win98 and can probably be removed. > Looking at the description > https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-setsecuritydescriptorcontrol > it is available at least since Win2003/XP so the function can be called directly. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27937#issuecomment-3436802360 From azafari at openjdk.org Thu Oct 23 14:21:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 23 Oct 2025 14:21:36 GMT Subject: RFR: 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out Message-ID: Creating core-dump on crash is disabled for the test. ------------- Commit messages: - 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out Changes: https://git.openjdk.org/jdk/pull/27953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370261 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27953/head:pull/27953 PR: https://git.openjdk.org/jdk/pull/27953 From pchilanomate at openjdk.org Thu Oct 23 14:27:02 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 23 Oct 2025 14:27:02 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: Message-ID: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> On Thu, 23 Oct 2025 03:56:07 GMT, Serguei Spitsyn wrote: >> Strangely, the test `serviceability/jvmti/vthread/ContStackDepthTest` is failing with the `assert(_cur_stack_depth == num_frames)`. Obviously, some of the code paths is missed to call `invalidate_jvmti_stack()`. > > As I see, the calls to `invalidate_jvmti_stack()` are needed for plain continuations only (under condition `if (!cont.entry()->is_virtual_thread()`). > > The following patch does not cause regressions in mach5 tier 6 (mach5 tiers 1-5 are in progress): > > diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp > index 0884fce2ff7..dbbf5526602 100644 > --- a/src/hotspot/share/prims/jvmtiExport.cpp > +++ b/src/hotspot/share/prims/jvmtiExport.cpp > @@ -1711,7 +1711,6 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati > if (state == nullptr) { > return; > } > - state->invalidate_cur_stack_depth(); > > // Clear frame_pop requests in frames popped by yield > if (can_post_frame_pop()) { > diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > index 0750f611876..f8406fb33c1 100644 > --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp > +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > @@ -1626,11 +1626,15 @@ static void invalidate_jvmti_stack(JavaThread* thread) { > } > > static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { > - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { > + if (cont.entry()->is_virtual_thread()) { > + return; > + } > + invalidate_jvmti_stack(thread); > + if (JvmtiExport::has_frame_pops(thread)) { > int num_frames = num_java_frames(cont); > > ContinuationWrapper::SafepointOp so(Thread::current(), cont); > - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); > + JvmtiExport::continuation_yield_cleanup(thread, num_frames); > } > } > > @@ -1685,7 +1689,7 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { > > log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); > > - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); > + JVMTI_ONLY(if (!cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(JavaThread::current())); > return freeze_ok; > } > > @@ -2311,7 +2315,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t > > assert(_cont.chunk_invariant(), ""); > > - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); > + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); > > _thread->set_cont_fastpath(_fastpath); > ``` Ah, we need to call `invalidate_jvmti_stack` at the end in `jvmti_yield_cleanup`! The problem is that in `JvmtiExport::continuation_yield_cleanup` we are setting again the stack depth when calling `state->cur_stack_depth()`. We count the enterSpecial frame at the top but we don?t decrement the depth when removing it (done in assembly code). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2455332318 From fbredberg at openjdk.org Thu Oct 23 14:37:38 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 23 Oct 2025 14:37:38 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2] In-Reply-To: References: Message-ID: <-gfZp7TYxZYTOiSQK7jLDfJXjhE5HZLudg6ZgmOmOBA=.eb28a751-dd90-430a-b411-b655397298f2@github.com> On Fri, 17 Oct 2025 15:24:48 GMT, Patricio Chilano Mateo wrote: >> If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. >> This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: >> >> `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` >> >> There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. >> Testing in mach5 tiers1-5. >> >> Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > rename to was_notified Nice cleanup! Having two variables that should always be in sync is never a good idea, so thank you for dropping the unnecessary `_notified`. ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27856#pullrequestreview-3370288391 From pchilanomate at openjdk.org Thu Oct 23 15:49:42 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 23 Oct 2025 15:49:42 GMT Subject: RFR: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: <6UaW-mUCcbPOUWqOwN66z365XOCAVblt00bD72gseWE=.cc35b6ad-c287-4815-83a2-8c39bf95e39f@github.com> On Fri, 17 Oct 2025 02:38:13 GMT, David Holmes wrote: >> If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. >> This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: >> >> `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` >> >> There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. >> Testing in mach5 tiers1-5. >> >> Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). >> >> Thanks, >> Patricio > >> This could have been a timed-wait that timed-out, and only after that, the thread was interrupted > > This is a feature not a bug. It is preferable to return via IE if the interrupt was detected, even if we originally timed-out of the wait itself. Thanks for the reviews @dholmes-ora and @fbredber! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27856#issuecomment-3437739607 From pchilanomate at openjdk.org Thu Oct 23 15:49:45 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 23 Oct 2025 15:49:45 GMT Subject: Integrated: 8369944: Notification can be lost due to interrupt in Object.wait In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 22:03:51 GMT, Patricio Chilano Mateo wrote: > If a thread waiting in `Object.wait` is interrupted at the same time it is being notified, it could wake up, read `node.TState` as `TS_ENTER` but then read `node._notified` as false. There is no ordering in `notify_internal()` between setting `iterator->_notified` to true and setting `node.TState` to `TS_ENTER`. > This means that `WasNotified` will be false and the thread will throw IE. But we will then miss a notification as per the JLS 17.2.4 specs: > > `Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified.` > > There is no need for `_notified`, since the value of `node.TState` can be used to tell if the thread was notified or not. > Testing in mach5 tiers1-5. > > Related note: besides checking for `!WasNotified`, I think we should also check for `ret == OS_OK` before throwing IE. This could have been a timed-wait that timed-out, and only after that, the thread was interrupted while trying to reenter the monitor (the thread can be observed in the reenter part either with JVMTI events enabled or by reading the j.l.Thread.State). > > Thanks, > Patricio This pull request has now been integrated. Changeset: 6e898e21 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/6e898e21130259839e8060245c70182f70d8ee12 Stats: 14 lines in 2 files changed: 0 ins; 7 del; 7 mod 8369944: Notification can be lost due to interrupt in Object.wait Reviewed-by: dholmes, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/27856 From sspitsyn at openjdk.org Thu Oct 23 17:20:59 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 23 Oct 2025 17:20:59 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> References: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> Message-ID: On Thu, 23 Oct 2025 14:24:05 GMT, Patricio Chilano Mateo wrote: >> As I see, the calls to `invalidate_jvmti_stack()` are needed for plain continuations only (under condition `if (!cont.entry()->is_virtual_thread()`). >> >> The following patch does not cause regressions in mach5 tier 6 (mach5 tiers 1-5 are in progress): >> >> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp >> index 0884fce2ff7..dbbf5526602 100644 >> --- a/src/hotspot/share/prims/jvmtiExport.cpp >> +++ b/src/hotspot/share/prims/jvmtiExport.cpp >> @@ -1711,7 +1711,6 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati >> if (state == nullptr) { >> return; >> } >> - state->invalidate_cur_stack_depth(); >> >> // Clear frame_pop requests in frames popped by yield >> if (can_post_frame_pop()) { >> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> index 0750f611876..f8406fb33c1 100644 >> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> @@ -1626,11 +1626,15 @@ static void invalidate_jvmti_stack(JavaThread* thread) { >> } >> >> static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { >> - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { >> + if (cont.entry()->is_virtual_thread()) { >> + return; >> + } >> + invalidate_jvmti_stack(thread); >> + if (JvmtiExport::has_frame_pops(thread)) { >> int num_frames = num_java_frames(cont); >> >> ContinuationWrapper::SafepointOp so(Thread::current(), cont); >> - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); >> + JvmtiExport::continuation_yield_cleanup(thread, num_frames); >> } >> } >> >> @@ -1685,7 +1689,7 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { >> >> log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); >> >> - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); >> + JVMTI_ONLY(if (!cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(JavaThread::current())); >> return freeze_ok; >> } >> >> @@ -2311,7 +2315,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t >> >> assert(_cont.chunk_invariant(), ""); >> >> - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); >> + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); >> >> _thread->set_cont_fast... > > Ah, we need to call `invalidate_jvmti_stack` at the end in `jvmti_yield_cleanup`! The problem is that in `JvmtiExport::continuation_yield_cleanup` we are setting again the stack depth when calling `state->cur_stack_depth()`. We count the enterSpecial frame at the top but we don?t decrement the depth when removing it (done in assembly code). Okay, thanks! Did you verify it the test `serviceability/jvmti/vthread/ContStackDepthTest`? I see it is still failing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2456206623 From sspitsyn at openjdk.org Thu Oct 23 17:36:32 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 23 Oct 2025 17:36:32 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> Message-ID: On Thu, 23 Oct 2025 17:17:16 GMT, Serguei Spitsyn wrote: >> Ah, we need to call `invalidate_jvmti_stack` at the end in `jvmti_yield_cleanup`! The problem is that in `JvmtiExport::continuation_yield_cleanup` we are setting again the stack depth when calling `state->cur_stack_depth()`. We count the enterSpecial frame at the top but we don?t decrement the depth when removing it (done in assembly code). > > Okay, thanks! Did you verify it with run of test `serviceability/jvmti/vthread/ContStackDepthTest`? I see it is still failing with the call to `invalidate_jvmti_stack()` at the end of `jvmti_yield_cleanup()`. This test does not fail with the following patch: diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 0750f611876..a12e99903af 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -1626,12 +1626,17 @@ static void invalidate_jvmti_stack(JavaThread* thread) { } static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { + if (cont.entry()->is_virtual_thread()) { + return; + } + invalidate_jvmti_stack(thread); + if (JvmtiExport::has_frame_pops(thread)) { int num_frames = num_java_frames(cont); ContinuationWrapper::SafepointOp so(Thread::current(), cont); - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); + JvmtiExport::continuation_yield_cleanup(thread, num_frames); } + invalidate_jvmti_stack(thread); } static void jvmti_mount_end(JavaThread* current, ContinuationWrapper& cont, frame top) { @@ -1685,7 +1690,6 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); return freeze_ok; } @@ -2311,7 +2315,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t assert(_cont.chunk_invariant(), ""); - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); _thread->set_cont_fastpath(_fastpath); The call to `invalidate_jvmti_stack()` is still needed in the `thaw_slow()`. I can go ahead with this update if you are okay with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2456310256 From pchilanomate at openjdk.org Thu Oct 23 18:02:27 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 23 Oct 2025 18:02:27 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v3] In-Reply-To: References: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> Message-ID: On Thu, 23 Oct 2025 17:32:51 GMT, Serguei Spitsyn wrote: >> Okay, thanks! Did you verify it with run of test `serviceability/jvmti/vthread/ContStackDepthTest`? I see it is still failing with the call to `invalidate_jvmti_stack()` at the end of `jvmti_yield_cleanup()`. > > This test does not fail with the following patch: > > diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > index 0750f611876..a12e99903af 100644 > --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp > +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > @@ -1626,12 +1626,17 @@ static void invalidate_jvmti_stack(JavaThread* thread) { > } > > static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { > - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { > + if (cont.entry()->is_virtual_thread()) { > + return; > + } > + invalidate_jvmti_stack(thread); > + if (JvmtiExport::has_frame_pops(thread)) { > int num_frames = num_java_frames(cont); > > ContinuationWrapper::SafepointOp so(Thread::current(), cont); > - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); > + JvmtiExport::continuation_yield_cleanup(thread, num_frames); > } > + invalidate_jvmti_stack(thread); > } > > static void jvmti_mount_end(JavaThread* current, ContinuationWrapper& cont, frame top) { > @@ -1685,7 +1690,6 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { > > log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); > > - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); > return freeze_ok; > } > > @@ -2311,7 +2315,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t > > assert(_cont.chunk_invariant(), ""); > > - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); > + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); > > _thread->set_cont_fastpath(_fastpath); > > > The call to `invalidate_jvmti_stack()` is still needed in the `thaw_slow()`. > I can go ahead with this update if you are okay with it. This is the patch I tested out with `serviceability/jvmti/vthread/ContStackDepthTest` (on top of mainline): diff --git a/src/hotspot/share/prims/jvmtiThreadState.cpp b/src/hotspot/share/prims/jvmtiThreadState.cpp index 00a48dec111..181d77f4d10 100644 --- a/src/hotspot/share/prims/jvmtiThreadState.cpp +++ b/src/hotspot/share/prims/jvmtiThreadState.cpp @@ -678,6 +678,10 @@ void JvmtiVTMSTransitionDisabler::VTMS_unmount_end(jobject vthread) { JavaThread* thread = JavaThread::current(); assert(thread->is_in_VTMS_transition(), "sanity check"); + JvmtiThreadState *state = thread->jvmti_thread_state(); + if (state != nullptr) { + state->invalidate_cur_stack_depth(); + } finish_VTMS_transition(vthread, /* is_mount */ false); } diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 3e509e71551..a493fca076e 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -1626,13 +1626,15 @@ static void invalidate_jvmti_stack(JavaThread* thread) { } static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { - int num_frames = num_java_frames(cont); + if (!cont.entry()->is_virtual_thread()) { + if (JvmtiExport::has_frame_pops(thread)) { + int num_frames = num_java_frames(cont); - ContinuationWrapper::SafepointOp so(Thread::current(), cont); - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); + ContinuationWrapper::SafepointOp so(Thread::current(), cont); + JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); + } + invalidate_jvmti_stack(thread); } - invalidate_jvmti_stack(thread); } static void jvmti_mount_end(JavaThread* current, ContinuationWrapper& cont, frame top) { Originally I had `invalidate_jvmti_stack()` before calling `JvmtiExport::continuation_yield_cleanup` so I could reproduce the issue. I think you are right that for virtual threads we shouldn't need to invalidate the stack, so your patch is an improvement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2456495915 From dholmes at openjdk.org Thu Oct 23 21:44:24 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Oct 2025 21:44:24 GMT Subject: RFR: 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out In-Reply-To: References: Message-ID: <40-Cw8DtHB65aoB5JEPVeU9SLugw_ksjC4GPLPGAD1c=.b5b75c73-1bb5-4ad9-8876-75f76670b734@github.com> On Thu, 23 Oct 2025 14:14:10 GMT, Afshin Zafari wrote: > Creating core-dump on crash is disabled for the test. LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27953#pullrequestreview-3372900474 From abarashev at openjdk.org Thu Oct 23 22:00:16 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 23 Oct 2025 22:00:16 GMT Subject: RFR: 8366364: Address inconsistencies in SSLParameters object returned by SSLConfiguration#getSSLParameters() call Message-ID: We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call: - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters. - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters. ------------- Commit messages: - 8366364: Address inconsistencies in SSLParameters object returned by SSLConfiguration#getSSLParameters() call Changes: https://git.openjdk.org/jdk/pull/27961/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27961&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366364 Stats: 108 lines in 10 files changed: 47 ins; 35 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27961/head:pull/27961 PR: https://git.openjdk.org/jdk/pull/27961 From dholmes at openjdk.org Fri Oct 24 07:02:08 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Oct 2025 07:02:08 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v3] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Thu, 23 Oct 2025 11:51:38 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Build only whitebox.cpp with new cflag One style nit. This still needs build team approval. Thanks test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java line 149: > 147: > 148: if (wb.hasExternalSymbolsStripped()) { expectSourceInformation = false; } > 149: Suggestion: if (wb.hasExternalSymbolsStripped()) { expectSourceInformation = false; } ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27899#pullrequestreview-3374797603 PR Review Comment: https://git.openjdk.org/jdk/pull/27899#discussion_r2459086347 From mbaesken at openjdk.org Fri Oct 24 07:22:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 24 Oct 2025 07:22:41 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v3] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Fri, 24 Oct 2025 06:59:46 GMT, David Holmes wrote: > This still needs build team approval. Christoph is from the build group / team too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3441476420 From mbaesken at openjdk.org Fri Oct 24 07:22:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 24 Oct 2025 07:22:40 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust style nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27899/files - new: https://git.openjdk.org/jdk/pull/27899/files/fec2180d..6390e48b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27899.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899 PR: https://git.openjdk.org/jdk/pull/27899 From fandreuzzi at openjdk.org Fri Oct 24 08:36:02 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 24 Oct 2025 08:36:02 GMT Subject: RFR: 8366364: Address inconsistencies in SSLParameters object returned by SSLConfiguration#getSSLParameters() call In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 21:54:24 GMT, Artur Barashev wrote: > We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call: > - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters. > - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 422: > 420: || config.signatureSchemes == null ? > 421: Arrays.asList(SignatureScheme.values()) : > 422: Arrays.stream(config.signatureSchemes) The formatting makes this assignment a bit hard to follow. Perhaps a simple `if` statement would behave better? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2459322058 From sspitsyn at openjdk.org Fri Oct 24 09:16:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 24 Oct 2025 09:16:46 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v4] In-Reply-To: References: Message-ID: > This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. > > Testing: > - TBD: Run mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: call to invalidate_jvmti_stack for pure continuations only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27878/files - new: https://git.openjdk.org/jdk/pull/27878/files/3edebdbd..e6fc4058 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=02-03 Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27878/head:pull/27878 PR: https://git.openjdk.org/jdk/pull/27878 From sspitsyn at openjdk.org Fri Oct 24 09:16:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 24 Oct 2025 09:16:46 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v4] In-Reply-To: References: <1q0W0EReS8VDFy-0hCt63wzIfutIr7SxbCPBvnVAXGQ=.59854671-5453-439a-a949-52b424c6a91f@github.com> Message-ID: On Thu, 23 Oct 2025 17:59:51 GMT, Patricio Chilano Mateo wrote: >> This test does not fail with the following patch: >> >> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> index 0750f611876..a12e99903af 100644 >> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> @@ -1626,12 +1626,17 @@ static void invalidate_jvmti_stack(JavaThread* thread) { >> } >> >> static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { >> - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { >> + if (cont.entry()->is_virtual_thread()) { >> + return; >> + } >> + invalidate_jvmti_stack(thread); >> + if (JvmtiExport::has_frame_pops(thread)) { >> int num_frames = num_java_frames(cont); >> >> ContinuationWrapper::SafepointOp so(Thread::current(), cont); >> - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); >> + JvmtiExport::continuation_yield_cleanup(thread, num_frames); >> } >> + invalidate_jvmti_stack(thread); >> } >> >> static void jvmti_mount_end(JavaThread* current, ContinuationWrapper& cont, frame top) { >> @@ -1685,7 +1690,6 @@ static inline freeze_result freeze_epilog(ContinuationWrapper& cont) { >> >> log_develop_debug(continuations)("=== End of freeze cont ### #" INTPTR_FORMAT, cont.hash()); >> >> - JVMTI_ONLY(invalidate_jvmti_stack(JavaThread::current())); >> return freeze_ok; >> } >> >> @@ -2311,7 +2315,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t >> >> assert(_cont.chunk_invariant(), ""); >> >> - JVMTI_ONLY(invalidate_jvmti_stack(_thread)); >> + JVMTI_ONLY(if (!_cont.entry()->is_virtual_thread()) invalidate_jvmti_stack(_thread)); >> >> _thread->set_cont_fastpath(_fastpath); >> >> >> The call to `invalidate_jvmti_stack()` is still needed in the `thaw_slow()`. >> I can go ahead with this update if you are okay with it. > > This is the patch I tested out with `serviceability/jvmti/vthread/ContStackDepthTest` (on top of mainline): > > diff --git a/src/hotspot/share/prims/jvmtiThreadState.cpp b/src/hotspot/share/prims/jvmtiThreadState.cpp > index 00a48dec111..181d77f4d10 100644 > --- a/src/hotspot/share/prims/jvmtiThreadState.cpp > +++ b/src/hotspot/share/prims/jvmtiThreadState.cpp > @@ -678,6 +678,10 @@ void > JvmtiVTMSTransitionDisabler::VTMS_unmount_end(jobject vthread) { > JavaThread* thread = JavaThread::current(); > assert(thread->is_in_VTMS_transition(), "sanity check"); > + JvmtiThreadState *state = thread->jvmti_thread_state(); > + if (state != nullptr) { > + state->invalidate_cur_stack_depth(); > + } > finish_VTMS_transition(vthread, /* is_mount */ false); > } > > diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > index 3e509e71551..a493fca076e 100644 > --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp > +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > @@ -1626,13 +1626,15 @@ static void invalidate_jvmti_stack(JavaThread* thread) { > } > > static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) { > - if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) { > - int num_frames = num_java_frames(cont); > + if (!cont.entry()->is_virtual_thread()) { > + if (JvmtiExport::has_frame_pops(thread)) { > + int num_frames = num_java_frames(cont); > > - ContinuationWrapper::SafepointOp so(Thread::current(), cont); > - JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); > + ContinuationWrapper::SafepointOp so(Thread::current(), cont); > + JvmtiExport::continuation_yield_cleanup(JavaThread::current(), num_frames); > + } > + invalidate_jvmti_stack(thread); > } > - invalidate_jvmti_stack(thread); > } > > static void jvmti_mount_end(JavaThread* current, ContinuationWrapper& cont, frame top) { > > Originally I had `invalidate_jvmti_stack()` before calling `JvmtiExport::continuation_yield_cleanup` so I could reproduce the issue. > > I think you are right that for virtual threads we shouldn't need to invalidate the stack, so your patch is an improvement. Okay, thanks! I've pushed my latest changes which are aligned with your patch above and invalidate the stack for plain/pure continuations only. So, the `VTMS_unmount_end()` still does not include it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27878#discussion_r2459453480 From sspitsyn at openjdk.org Fri Oct 24 09:55:22 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 24 Oct 2025 09:55:22 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v5] In-Reply-To: References: Message-ID: > This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. > > Testing: > - TBD: Run mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: remove unintentionally added new empty line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27878/files - new: https://git.openjdk.org/jdk/pull/27878/files/e6fc4058..4a4302b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27878&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27878/head:pull/27878 PR: https://git.openjdk.org/jdk/pull/27878 From clanger at openjdk.org Fri Oct 24 11:46:06 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 24 Oct 2025 11:46:06 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: <-6l0di2HLMzXvb0keU3RQNanYonVvG5-tdWQw2VHLLk=.cdf57ee7-9663-492b-8133-d713b4163fec@github.com> On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust style nit I think the change is good, however, we should wait for resolution of the PR #24012. Maybe even inline these changes into that. Because without #24012, this here will not be necessary... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3442706212 From mbaesken at openjdk.org Fri Oct 24 11:55:03 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 24 Oct 2025 11:55:03 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: <6FfKIqRf68GxCYMLfJQbRq-wb8RyC9TvVxB_uW-mzwI=.a605ad7b-2578-4837-ab23-9e741416ef4c@github.com> On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust style nit If you build OpenJDK on Windows with stripped debug symbols, you will most likely need it. Assuming you always have the source info in is not valid; I think the change is a good compromise. Instead of using the wrong assumption, or of doing complicated things e.g. with the DIA SDK to analyze the debug info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3442736592 From shade at openjdk.org Fri Oct 24 13:22:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Oct 2025 13:22:06 GMT Subject: RFR: 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 14:14:10 GMT, Afshin Zafari wrote: > Creating core-dump on crash is disabled for the test. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27953#pullrequestreview-3376665016 From erikj at openjdk.org Fri Oct 24 13:48:06 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 24 Oct 2025 13:48:06 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust style nit This test is only run on debug builds. In the discussion in https://github.com/openjdk/jdk/pull/24012 it was pointed out that `--with-external-symbols-in-bundles=public` was an option meant for distribution builds and developers would opt out of it for a reasonable developer experience. Given that, I think this would be quite a rare combination. Especially without https://github.com/openjdk/jdk/pull/24012 since we are currently replacing the stripped PDB files in the image with the full ones anyway, for a local build-test, this test would work anyway. That said, I don't think this change hurts much either, given the rarity of the combination. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3443241940 From pchilanomate at openjdk.org Fri Oct 24 15:49:41 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 24 Oct 2025 15:49:41 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v5] In-Reply-To: References: Message-ID: <1MF3SakLBoE1h9rTSTVDDnnFnujAJJSz2DNlGmndnEg=.3576b8d3-23d6-44b6-9f13-ea93b5a958b4@github.com> On Fri, 24 Oct 2025 09:55:22 GMT, Serguei Spitsyn wrote: >> This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. >> >> Testing: >> - TBD: Run mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unintentionally added new empty line Looks good to me, thanks Serguei! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27878#pullrequestreview-3377577998 From wkemper at openjdk.org Fri Oct 24 16:09:15 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 24 Oct 2025 16:09:15 GMT Subject: RFR: 8370050: Shenandoah: Obsolete ShenandoahPacing option In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 04:37:07 GMT, David Holmes wrote: >> ShenandoahPacing was removed in this release (26). Rather than have the JVM refuse to start if this option is given, it should give a warning that the option is removed and is ignored and will reject the option in JDK27. >> >> Testing: >> >> [0] % ./build/linux-x86_64-server-release/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahPacing --version >> OpenJDK 64-Bit Server VM warning: Ignoring option ShenandoahPacing; support was removed in 26.0 > > src/hotspot/share/runtime/arguments.cpp line 551: > >> 549: { "ZMarkStackSpaceLimit", JDK_Version::undefined(), JDK_Version::jdk(25), JDK_Version::undefined() }, >> 550: { "G1UpdateBufferSize", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >> 551: { "ShenandoahPacing", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > Nit: you didn't actually deprecate the option in 25 so this should have been left as `undefined()`. Sorry, I missed this comment earlier. We sort of did deprecate it in 25 through this change: https://github.com/openjdk/jdk25u/pull/321. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27859#discussion_r2461147097 From sspitsyn at openjdk.org Fri Oct 24 17:39:03 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 24 Oct 2025 17:39:03 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v5] In-Reply-To: References: Message-ID: <8F7bgTZfsRhB_BLqufD4zgvFnnwZ4UzJP3nOJjTwF0A=.6923e59e-8431-486d-8437-e9462af76877@github.com> On Fri, 24 Oct 2025 09:55:22 GMT, Serguei Spitsyn wrote: >> This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. >> >> Testing: >> - TBD: Run mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unintentionally added new empty line Patricio, thank you a lot for review a suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27878#issuecomment-3444217146 From coleenp at openjdk.org Fri Oct 24 18:11:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Oct 2025 18:11:17 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM Message-ID: Check for constant pool index overflow and throw ClassFormatError instead of crashing. Tested with tier1-4. ------------- Commit messages: - 8364360: Defining hidden class with no room in constant pool crashes the VM Changes: https://git.openjdk.org/jdk/pull/27964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364360 Stats: 57 lines in 2 files changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From dlong at openjdk.org Fri Oct 24 23:16:12 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 24 Oct 2025 23:16:12 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) Message-ID: The problem is code called from a signal handler, like SharedRuntime::handle_unsafe_access(), can call os::malloc(), and when NMT is enabled, we try to get a stack backtrace. But os::get_native_stack() does not know how to walk through signal handler frames. This fix introduces FirstNativeFrameMark to be used by the POSIX version of os::get_native_stack() to set a frame to stop at in the POSIX signal handler. ------------- Commit messages: - remove added blank lines - sort includes - missing include - stop stack walk at signal handler Changes: https://git.openjdk.org/jdk/pull/27985/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27985&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358725 Stats: 56 lines in 5 files changed: 54 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27985.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27985/head:pull/27985 PR: https://git.openjdk.org/jdk/pull/27985 From dholmes at openjdk.org Sun Oct 26 20:43:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 26 Oct 2025 20:43:03 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust style nit Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27899#pullrequestreview-3381432798 From dholmes at openjdk.org Mon Oct 27 02:59:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Oct 2025 02:59:01 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 23:09:20 GMT, Dean Long wrote: > The problem is code called from a signal handler, like SharedRuntime::handle_unsafe_access(), can call os::malloc(), and when NMT is enabled, we try to get a stack backtrace. But os::get_native_stack() does not know how to walk through signal handler frames. > > This fix introduces FirstNativeFrameMark to be used by the POSIX version of os::get_native_stack() to set a frame to stop at in the POSIX signal handler. If we only the print the stack up to the signal handler, and not all the way to the allocation, then won't the resulting stack trace be confusing for the reader? > The problem is code called from a signal handler, like SharedRuntime::handle_unsafe_access(), can call os::malloc(), Yeah and it really should not do that. :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/27985#issuecomment-3449310485 From dholmes at openjdk.org Mon Oct 27 04:29:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Oct 2025 04:29:02 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 23:54:10 GMT, Coleen Phillimore wrote: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. The `guarantee_property` is fine but some nits elsewhere. Thanks src/hotspot/share/classfile/classFileParser.cpp line 5528: > 5526: cp_size++; > 5527: // Check for overflow. cp_size is a u2. > 5528: precond(sizeof(cp_size) == sizeof(u2)); Why do you need to assert this given `u2 cp_size = ...` is the declaration? test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 44: > 42: var cw = new ClassWriter(0); > 43: cw.visit(V17, ACC_PUBLIC, "Hidden", null, "java/lang/Object", null); > 44: for (int i = 0; i < 65530; i++) { Why 65530? An empty class definition already has 12 CP entries when compiled by javac. test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 50: > 48: MethodHandles.lookup().defineHiddenClass(cw.toByteArray(), false); > 49: throw new RuntimeException("Test Failed: ClassFormatError expected."); > 50: } catch (ClassFormatError cfe) { It would be prudent to check that you get the expected CFE. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27964#pullrequestreview-3381751779 PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2464387186 PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2464392864 PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2464389558 From iklam at openjdk.org Mon Oct 27 06:27:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 27 Oct 2025 06:27:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 20 Oct 2025 17:40:20 GMT, Dan Heidinga wrote: >> These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? > > Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? > > Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? > > The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem I looked at all the calls of the pattern `SharedSecrets.set.*::` java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream); These calls are all done inside a ``. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its ``. Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit. I think we can leave the other 3 cases alone. An alternative is to rewrite the first case from: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); to SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() { ObjectInputFilter createFilter2(String pattern) { return Config.createFilter2(pattern); } }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464550244 From pminborg at openjdk.org Mon Oct 27 08:52:04 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 27 Oct 2025 08:52:04 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/hotspot/share/cds/cdsHeapVerifier.cpp line 186: > 184: if (fd->signature()->starts_with("Ljdk/internal/access/") && > 185: fd->signature()->ends_with("Access;")) { > 186: // The jdk/internal/access/*Access classes carry no states so they can be safely This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464838946 From coleenp at openjdk.org Mon Oct 27 12:45:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Oct 2025 12:45:11 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: Message-ID: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Test enhancement and comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/097a5561..0d982a7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From coleenp at openjdk.org Mon Oct 27 12:45:14 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Oct 2025 12:45:14 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: Message-ID: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> On Mon, 27 Oct 2025 04:17:27 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Test enhancement and comment. > > src/hotspot/share/classfile/classFileParser.cpp line 5528: > >> 5526: cp_size++; >> 5527: // Check for overflow. cp_size is a u2. >> 5528: precond(sizeof(cp_size) == sizeof(u2)); > > Why do you need to assert this given `u2 cp_size = ...` is the declaration? In case somebody changes it to int. There used to be talk about doing this so then the overflow check might have to be different. > test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 44: > >> 42: var cw = new ClassWriter(0); >> 43: cw.visit(V17, ACC_PUBLIC, "Hidden", null, "java/lang/Object", null); >> 44: for (int i = 0; i < 65530; i++) { > > Why 65530? An empty class definition already has 12 CP entries when compiled by javac. This is a magic number. 65536-5 gets CFE: class too large, 65536-7 doesn't get an CFE. Only 65536-6 caused the overflow. This is asm so asm may only be adding 6 entries. I kept the test as ASM rather than using ClassFile API because it might be good to backport this. > test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 50: > >> 48: MethodHandles.lookup().defineHiddenClass(cw.toByteArray(), false); >> 49: throw new RuntimeException("Test Failed: ClassFormatError expected."); >> 50: } catch (ClassFormatError cfe) { > > It would be prudent to check that you get the expected CFE. okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2465450393 PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2465501998 PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2465481673 From duke at openjdk.org Mon Oct 27 13:28:10 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 27 Oct 2025 13:28:10 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 27 Oct 2025 06:23:58 GMT, Ioi Lam wrote: >> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? >> >> Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? >> >> The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem > > I looked at all the calls of the pattern `SharedSecrets.set.*::` > > > java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); > java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); > javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream); > > > These calls are all done inside a ``. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its ``. > > Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit. > > I think we can leave the other 3 cases alone. > > An alternative is to rewrite the first case from: > > > SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > > > to > > > SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() { > ObjectInputFilter createFilter2(String pattern) { > return Config.createFilter2(pattern); > } > }); The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`: SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() { public void checkArray(ObjectInputStream ois, Class arrayType, int arrayLength) throws ObjectStreamException { ois.checkArray(arrayType, arrayLength); } public String readString(ObjectInputStream ois) throws IOException { return ois.readString(); } }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2465667143 From duke at openjdk.org Mon Oct 27 13:49:01 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 27 Oct 2025 13:49:01 GMT Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension request Message-ID: Hi, please consider the following changes: If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen: 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM. 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM. The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again. The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events. Tests are added for both scenarios. Tested in tiers 1 - 7. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed new lines. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Removed incorrect assert, - 8366659: Fixed merge conflict - 8366659: Fixed whitespace. - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event. - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock - 8366659: Fixed whitespace. - ... and 5 more: https://git.openjdk.org/jdk/compare/7bb490c4...8b7d3f60 Changes: https://git.openjdk.org/jdk/pull/27040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366659 Stats: 374 lines in 3 files changed: 310 ins; 44 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040 PR: https://git.openjdk.org/jdk/pull/27040 From shade at openjdk.org Mon Oct 27 17:48:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 27 Oct 2025 17:48:28 GMT Subject: RFR: 8370572: cgroup v1 hierarchical memory limit is not honored after JDK-8322420 Message-ID: See the bug for more discussion. We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. Additional testing: - [x] Reproducer with local Docker now passes - [ ] Reproducer with ECS Fargate now passes - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/28006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370572 Stats: 35 lines in 3 files changed: 23 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28006/head:pull/28006 PR: https://git.openjdk.org/jdk/pull/28006 From shade at openjdk.org Mon Oct 27 17:59:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 27 Oct 2025 17:59:23 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: Message-ID: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> > See the bug for more discussion. > > We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). > > But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. > > Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. > > We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. > > I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. > > Additional testing: > - [x] Reproducer with local Docker now passes > - [ ] Reproducer with ECS Fargate now passes > - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host > - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Also no need to touch the other getter - Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28006/files - new: https://git.openjdk.org/jdk/pull/28006/files/1bab06c9..a02526d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28006&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28006&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28006/head:pull/28006 PR: https://git.openjdk.org/jdk/pull/28006 From shade at openjdk.org Mon Oct 27 18:05:03 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 27 Oct 2025 18:05:03 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [ ] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace Logs from local reproducer (see bug for details) -- asking to run with 1G in parent slice, and 25% of container memory as heap size. The goal is to have 256M heap size then. Current mainline (broken): [0.001s][trace][os,container] OSContainer::init: Initializing Container Support [0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.001s][debug][os,container] OSContainer::init: is_containerized() = true because all controllers are mounted read-only (container case) ... [0.001s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.001s][trace][os,container] Memory Limit is: 9223372036854771712 [0.001s][debug][os,container] container memory limit ignored: 9223372036854771712, upper bound is 264567476224 ... [0.141s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.141s][trace][os,container] Memory Limit is: 9223372036854771712 [0.141s][debug][os,container] container memory limit ignored: 9223372036854771712, upper bound is 264567476224 [0.141s][info ][gc,init ] Memory: 246G ... [0.141s][info ][gc,init ] Heap Min Capacity: 32M [0.141s][info ][gc,init ] Heap Initial Capacity: 63104M [0.141s][info ][gc,init ] Heap Max Capacity: 63104M ... This fix: [0.001s][trace][os,container] OSContainer::init: Initializing Container Support [0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.001s][debug][os,container] OSContainer::init: is_containerized() = true because all controllers are mounted read-only (container case) ... [0.001s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.001s][trace][os,container] Memory Limit is: 9223372036854771712 [0.001s][trace][os,container] Path to /memory.use_hierarchy is /sys/fs/cgroup/memory/memory.use_hierarchy [0.001s][trace][os,container] Use Hierarchy is: 1 [0.001s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat [0.001s][trace][os,container] Hierarchical Memory Limit is: 1073741824 ... [0.040s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.040s][trace][os,container] Memory Limit is: 9223372036854771712 [0.040s][trace][os,container] Path to /memory.use_hierarchy is /sys/fs/cgroup/memory/memory.use_hierarchy [0.041s][trace][os,container] Use Hierarchy is: 1 [0.041s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/memory.stat [0.041s][trace][os,container] Hierarchical Memory Limit is: 1073741824 ... [0.041s][info ][gc,init ] Memory: 1024M [0.041s][info ][gc,init ] Heap Initial Capacity: 256M [0.041s][info ][gc,init ] Heap Max Capacity: 256M ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3452627144 From xpeng at openjdk.org Mon Oct 27 19:29:43 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 27 Oct 2025 19:29:43 GMT Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads concurrently Message-ID: As @shipilev mentioned in the description description of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), we could rearrange the code and ask GC to suspend after announcing safepoint, GC threads and Java threads will sync simultaneously. [The other option](https://github.com/openjdk/jdk/pull/27739/files) I have test is to split STS synchronize into `synchronize_begin` and `synchronize`, which makes GC thread suspension fully aysnc(same Java threads), but I didn't see big performance difference, therefore I chose the simple solution suggested by Aleksey. Test: - [x] tier1 ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8369392-simple-solution - Suspend GC threads after arming safepoint for Java threads but before synchronizing Java threads Changes: https://git.openjdk.org/jdk/pull/27924/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27924&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369392 Stats: 8 lines in 1 file changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27924.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27924/head:pull/27924 PR: https://git.openjdk.org/jdk/pull/27924 From liach at openjdk.org Mon Oct 27 23:32:01 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Oct 2025 23:32:01 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> Message-ID: <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> On Mon, 27 Oct 2025 12:40:02 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 44: >> >>> 42: var cw = new ClassWriter(0); >>> 43: cw.visit(V17, ACC_PUBLIC, "Hidden", null, "java/lang/Object", null); >>> 44: for (int i = 0; i < 65530; i++) { >> >> Why 65530? An empty class definition already has 12 CP entries when compiled by javac. > > This is a magic number. 65536-5 gets CFE: class too large, 65536-7 doesn't get an CFE. Only 65536-6 caused the overflow. This is asm so asm may only be adding 6 entries. I kept the test as ASM rather than using ClassFile API because it might be good to backport this. If we have such a sensitive dependency on the CP size, we might consider opening up the `symbolTable.getConstantPoolCount()` on the `ClassWriter` for better testing, or use the ClassFile API that has a similar fine-grained control over constant pool sizes. I can help you update ASM or rewrite in ClassFile API if the Java code is too complex for you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2467431683 From macarte at openjdk.org Tue Oct 28 00:55:32 2025 From: macarte at openjdk.org (Mat Carter) Date: Tue, 28 Oct 2025 00:55:32 GMT Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command Message-ID: Add jcmd AOT.end_recording diagnostic command. When this command is issued, a targeted JVM that is currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated. The command will report back to the user one of the following messages depending on the state of the JVM: - Error! Not a recording run - Error! Not recording - Recording ended successfully - Error! Failed to end recording It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses: - Recording ended successfully - Error! Not recording ------------- Commit messages: - Switched line endings to unix style LF - Removed timing functionality as it's not needed yet - Sort headers correctly - 8370203 - Adding JCmd AOT.end_recording Changes: https://git.openjdk.org/jdk/pull/27965/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370203 Stats: 125 lines in 5 files changed: 125 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27965.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965 PR: https://git.openjdk.org/jdk/pull/27965 From dlong at openjdk.org Tue Oct 28 01:35:03 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 28 Oct 2025 01:35:03 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 02:56:36 GMT, David Holmes wrote: > If we only the print the stack up to the signal handler, and not all the way to the allocation, then won't the resulting stack trace be confusing for the reader? The stack trace starts at the most recent stack frames (the allocation) and works backwards through the callers (signal handler). So the signal handler frame looks like a special entry or "first" frame, similar to a thread start function or libc init code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27985#issuecomment-3454063293 From dlong at openjdk.org Tue Oct 28 01:40:05 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 28 Oct 2025 01:40:05 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 02:56:36 GMT, David Holmes wrote: > Yeah and it really should not do that. :( I agree, but I am not addressing that in this fix. There might be other legitimate reasons for wanting a stack trace during a signal handler, other than NMT allocation tracking, though off the top of my head I can't think of any :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27985#issuecomment-3454073879 From dholmes at openjdk.org Tue Oct 28 03:38:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Oct 2025 03:38:03 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 01:32:14 GMT, Dean Long wrote: > > If we only the print the stack up to the signal handler, and not all the way to the allocation, then won't the resulting stack trace be confusing for the reader? > > The stack trace starts at the most recent stack frames (the allocation) and works backwards through the callers (signal handler). So the signal handler frame looks like a special entry or "first" frame, similar to a thread start function or libc init code. Sorry I'm confused about which part of the stack - that preceding the signal handler, or that after - will be printed after this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27985#issuecomment-3454389084 From dholmes at openjdk.org Tue Oct 28 03:48:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Oct 2025 03:48:00 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> Message-ID: On Mon, 27 Oct 2025 12:21:28 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5528: >> >>> 5526: cp_size++; >>> 5527: // Check for overflow. cp_size is a u2. >>> 5528: precond(sizeof(cp_size) == sizeof(u2)); >> >> Why do you need to assert this given `u2 cp_size = ...` is the declaration? > > In case somebody changes it to int. There used to be talk about doing this so then the overflow check might have to be different. Hmm ... then I would prefer simply: // Don't change the type of cp_size without updating the overflow // check below. u2 cp_size = ...; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2467790726 From dholmes at openjdk.org Tue Oct 28 03:53:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Oct 2025 03:53:04 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 12:45:11 GMT, Coleen Phillimore wrote: >> Check for constant pool index overflow and throw ClassFormatError instead of crashing. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Test enhancement and comment. test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 53: > 51: } catch (ClassFormatError cfe) { > 52: String message = cfe.getMessage(); > 53: if (message == null && message.contains("Overflow in constant pool size for hidden class")) { Suggestion: if (message != null && message.contains("Overflow in constant pool size for hidden class")) { but isn't this the message you expect to see? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2467795643 From dlong at openjdk.org Tue Oct 28 04:04:00 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 28 Oct 2025 04:04:00 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 03:35:10 GMT, David Holmes wrote: > Sorry I'm confused about which part of the stack - that preceding the signal handler, or that after - will be printed after this fix. After, temporally. The history before the signal handler happened is erased. This should match the meaning of os::is_first_C_frame(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27985#issuecomment-3454425319 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added StatelessOopsFinder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/a886aa85..c6ea93c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00-01 Stats: 217 lines in 4 files changed: 211 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 08:48:40 GMT, Per Minborg wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added StatelessOopsFinder > > src/hotspot/share/cds/cdsHeapVerifier.cpp line 186: > >> 184: if (fd->signature()->starts_with("Ljdk/internal/access/") && >> 185: fd->signature()->ends_with("Access;")) { >> 186: // The jdk/internal/access/*Access classes carry no states so they can be safely > > This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes. I removed this hard-coded check and instead added `CDSHeapVerifier::add_shared_secret_accessors()`, which requires all AOT-initialized accessors to be stateless. I also added a negative test case for `SharedSecrets::javaObjectInputFilterAccess`, which is not stateless so it cannot be initialized in the AOT assembly phase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467807545 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 27 Oct 2025 13:25:56 GMT, ExE Boss wrote: > The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467809826 From iklam at openjdk.org Tue Oct 28 04:10:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:10:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 04:03:00 GMT, Ioi Lam wrote: >> The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`: >> >> SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() { >> public void checkArray(ObjectInputStream ois, Class arrayType, int arrayLength) throws ObjectStreamException { >> ois.checkArray(arrayType, arrayLength); >> } >> >> public String readString(ObjectInputStream ois) throws IOException { >> return ois.readString(); >> } >> }); > >> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. > > I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? > Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467814022 From iklam at openjdk.org Tue Oct 28 04:15:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:15:39 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v3] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8368199-add-aot-safe-class-initializer-annotation-to-shared-secrets - Added StatelessOopsFinder - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/c6ea93c3..6ae1172a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01-02 Stats: 20837 lines in 485 files changed: 12666 ins; 4954 del; 3217 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From syan at openjdk.org Tue Oct 28 04:22:20 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 28 Oct 2025 04:22:20 GMT Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent fails [v5] In-Reply-To: References: Message-ID: > Hi all, > > The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis. > > If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails. > > This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed. > > The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java. > > Change has been verified locally, test-fix only, no risk. SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into jbs8362087 - Merge branch 'openjdk:master' into jbs8362087 - Merge branch 'openjdk:master' into jbs8362087 - Add synchronized lock for addClassOptions - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26605/files - new: https://git.openjdk.org/jdk/pull/26605/files/d04cc981..997451c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=03-04 Stats: 40778 lines in 955 files changed: 23790 ins; 11903 del; 5085 mod Patch: https://git.openjdk.org/jdk/pull/26605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26605/head:pull/26605 PR: https://git.openjdk.org/jdk/pull/26605 From stefank at openjdk.org Tue Oct 28 06:56:01 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 28 Oct 2025 06:56:01 GMT Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads concurrently In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 20:00:15 GMT, Xiaolong Peng wrote: > As @shipilev mentioned in the description description of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), we could rearrange the code and ask GC to suspend after announcing safepoint, GC threads and Java threads will sync simultaneously. [The other option](https://github.com/openjdk/jdk/pull/27739/files) I have test is to split STS synchronize into `synchronize_begin` and `synchronize`, which makes GC thread suspension fully aysnc(same Java threads), but I didn't see big performance difference, therefore I chose the simple solution suggested by Aleksey. > > > Test: > - [x] tier1 I don't think this should be done for ZGC. We intentionally perform the lengthy GC syncronization before we start to synchronize the Java thread. With the proposed change the Java threads could end up blocking longer because they now also have to wait for the GC threads to synchronize. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27924#issuecomment-3454890490 From shade at openjdk.org Tue Oct 28 09:18:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 28 Oct 2025 09:18:06 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace ECS team also reports positive results with this patch. @jerboaa, take a look, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3455372973 From adinn at openjdk.org Tue Oct 28 09:36:22 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 28 Oct 2025 09:36:22 GMT Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 23:57:21 GMT, Mat Carter wrote: > Add jcmd AOT.end_recording diagnostic command. When this command is issued, a targeted JVM that is currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated. > > The command will report back to the user one of the following messages depending on the state of the JVM: > > - Error! Not a recording run > - Error! Not recording > - Recording ended successfully > - Error! Failed to end recording > > It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses: > > - Recording ended successfully > - Error! Not recording > > Passes tier1 on linux (x64) and windows (x64) src/hotspot/share/cds/aotMetaspace.cpp line 963: > 961: bool AOTMetaspace::is_recording_preimage_static_archive() { > 962: if (CDSConfig::is_dumping_preimage_static_archive()) { > 963: return _preimage_static_archive_dumped == 0; Do we need to use an acquiring load here? i.e. can the read here and the cmpxchg below happen in different threads? n.b. I'm not just thinking about the behaviour when this patch makes the DCmd available but also what happens when we supplement it with the MXBean interface to end recordings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2468726557 From alanb at openjdk.org Tue Oct 28 09:48:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 09:48:19 GMT Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 23:57:21 GMT, Mat Carter wrote: > Add jcmd AOT.end_recording diagnostic command. When this command is issued, a targeted JVM that is currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated. > > The command will report back to the user one of the following messages depending on the state of the JVM: > > - Error! Not a recording run > - Error! Not recording > - Recording ended successfully > - Error! Failed to end recording > > It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses: > > - Recording ended successfully > - Error! Not recording > > Passes tier1 on linux (x64) and windows (x64) src/hotspot/share/services/diagnosticCommand.cpp line 1009: > 1007: } > 1008: > 1009: output()->print_cr("Error! Failed to end recording"); Is there an error recorded or anything further that could be included for the error case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2468772668 From dholmes at openjdk.org Tue Oct 28 10:01:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Oct 2025 10:01:41 GMT Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads concurrently In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 20:00:15 GMT, Xiaolong Peng wrote: > As @shipilev mentioned in the description description of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), we could rearrange the code and ask GC to suspend after announcing safepoint, GC threads and Java threads will sync simultaneously. [The other option](https://github.com/openjdk/jdk/pull/27739/files) I have test is to split STS synchronize into `synchronize_begin` and `synchronize`, which makes GC thread suspension fully aysnc(same Java threads), but I didn't see big performance difference, therefore I chose the simple solution suggested by Aleksey. > > > Test: > - [x] tier1 This is really for GC folk to decide upon but a few general comments. This seems like a reasonable hypothesis but the JBS issue does not provide any detailed performance results for each of the GCs to shows the hypothesis is correct and there is some actual value to doing this. Tier1 testing alone does not seem sufficient to me. And which GCs on which platforms were tested? I have to wonder whether suspending the GC threads after taking the Threads_lock could have any unintended consequences? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27924#issuecomment-3455557440 From coleenp at openjdk.org Tue Oct 28 11:51:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 11:51:02 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> Message-ID: On Tue, 28 Oct 2025 03:45:25 GMT, David Holmes wrote: >> In case somebody changes it to int. There used to be talk about doing this so then the overflow check might have to be different. > > Hmm ... then I would prefer simply: > > // Don't change the type of cp_size without updating the overflow > // check below. > u2 cp_size = ...; That's a comment. The comment isn't executable. I prefer something that will fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469228533 From coleenp at openjdk.org Tue Oct 28 11:51:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 11:51:03 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> Message-ID: On Mon, 27 Oct 2025 23:28:00 GMT, Chen Liang wrote: >> This is a magic number. 65536-5 gets CFE: class too large, 65536-7 doesn't get an CFE. Only 65536-6 caused the overflow. This is asm so asm may only be adding 6 entries. I kept the test as ASM rather than using ClassFile API because it might be good to backport this. > > If we have such a sensitive dependency on the CP size, we might consider opening up the `symbolTable.getConstantPoolCount()` on the `ClassWriter` for better testing, or use the ClassFile API that has a similar fine-grained control over constant pool sizes. > > I can help you update ASM or rewrite in ClassFile API if the Java code is too complex for you. Let me try that ClassWriter method and see if that takes out the magic number. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469239074 From coleenp at openjdk.org Tue Oct 28 11:51:06 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 11:51:06 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 03:50:06 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Test enhancement and comment. > > test/hotspot/jtreg/runtime/ClassFile/HiddenClassesTest.java line 53: > >> 51: } catch (ClassFormatError cfe) { >> 52: String message = cfe.getMessage(); >> 53: if (message == null && message.contains("Overflow in constant pool size for hidden class")) { > > Suggestion: > > if (message != null && message.contains("Overflow in constant pool size for hidden class")) { > > but isn't this the message you expect to see? It should be message != null and !message.contains("the expected message"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469241763 From coleenp at openjdk.org Tue Oct 28 12:01:01 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 12:01:01 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> Message-ID: On Mon, 27 Oct 2025 23:28:00 GMT, Chen Liang wrote: >> This is a magic number. 65536-5 gets CFE: class too large, 65536-7 doesn't get an CFE. Only 65536-6 caused the overflow. This is asm so asm may only be adding 6 entries. I kept the test as ASM rather than using ClassFile API because it might be good to backport this. > > If we have such a sensitive dependency on the CP size, we might consider opening up the `symbolTable.getConstantPoolCount()` on the `ClassWriter` for better testing, or use the ClassFile API that has a similar fine-grained control over constant pool sizes. > > I can help you update ASM or rewrite in ClassFile API if the Java code is too complex for you. @liach I have no idea how to do this, can you help? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469298381 From forax at openjdk.org Tue Oct 28 12:29:05 2025 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 28 Oct 2025 12:29:05 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v2] In-Reply-To: References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> Message-ID: On Tue, 28 Oct 2025 11:58:49 GMT, Coleen Phillimore wrote: >> If we have such a sensitive dependency on the CP size, we might consider opening up the `symbolTable.getConstantPoolCount()` on the `ClassWriter` for better testing, or use the ClassFile API that has a similar fine-grained control over constant pool sizes. >> >> I can help you update ASM or rewrite in ClassFile API if the Java code is too complex for you. > > @liach I have no idea how to do this, can you help? ClassWriter.newUTF8() returns the index in the constant pool so you can use that information int maxCPIndex = cw.newUTF8(Integer.toString(-1)); int maxEntry = 65535 - maxCPIndex - 1; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469392915 From coleenp at openjdk.org Tue Oct 28 12:37:24 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 12:37:24 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v3] In-Reply-To: References: Message-ID: <7MKimls6I_Yd-VZULonBO-XMmucusfLoTuRe4tNr4HA=.215a4f49-ea3c-4528-bedf-1bedf61ccb82@github.com> > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/0d982a7b..cd8c07e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From coleenp at openjdk.org Tue Oct 28 13:11:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 13:11:43 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v4] In-Reply-To: References: Message-ID: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make test not have magic number. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/cd8c07e8..170416ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=02-03 Stats: 18 lines in 1 file changed: 16 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From coleenp at openjdk.org Tue Oct 28 13:11:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Oct 2025 13:11:44 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v4] In-Reply-To: References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> Message-ID: <7KCTM19LDq03i-J6lxi50UkqvGD8Tb_k49IA3S4tXU8=.5b4e889c-5e3d-4fd2-87e6-9912ef94bf75@github.com> On Tue, 28 Oct 2025 12:25:57 GMT, R?mi Forax wrote: >> @liach I have no idea how to do this, can you help? Is see symbolTable is internal to ClassWriter and things are added in toByteArray. I would have to add a method to ClassWriter to get the default size of an empty class. >> >> // IMPORTANT: this must be the last part of the ClassFile size computation, because the previous >> // statements can add attribute names to the constant pool, thereby changing its size! >> size += symbolTable.getConstantPoolLength(); >> int constantPoolCount = symbolTable.getConstantPoolCount(); >> if (constantPoolCount > 0xFFFF) { >> throw new ClassTooLargeException(symbolTable.getClassName(), constantPoolCount); >> } >> >> Create an empty class, call new API to get constant pool length, then do the loop to create the overflowing class. > > ClassWriter.newUTF8() returns the index in the constant pool so you can use that information > > > int maxCPIndex = cw.newUTF8(Integer.toString(-1)); > int maxEntry = 65535 - maxCPIndex - 1; I think I figured it out. It's sort of um interesting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2469509255 From heidinga at openjdk.org Tue Oct 28 14:01:34 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 28 Oct 2025 14:01:34 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v3] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 04:06:57 GMT, Ioi Lam wrote: >>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. >> >> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? > >> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? > > @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2469685015 From mbaesken at openjdk.org Tue Oct 28 16:45:26 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 28 Oct 2025 16:45:26 GMT Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files [v4] In-Reply-To: References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken wrote: >> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). >> error output is : >> >> >> java.lang.RuntimeException: Expected source information missing from output >> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1474) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust style nit Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3457451232 From mbaesken at openjdk.org Tue Oct 28 16:45:27 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 28 Oct 2025 16:45:27 GMT Subject: Integrated: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com> Message-ID: <6IiPqABpO9Lw0pU4jR9FknSre6Zlt6DvhZYSycO6YIY=.e0a6c88e-0902-48fd-85c9-dc5f20eec2b6@github.com> On Mon, 20 Oct 2025 12:47:52 GMT, Matthias Baesken wrote: > When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available). > error output is : > > > java.lang.RuntimeException: Expected source information missing from output > at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) This pull request has now been integrated. Changeset: 69a9b4ce Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/69a9b4ceaf3852a299ee268a39e56575ad8207ab Stats: 30 lines in 4 files changed: 27 ins; 0 del; 3 mod 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java fails on Windows when using stripped pdb files Reviewed-by: dholmes, clanger ------------- PR: https://git.openjdk.org/jdk/pull/27899 From macarte at openjdk.org Tue Oct 28 17:02:25 2025 From: macarte at openjdk.org (Mat Carter) Date: Tue, 28 Oct 2025 17:02:25 GMT Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command In-Reply-To: References: Message-ID: <73mIYRuGWI0kSUKqXQdb7MPjZqXwM9s4-EuZw6qeiWo=.8814d782-f332-4033-b43b-7317a82c8650@github.com> On Tue, 28 Oct 2025 09:33:28 GMT, Andrew Dinn wrote: >> Add jcmd AOT.end_recording diagnostic command. When this command is issued, a targeted JVM that is currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated. >> >> The command will report back to the user one of the following messages depending on the state of the JVM: >> >> - Error! Not a recording run >> - Error! Not recording >> - Recording ended successfully >> - Error! Failed to end recording >> >> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses: >> >> - Recording ended successfully >> - Error! Not recording >> >> Passes tier1 on linux (x64) and windows (x64) > > src/hotspot/share/cds/aotMetaspace.cpp line 963: > >> 961: bool AOTMetaspace::is_recording_preimage_static_archive() { >> 962: if (CDSConfig::is_dumping_preimage_static_archive()) { >> 963: return _preimage_static_archive_dumped == 0; > > Do we need to use an acquiring load here? i.e. can the read here and the cmpxchg below happen in different threads? > n.b. I'm not just thinking about the behaviour when this patch makes the DCmd available but also what happens when we supplement it with the MXBean interface to end recordings. I think it's okay as ending the recording is controlled by the cmpxchg, even if two threads think the recording is still going on, only one call to end the recording will work, and if the threads both check whether the recording has completed they will both see that it has (regardless of which thread 'won') ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2470342427 From macarte at openjdk.org Tue Oct 28 17:02:27 2025 From: macarte at openjdk.org (Mat Carter) Date: Tue, 28 Oct 2025 17:02:27 GMT Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 09:45:29 GMT, Alan Bateman wrote: >> Add jcmd AOT.end_recording diagnostic command. When this command is issued, a targeted JVM that is currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated. >> >> The command will report back to the user one of the following messages depending on the state of the JVM: >> >> - Error! Not a recording run >> - Error! Not recording >> - Recording ended successfully >> - Error! Failed to end recording >> >> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses: >> >> - Recording ended successfully >> - Error! Not recording >> >> Passes tier1 on linux (x64) and windows (x64) > > src/hotspot/share/services/diagnosticCommand.cpp line 1009: > >> 1007: } >> 1008: >> 1009: output()->print_cr("Error! Failed to end recording"); > > Is there an error recorded or anything further that could be included for the error case? There is not, currently, the aotMetaspace method throws an exception if something goes wrong. I added this line in case the flow in aotMetaspace changes. The logic here is that if we asked the recording to stop, but it's still recording then we report to the user that 'we failed to stop the recording' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2470350546 From iklam at openjdk.org Tue Oct 28 18:51:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 18:51:40 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Updated comments about @AOTSafeClassInitializer in SharedSecrets.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/6ae1172a..3121fd11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02-03 Stats: 15 lines in 1 file changed: 12 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From iklam at openjdk.org Tue Oct 28 18:51:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 18:51:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 13:57:46 GMT, Dan Heidinga wrote: >>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? >> >> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. > > Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context? I updated the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2470693374 From heidinga at openjdk.org Tue Oct 28 18:57:01 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 28 Oct 2025 18:57:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java Marked as reviewed by heidinga (no project role). ------------- PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3390359439 From simonis at openjdk.org Tue Oct 28 20:17:47 2025 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 28 Oct 2025 20:17:47 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace I'm not an expert in this area, but after looking at [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) and its two rather lengthy review threads for [PR #17198](https://github.com/openjdk/jdk/pull/17198) (which was abandoned) and [PR #20646](https://github.com/openjdk/jdk/pull/20646) which was finally approved and which contained the [changes which led to this regression](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131) it seems that @jerboaa's comment [in the first PR](https://github.com/openjdk/jdk/pull/17198#discussion_r1673797261): > *It is the hope to no longer needing to do this hierarchical look-up since we know where in the hierarchy we ought to look for the memory limit.* which referred to this code: bool is_ok = reader()->read_numerical_key_value("/memory.stat", "hierarchical_memory_limit", &hier_memlimit); if (!is_ok) { return OSCONTAINER_ERROR; } log_trace(os, container)("Hierarchical Memory Limit is: " JULONG_FORMAT, hier_memlimit); if (hier_memlimit < phys_mem) { verbose_log(hier_memlimit, phys_mem); return (jlong)hier_memlimit; } log_trace(os, container)("Hierarchical Memory Limit is: Unlimited"); was a little bit too optimistic, and finally led to this regression. I'm therefore inclined to approve this fix after sleeping on it one more night :) ------------- PR Review: https://git.openjdk.org/jdk/pull/28006#pullrequestreview-3390624209 From xpeng at openjdk.org Tue Oct 28 21:42:30 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 28 Oct 2025 21:42:30 GMT Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads concurrently In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 06:53:32 GMT, Stefan Karlsson wrote: > I don't think this should be done for ZGC. We intentionally perform the lengthy GC syncronization before we start to synchronize the Java thread. With the proposed change the Java threads could end up blocking longer because they now also have to wait for the GC threads to synchronize. Thanks for the feedback, now I think I know why Kim said it won't help ZGC. The simple solution in PR applies to all GCs, we may still the more sophisticated solution like https://github.com/openjdk/jdk/pull/27739 so we can control the behavior on individual GC if necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27924#issuecomment-3458606384 From lmesnik at openjdk.org Tue Oct 28 23:38:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 28 Oct 2025 23:38:41 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory Message-ID: There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. The tests that are incompatible with test thread factory are marked with test.thread.factory == null and the tests that are rather incompatible with virtual threads are makred with test.thread.factory != "Virtual" ------------- Commit messages: - 8370851: Mark hotspot and jdk tests incompatible with test thread factory Changes: https://git.openjdk.org/jdk/pull/28030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370851 Stats: 32 lines in 14 files changed: 17 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From dholmes at openjdk.org Wed Oct 29 01:30:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Oct 2025 01:30:01 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v4] In-Reply-To: References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> Message-ID: On Tue, 28 Oct 2025 11:42:36 GMT, Coleen Phillimore wrote: >> Hmm ... then I would prefer simply: >> >> // Don't change the type of cp_size without updating the overflow >> // check below. >> u2 cp_size = ...; > > That's a comment. The comment isn't executable. I prefer something that will fail. We don't generally do this kind of thing though. We would have tons of code that depends on the type of various variables and we don't assert that those variables have the declared type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2471497905 From dholmes at openjdk.org Wed Oct 29 01:38:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Oct 2025 01:38:03 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v4] In-Reply-To: References: Message-ID: <9zI7OdA_3nSVkzEYK6kPeqVuqbc48n4RBRKclAz4JpY=.2e121310-1885-4373-b50e-4b62515a9773@github.com> On Tue, 28 Oct 2025 13:11:43 GMT, Coleen Phillimore wrote: >> Check for constant pool index overflow and throw ClassFormatError instead of crashing. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make test not have magic number. Other than the assert (not precond please), this looks fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27964#pullrequestreview-3391409599 From iklam at openjdk.org Wed Oct 29 02:53:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 02:53:09 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java Thanks everyone for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27880#issuecomment-3459415761 From liach at openjdk.org Wed Oct 29 03:23:04 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Oct 2025 03:23:04 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java The updated comments look very clear. Thanks! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3391539750 From iklam at openjdk.org Wed Oct 29 03:26:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 03:26:16 GMT Subject: Integrated: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. This pull request has now been integrated. Changeset: 0687f120 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/0687f120cc324f35fe43d811b6beb4184fd854ec Stats: 260 lines in 10 files changed: 224 ins; 35 del; 1 mod 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Reviewed-by: liach, heidinga ------------- PR: https://git.openjdk.org/jdk/pull/27880 From iklam at openjdk.org Wed Oct 29 04:35:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 04:35:41 GMT Subject: RFR: 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 Message-ID: The test expects output like this CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed. But the actual output is: CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers ------------- Commit messages: - 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 Changes: https://git.openjdk.org/jdk/pull/28035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370797 Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28035/head:pull/28035 PR: https://git.openjdk.org/jdk/pull/28035 From dholmes at openjdk.org Wed Oct 29 05:04:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Oct 2025 05:04:02 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 23:09:20 GMT, Dean Long wrote: > The problem is code called from a signal handler, like SharedRuntime::handle_unsafe_access(), can call os::malloc(), and when NMT is enabled, we try to get a stack backtrace. But os::get_native_stack() does not know how to walk through signal handler frames. > > This fix introduces FirstNativeFrameMark to be used by the POSIX version of os::get_native_stack() to set a frame to stop at in the POSIX signal handler. src/hotspot/os/posix/signals_posix.cpp line 575: > 573: // We are called from a signal handler, so stop the stack backtrace here. > 574: // See os::is_first_C_frame() in os::get_native_stack(). > 575: os::FirstNativeFrameMark fnfm; Won't this break stack-walking in hs_err file generation when we get a SEGV for example? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27985#discussion_r2471742737 From alanb at openjdk.org Wed Oct 29 07:00:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Oct 2025 07:00:04 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > 26: * @bug 8284161 8303242 > 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads > 28: * @requires test.thread.factory != "Virtual" This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2471923090 From stuefe at openjdk.org Wed Oct 29 07:04:06 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 29 Oct 2025 07:04:06 GMT Subject: RFR: 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 04:28:59 GMT, Ioi Lam wrote: > The test expects output like this > > > CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed. > > > But the actual output is: > > > CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers Ok. Thanks for fixing. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28035#pullrequestreview-3391930386 From sspitsyn at openjdk.org Wed Oct 29 08:19:13 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 29 Oct 2025 08:19:13 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 12:23:05 GMT, Sergey Chernyshev wrote: >> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8319589 >> - Removed unused native method >> - addressed review comment #2 >> - Apply suggestions from code review >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> >> Co-authored-by: Andrey Turbanov >> - addressed review comments >> - 8319589: Attach from root to a user java process not supported in Mac > > @sspitsyn Could you please have a look at this PR ? @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3460308914 From sgehwolf at openjdk.org Wed Oct 29 09:40:03 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 29 Oct 2025 09:40:03 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace > I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3460594125 From aboldtch at openjdk.org Wed Oct 29 09:50:48 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 29 Oct 2025 09:50:48 GMT Subject: RFR: 8369983: Remove expired ZGC flags for JDK 26 In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 08:44:04 GMT, Joel Sikstr?m wrote: > Hello, > > The ZGenerational flag was obsoleted in JDK 24 as part of removing the non-generational mode of ZGC in JEP 490. The flag was still obsolete in JDK 25, which is a LTS version, so that user's that might specify/try to use it are prompted with a warning. Now that we're past JDK 25, the flag should be expired. Likewise, the ZMarkStackSpaceLimit flag was obsoleted in JDK 25 and can now be expired in JDK 26. > > Since neither of these flags were documented in `java.md` I haven't added them to the "Removed Java Options" section in that file. Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27838#pullrequestreview-3392466355 From jsikstro at openjdk.org Wed Oct 29 10:01:24 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 29 Oct 2025 10:01:24 GMT Subject: RFR: 8369983: Remove expired ZGC flags for JDK 26 In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 12:20:33 GMT, Albert Mingkun Yang wrote: >> Hello, >> >> The ZGenerational flag was obsoleted in JDK 24 as part of removing the non-generational mode of ZGC in JEP 490. The flag was still obsolete in JDK 25, which is a LTS version, so that user's that might specify/try to use it are prompted with a warning. Now that we're past JDK 25, the flag should be expired. Likewise, the ZMarkStackSpaceLimit flag was obsoleted in JDK 25 and can now be expired in JDK 26. >> >> Since neither of these flags were documented in `java.md` I haven't added them to the "Removed Java Options" section in that file. > > Marked as reviewed by ayang (Reviewer). Thank you for the reviews! @albertnetymk @xmas92 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27838#issuecomment-3460667531 From jsikstro at openjdk.org Wed Oct 29 10:01:25 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 29 Oct 2025 10:01:25 GMT Subject: Integrated: 8369983: Remove expired ZGC flags for JDK 26 In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 08:44:04 GMT, Joel Sikstr?m wrote: > Hello, > > The ZGenerational flag was obsoleted in JDK 24 as part of removing the non-generational mode of ZGC in JEP 490. The flag was still obsolete in JDK 25, which is a LTS version, so that user's that might specify/try to use it are prompted with a warning. Now that we're past JDK 25, the flag should be expired. Likewise, the ZMarkStackSpaceLimit flag was obsoleted in JDK 25 and can now be expired in JDK 26. > > Since neither of these flags were documented in `java.md` I haven't added them to the "Removed Java Options" section in that file. This pull request has now been integrated. Changeset: d8515f08 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/d8515f084dcd537ccad98f9b15f257baeffae222 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8369983: Remove expired ZGC flags for JDK 26 Reviewed-by: ayang, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/27838 From coleenp at openjdk.org Wed Oct 29 11:49:32 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 29 Oct 2025 11:49:32 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v5] In-Reply-To: References: Message-ID: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Change precond to an assert with a comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/170416ed..e45c594f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From shade at openjdk.org Wed Oct 29 12:04:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Oct 2025 12:04:28 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: <4HrFjUDMpB3yS0vpDbo0glc0mpvuTsdRtXiyRjYuKiw=.893e4e38-123d-4962-a598-1f6c059e9959@github.com> On Wed, 29 Oct 2025 09:36:54 GMT, Severin Gehwolf wrote: > Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. Yes, I tried to write a test, but it was not simple at all. AFAICS, you need to configure the _host_ in a particular way to get to the interesting configuration, when part of hierarchy is hidden. So not only it would require root, it would also make changes to the host cgroup config (and properly revert them at the end of testing!). It would be better if we could come up with something like Docker-in-Docker kind of test, but that is probably a headache as well. Anyway, we are dealing with the real-world, customer-facing breakage here, so I reasoned it was unwise to delay the immediately deployable fix, just because it was unclear how to write a reliable regression test for it :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3461156992 From kvn at openjdk.org Wed Oct 29 16:52:06 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 29 Oct 2025 16:52:06 GMT Subject: RFR: 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 04:28:59 GMT, Ioi Lam wrote: > The test expects output like this > > > CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed. > > > But the actual output is: > > > CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28035#pullrequestreview-3394822718 From simonis at openjdk.org Wed Oct 29 17:21:30 2025 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 29 Oct 2025 17:21:30 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <4HrFjUDMpB3yS0vpDbo0glc0mpvuTsdRtXiyRjYuKiw=.893e4e38-123d-4962-a598-1f6c059e9959@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> <4HrFjUDMpB3yS0vpDbo0glc0mpvuTsdRtXiyRjYuKiw=.893e4e38-123d-4962-a598-1f6c059e9959@github.com> Message-ID: <20_sQBgrjw9Y5AGRunOzNNDnXMuEx5-Ya2EUcy8-gr8=.13fdb140-87c9-4faa-beee-51f19bdf9f77@github.com> On Wed, 29 Oct 2025 12:01:22 GMT, Aleksey Shipilev wrote: >>> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > >> Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > > Yes, I tried to write a test, but it was not simple at all. AFAICS, you need to configure the _host_ in a particular way to get to the interesting configuration, when part of hierarchy is hidden. So not only it would require root, it would also make changes to the host cgroup config (and properly revert them at the end of testing!). It would be better if we could come up with something like Docker-in-Docker kind of test, but that is probably a headache as well. > > Anyway, we are dealing with the real-world, customer-facing breakage here, so I reasoned it was unwise to delay the immediately deployable fix, just because it was unclear how to write a reliable regression test for it :) So here's a simple test (based on [`test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java`](https://github.com/openjdk/jdk/blob/28f2591bad49c4d1590325c3d315d850ab6bcc7d/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java) which basically implements @shipilev Docker reproducer. It only runs if the user is `root` or a `sudo` user and if the system supports cgroup v1. The test fails with the current implementation and succeeds with the patch proposed in this PR. /* * Copyright (c) 2018, 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 * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import java.io.BufferedWriter; import java.nio.file.Files; import java.nio.file.Path; import jdk.internal.platform.Metrics; import jdk.test.lib.Utils; import jdk.test.lib.containers.docker.Common; import jdk.test.lib.containers.docker.DockerRunOptions; import jdk.test.lib.containers.docker.DockerTestUtils; import jdk.test.lib.process.OutputAnalyzer; import jdk.test.lib.process.ProcessTools; import jtreg.SkippedException; /* * @test * @key cgroups * @bug 8370572 * @summary Test that the Cgroups hierarchical memory limit is honored * @requires container.support * @requires !vm.asan * @library /test/lib * @modules java.base/jdk.internal.platform * @run main/timeout=360 TestHierarchicalMemoryLimit */ public class TestHierarchicalMemoryLimit { private static final String imageName = Common.imageName("metrics-memory"); private static final long memLimit = 1024 * 1024 * 1024; // Should probably be a multiple of page size private static final String memLimitString = String.valueOf(memLimit); public static void main(String[] args) throws Exception { if (!DockerTestUtils.canTestDocker()) { return; } try { OutputAnalyzer oa = ProcessTools.executeProcess("sudo", "-n", "mkdir", "/sys/fs/cgroup/memory/jtreg-test-parent"); if (oa.getExitValue() != 0) { if (oa.getStderr().contains("Permission denied")) { throw new SkippedException("Must be root or sudo user for this test. (original error was: " + oa.getStderr() + ")"); } else { throw new SkippedException("Must have cgroup v1 for this test. (original error was: " + oa.getStderr() + ")"); } } Path setMemoryLimit = Files.createTempFile("setMemoryLimit", ".sh"); setMemoryLimit.toFile().deleteOnExit(); try (BufferedWriter writer = Files.newBufferedWriter(setMemoryLimit)) { writer.write("echo " + memLimitString + " > /sys/fs/cgroup/memory/jtreg-test-parent/memory.limit_in_bytes"); setMemoryLimit.toFile().setExecutable(true); } oa = ProcessTools.executeProcess("sudo", "-n", setMemoryLimit.toString()); if (oa.getExitValue() != 0) { throw new SkippedException("Can't set jtreg-test-parent/memory.limit_in_bytes. (original error was: " + oa.getStderr() + ")"); } // These tests create a docker image and run this image with // varying docker memory options. The arguments passed to the docker // container include the Java test class to be run along with the // resource to be examined and expected result. DockerTestUtils.buildJdkContainerImage(imageName); try { testHierarchicalMemoryLimit(memLimitString); } finally { if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { DockerTestUtils.removeDockerImage(imageName); } } } finally { ProcessTools.executeProcess("sudo", "-n", "rmdir", "/sys/fs/cgroup/memory/jtreg-test-parent"); } } private static void testHierarchicalMemoryLimit(String value) throws Exception { Common.logNewTestCase("testHierarchicalMemoryLimit, value = " + value); DockerRunOptions opts = new DockerRunOptions(imageName, "/jdk/bin/java", "-version"); opts.addDockerOpts("--volume", Utils.TEST_CLASSES + ":/test-classes/") .addDockerOpts("--cgroup-parent=/jtreg-test-parent") .addJavaOpts("-cp", "/test-classes/") .addJavaOpts("--add-exports", "java.base/jdk.internal.platform=ALL-UNNAMED", "-Xlog:os+container=trace", "-XX:InitialRAMPercentage=25", "-XX:MaxRAMPercentage=25", "-Xlog:gc+init"); OutputAnalyzer oa = DockerTestUtils.dockerRunJava(opts).shouldHaveExitValue(0); String gcMemoryLine = oa.asLines().stream() .filter(line -> line.contains("gc,init")) .filter(line -> line.contains("Memory")) .findFirst().get(); String gcMemory = gcMemoryLine.substring(gcMemoryLine.lastIndexOf(" ") + 1, gcMemoryLine.length() - 1); char gcUnit = gcMemoryLine.charAt(gcMemoryLine.length() - 1); System.out.println(gcMemory + gcUnit); long unit = 1; switch (gcUnit) { case 'K' : unit = 1024; break; case 'M' : unit = 1024 * 1024; break; case 'G' : unit = 1024 * 1024 * 1024; break; } long memory = Integer.parseInt(gcMemory) * unit; if (memLimit != memory) { throw new Exception("Pysical memory should be " + memLimit + " but was " + memory); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3462760365 From shade at openjdk.org Wed Oct 29 17:32:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Oct 2025 17:32:23 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <4HrFjUDMpB3yS0vpDbo0glc0mpvuTsdRtXiyRjYuKiw=.893e4e38-123d-4962-a598-1f6c059e9959@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> <4HrFjUDMpB3yS0vpDbo0glc0mpvuTsdRtXiyRjYuKiw=.893e4e38-123d-4962-a598-1f6c059e9959@github.com> Message-ID: <-450vlImKWp5wjlxCPCUUdAUCiFmg6qT0io7vajhlys=.0e419f91-0dbe-411e-b334-82289264eb5b@github.com> On Wed, 29 Oct 2025 12:01:22 GMT, Aleksey Shipilev wrote: >>> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > >> Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > > Yes, I tried to write a test, but it was not simple at all. AFAICS, you need to configure the _host_ in a particular way to get to the interesting configuration, when part of hierarchy is hidden. So not only it would require root, it would also make changes to the host cgroup config (and properly revert them at the end of testing!). It would be better if we could come up with something like Docker-in-Docker kind of test, but that is probably a headache as well. > > Anyway, we are dealing with the real-world, customer-facing breakage here, so I reasoned it was unwise to delay the immediately deployable fix, just because it was unclear how to write a reliable regression test for it :) > So here's a simple test (based on [`test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java`](https://github.com/openjdk/jdk/blob/28f2591bad49c4d1590325c3d315d850ab6bcc7d/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java) which basically implements @shipilev Docker reproducer. It only runs if the user is `root` or a `sudo` user and if the system supports cgroup v1. The test fails with the current implementation and succeeds with the patch proposed in this PR. Thanks! It has the disadvantages I listed before: requires super-user, modifies host cgroup configuration, needs to clean up after itself, etc. As it stands now, it is not an automatic test (anyone runs jtreg-s with root privileges?), so it does not buy us any regression testing posture much right now. And we will spend time bike-shedding and dealing with (likely) testbugs from it. So I would very much prefer to integrate this fix without a test, backport the to 25u and 21u ASAP to unbreak users, and _then_ follow-up with the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3462801122 From simonis at openjdk.org Wed Oct 29 17:37:48 2025 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 29 Oct 2025 17:37:48 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace Fine with me either way, but I agree that this issue has to be fixed as quickly as possible. I leave the final decision whether to include the test or not up to @jerboaa . ------------- Marked as reviewed by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28006#pullrequestreview-3394975054 From duke at openjdk.org Wed Oct 29 17:42:05 2025 From: duke at openjdk.org (Nityanand Rai) Date: Wed, 29 Oct 2025 17:42:05 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls Message-ID: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs ------------- Commit messages: - remove extra whitespace - remove extra whitespace - Merge branch 'openjdk:master' into macos-vm-tagging - Covered ZGC direct mmap usage for JAVA tagging. Added unit test to validate changes - Merge branch 'openjdk:master' into macos-vm-tagging - Merge branch 'openjdk:master' into macos-vm-tagging - Merge branch 'openjdk:master' into macos-vm-tagging - Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking Changes: https://git.openjdk.org/jdk/pull/27868/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370254 Stats: 150 lines in 3 files changed: 148 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868 PR: https://git.openjdk.org/jdk/pull/27868 From phh at openjdk.org Wed Oct 29 17:42:06 2025 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 29 Oct 2025 17:42:06 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Message-ID: On Fri, 17 Oct 2025 17:01:02 GMT, Nityanand Rai wrote: > Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs Imo, be a good idea to include os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp, which has 3 uses that should probably be marked with VM_MEMORY_JAVA. #if defined(__APPLE__) of course. Thanks, lgtm. ------------- PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3358106513 Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3394703360 From eastigeevich at openjdk.org Wed Oct 29 17:42:07 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 29 Oct 2025 17:42:07 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Message-ID: On Fri, 17 Oct 2025 17:01:02 GMT, Nityanand Rai wrote: > Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs https://bugs.openjdk.org/browse/JDK-8370238 @nityarai08 , What macOS and Xcode versions are required to support `VM_MEMORY_JAVA` tag? OpenJDK macOS recommendation: > It is recommended that you use at least macOS 14 and Xcode 15.4, but earlier versions may also work. It would be nice to have a gtest. src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp line 111: > 109: #else > 110: const void* const res = mmap((void*)addr, length, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > 111: #endif Maybe this code has better readability: - A global constant constexpr int mmap_fd = #ifdef __APPLE__ VM_MAKE_TAG(VM_MEMORY_JAVA); #else -1; #endif In all `mmap` we replace `-1` with `mmap_fd`. This will minimize the number of `#ifdef`. test/hotspot/gtest/runtime/test_os_bsd_memory_tagging.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2025, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Correct lines are: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ``` test/hotspot/gtest/runtime/test_os_bsd_memory_tagging.cpp line 34: > 32: // Test that memory allocations on macOS are properly tagged with VM_MEMORY_JAVA > 33: // This validates the VM_MAKE_TAG(VM_MEMORY_JAVA) changes in os_bsd.cpp > 34: class BSDMemoryTaggingTest : public ::testing::Test { This test does not test new JVM runtime code. I found there are tests which might test this code: - test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp - test/hotspot/gtest//runtime/test_os.cpp You need to check if they cover your changes. If not, you need to add tests to `test_os_bsd.cpp`. Also there are tests for ZGC in `test/hotspot/gtest/gc/z`. You need to check if any of them cover your changes. IMO, `is_memory_tagged_as_java` will be needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3422396080 PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3422444972 PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2474311804 PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2474262825 PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2474369331 From duke at openjdk.org Wed Oct 29 17:42:07 2025 From: duke at openjdk.org (Nityanand Rai) Date: Wed, 29 Oct 2025 17:42:07 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Message-ID: On Fri, 17 Oct 2025 17:01:02 GMT, Nityanand Rai wrote: > Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs > Imo, be a good idea to include os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp, which has 3 uses that should probably be marked with VM_MEMORY_JAVA. #if defined(**APPLE**) of course. Covered ZGC direct mmap calls as well ------------- PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3429515987 From duke at openjdk.org Wed Oct 29 17:42:08 2025 From: duke at openjdk.org (Nityanand Rai) Date: Wed, 29 Oct 2025 17:42:08 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls In-Reply-To: References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Message-ID: On Tue, 21 Oct 2025 20:53:21 GMT, Nityanand Rai wrote: >> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs > >> Imo, be a good idea to include os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp, which has 3 uses that should probably be marked with VM_MEMORY_JAVA. #if defined(**APPLE**) of course. > > Covered ZGC direct mmap calls as well > @nityarai08 , > > What macOS and Xcode versions are required to support `VM_MEMORY_JAVA` tag? > > OpenJDK macOS recommendation: > > > It is recommended that you use at least macOS 14 and Xcode 15.4, but earlier versions may also work. > > It would be nice to have a gtest. Added a gtest and validated on macOS 15.6.1 and Xcode 16.2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3429522593 From eastigeevich at openjdk.org Wed Oct 29 17:44:39 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 29 Oct 2025 17:44:39 GMT Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com> Message-ID: <2yddz-oh3R_8sZlR6zagp-aoev24wvWTGw_7yFCL1yo=.9ad83098-76c8-41d5-9645-63335cb0b2a2@github.com> On Fri, 17 Oct 2025 17:01:02 GMT, Nityanand Rai wrote: > Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs The PR needs gtest/jtreg testing results. Also it needs to be checks the new code is covered by existing gtests or new tests are needed. ------------- Changes requested by eastigeevich (Committer). PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3394993477 From shade at openjdk.org Wed Oct 29 17:46:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Oct 2025 17:46:43 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: <6CtMQtXSG6NuW6MD0QOZ11oXtd5VReax9iIVpNgMcXg=.20c3b8a3-d5da-4ef5-b1fd-099a4e840e8d@github.com> On Wed, 29 Oct 2025 09:36:54 GMT, Severin Gehwolf wrote: >> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also no need to touch the other getter >> - Whitespace > >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. > > Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > I leave the final decision whether to include the test or not up to @jerboaa . In one of those cases, could you please submit the related RFE and PR the test from there? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3462847145 From iklam at openjdk.org Wed Oct 29 18:43:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 18:43:13 GMT Subject: Integrated: 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 04:28:59 GMT, Ioi Lam wrote: > The test expects output like this > > > CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed. > > > But the actual output is: > > > CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers This pull request has now been integrated. Changeset: 6080ccd2 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/6080ccd23239a5209dfb21bd0a413a116709af76 Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 Reviewed-by: stuefe, kvn ------------- PR: https://git.openjdk.org/jdk/pull/28035 From iklam at openjdk.org Wed Oct 29 18:43:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 18:43:12 GMT Subject: RFR: 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 07:01:41 GMT, Thomas Stuefe wrote: >> The test expects output like this >> >> >> CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed. >> >> >> But the actual output is: >> >> >> CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers > > Ok. Thanks for fixing. Thanks @tstuefe @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28035#issuecomment-3463184124 From lmesnik at openjdk.org Wed Oct 29 19:01:56 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 29 Oct 2025 19:01:56 GMT Subject: RFR: 8370905: Update vm.defmeth tests to use virtual threads Message-ID: The vm.defmeth stress tests should use `TestThreadFactory.newThread()` to start virtual threads if test thread factory is used. ------------- Commit messages: - 8370905: Update vm.defmeth tests to use virtual threads Changes: https://git.openjdk.org/jdk/pull/28048/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370905 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28048.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28048/head:pull/28048 PR: https://git.openjdk.org/jdk/pull/28048 From duke at openjdk.org Wed Oct 29 19:12:32 2025 From: duke at openjdk.org (Larry Cable) Date: Wed, 29 Oct 2025 19:12:32 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 08:16:06 GMT, Serguei Spitsyn wrote: >> @sspitsyn Could you please have a look at this PR ? > > @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert. @sspitsyn and @sercher I'll take a look since I familiar with the code and the platform... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3463384565 From matsaave at openjdk.org Wed Oct 29 19:35:42 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 29 Oct 2025 19:35:42 GMT Subject: RFR: 8365940: Misleading macro in jvm_md.h:57 Message-ID: The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests. ------------- Commit messages: - 8365940: Misleading macro in jvm_md.h:57 Changes: https://git.openjdk.org/jdk/pull/28049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365940 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28049/head:pull/28049 PR: https://git.openjdk.org/jdk/pull/28049 From dlong at openjdk.org Wed Oct 29 22:36:05 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 29 Oct 2025 22:36:05 GMT Subject: RFR: 8358725: RunThese30M: assert(nm->insts_contains_inclusive(original_pc)) failed: original PC must be in the main code section of the compiled method (or must be immediately following it) In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 05:01:28 GMT, David Holmes wrote: >> The problem is code called from a signal handler, like SharedRuntime::handle_unsafe_access(), can call os::malloc(), and when NMT is enabled, we try to get a stack backtrace. But os::get_native_stack() does not know how to walk through signal handler frames. >> >> This fix introduces FirstNativeFrameMark to be used by the POSIX version of os::get_native_stack() to set a frame to stop at in the POSIX signal handler. > > src/hotspot/os/posix/signals_posix.cpp line 575: > >> 573: // We are called from a signal handler, so stop the stack backtrace here. >> 574: // See os::is_first_C_frame() in os::get_native_stack(). >> 575: os::FirstNativeFrameMark fnfm; > > Won't this break stack-walking in hs_err file generation when we get a SEGV for example? Yes, I suppose so. Good catch. We shouldn't consider the "first frame" marker if we are starting before it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27985#discussion_r2475788254 From sspitsyn at openjdk.org Wed Oct 29 23:32:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 29 Oct 2025 23:32:12 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v6] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 08:16:06 GMT, Serguei Spitsyn wrote: >> @sspitsyn Could you please have a look at this PR ? > > @sercher Okay, will take a look but I'm busy with other things at the moment, so it will take time. Also, I'm also not a Mac OS expert. > @sspitsyn and @sercher I'll take a look since I familiar with the code and the platform... Okay. Thank you, Larry! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3465033182 From sspitsyn at openjdk.org Thu Oct 30 00:06:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 00:06:00 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This looks good to me modulo the comment from Alan. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3396935258 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: reverted back one test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28030/files - new: https://git.openjdk.org/jdk/pull/28030/files/e132e73f..4eec9c78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 06:56:56 GMT, Alan Bateman wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> reverted back one test > > test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > >> 26: * @bug 8284161 8303242 >> 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads >> 28: * @requires test.thread.factory != "Virtual" > > This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? > > (all the rest looks okay, excluded via ProblemList-Virtual in the loom repo) Yes, it is not failing. I thought to exclude it because it is virtual thread specific. But I agree, it is not complaint with overall approach. I am reverting this test change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2476276800 From sspitsyn at openjdk.org Thu Oct 30 04:35:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 04:35:01 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:55:22 GMT, Serguei Spitsyn wrote: >> This is a simple fix to add missing call to `invalidate_jvmti_stack()` to the `freeze_epilog(ContinuationWrapper& cont)`. >> >> Testing: >> - TBD: Run mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unintentionally added new empty line PING: Need one more reviewer, please! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27878#issuecomment-3466094988 From iklam at openjdk.org Thu Oct 30 05:53:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 30 Oct 2025 05:53:16 GMT Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic address Message-ID: **Overview** This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`. This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations. **The fix** (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents. (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with zero-based, zero-shift encoding. Please see comments in the above two functions for more details. ------------- Commit messages: - More clean up - fixed aot map - clean up - 8363986: Heap region in CDS archive is not at deterministic address Changes: https://git.openjdk.org/jdk/pull/28052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363986 Stats: 139 lines in 5 files changed: 104 ins; 17 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28052/head:pull/28052 PR: https://git.openjdk.org/jdk/pull/28052 From dholmes at openjdk.org Thu Oct 30 06:11:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Oct 2025 06:11:04 GMT Subject: RFR: 8365940: Misleading macro in jvm_md.h:57 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 19:27:29 GMT, Matias Saavedra Silva wrote: > The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests. Trivially fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28049#pullrequestreview-3397569921 From dholmes at openjdk.org Thu Oct 30 06:41:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Oct 2025 06:41:04 GMT Subject: RFR: 8369609: Continuations preempt_epilog is missing a call to invalidate_jvmti_stack [v5] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 04:32:41 GMT, Serguei Spitsyn wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unintentionally added new empty line > > PING: Need one more reviewer, please! @sspitsyn the final code changes actually reduce the conditions under which a call to `invalidate_jvmti_stack` is made, which makes the PR description and JBS description rather confusing. Could you rephrase the problem statement so that the proposed solution more obviously addresses it. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27878#issuecomment-3466328253 From alanb at openjdk.org Thu Oct 30 06:54:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Oct 2025 06:54:10 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3397682870 From sspitsyn at openjdk.org Thu Oct 30 06:59:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 06:59:01 GMT Subject: RFR: 8369609: calls from Continuations to invalidate_jvmti_stack must be more accurate [v5] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 06:38:41 GMT, David Holmes wrote: >> PING: Need one more reviewer, please! > > @sspitsyn the final code changes actually reduce the conditions under which a call to `invalidate_jvmti_stack` is made, which makes the PR description and JBS description rather confusing. Could you rephrase the problem statement so that the proposed solution more obviously addresses it. Thanks. @dholmes-ora Thanks. Changed PR description and titles for both PR and CR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27878#issuecomment-3466364754 From dholmes at openjdk.org Thu Oct 30 07:29:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Oct 2025 07:29:03 GMT Subject: RFR: 8369609: calls from Continuations to invalidate_jvmti_stack must be more accurate [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:55:22 GMT, Serguei Spitsyn wrote: >> This is a simple fix is to make calls to `invalidate_jvmti_stack()` from Contunuations code more accurate. We need these calls for pure/plain continuations only which are not executed in a context of virtual threads. >> >> Testing: >> - TBD: Run mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unintentionally added new empty line Thanks. PR description is okay. JBS still a little confusing. :) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27878#pullrequestreview-3397773998 From kbarrett at openjdk.org Thu Oct 30 07:49:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 30 Oct 2025 07:49:18 GMT Subject: RFR: 8365940: Misleading macro in jvm_md.h:57 In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 19:27:29 GMT, Matias Saavedra Silva wrote: > The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests. src/hotspot/os/posix/include/jvm_md.h line 57: > 55: // Linux releases. Here we define JVM_MAXPATHLEN to be MAXPATHLEN + 1, > 56: // so buffers declared in VM are always >= 4096. > 57: #define JVM_MAXPATHLEN (MAXPATHLEN + 1) Per the comment immediately preceeding the definition, JVM_MAXPATHLEN exists to support "JVM and the rest of JDK are built on different Linux releases". We used to have the JVM and the rest of the JDK separable, and could use (somewhat) different versions of them together. But that model was elminated years ago. All uses of JVM_MAXPATHLEN are in HotSpot. (There are also unused *definitions* of that name in jdk.hotspot.agent/share/native/libsaproc/sadis.c.) Looking around, there are many uses of MAXPATHLEN in HotSpot. If we really need JVM_MAXPATHLEN, how sure are we that all of those uses of MAXPATHLEN are okay? So maybe it would be better to just remove JVM_MAXPATHLEN and use MAXPATHLEN everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28049#discussion_r2476725445 From azafari at openjdk.org Thu Oct 30 08:17:56 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 30 Oct 2025 08:17:56 GMT Subject: Integrated: 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 14:14:10 GMT, Afshin Zafari wrote: > Creating core-dump on crash is disabled for the test. This pull request has now been integrated. Changeset: d565c45e Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/d565c45e61bf741cdac5ede252277e4ebc17c104 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/27953 From azafari at openjdk.org Thu Oct 30 08:17:54 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 30 Oct 2025 08:17:54 GMT Subject: RFR: 8370261: Test runtime/NMT/NMTPrintMallocSiteOfCorruptedMemory.java timed out In-Reply-To: <40-Cw8DtHB65aoB5JEPVeU9SLugw_ksjC4GPLPGAD1c=.b5b75c73-1bb5-4ad9-8876-75f76670b734@github.com> References: <40-Cw8DtHB65aoB5JEPVeU9SLugw_ksjC4GPLPGAD1c=.b5b75c73-1bb5-4ad9-8876-75f76670b734@github.com> Message-ID: <_VyLkAMhp8uiKj7bACVjZZFelg1JqsB_RIJLURJGDpA=.e53ba5ee-3b87-4594-863c-d10d97173a2f@github.com> On Thu, 23 Oct 2025 21:41:26 GMT, David Holmes wrote: >> Creating core-dump on crash is disabled for the test. > > LGTM. Thanks Thank you @dholmes-ora and @shipilev for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27953#issuecomment-3466576240 From azafari at openjdk.org Thu Oct 30 09:28:56 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 30 Oct 2025 09:28:56 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v8] In-Reply-To: References: Message-ID: <32KpeIgao1DjFREsAogfAuw4_0k6aaOSp_IwuB-uEVk=.dfd6ba22-4c35-4447-94ca-cd76c5a02276@github.com> > It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. > Specific casts are used to avoid UBSAN error. > > Tests: > linux-x64-debug: tier1 passed Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: suggested change is applied. one error is addressed. one remains still. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26983/files - new: https://git.openjdk.org/jdk/pull/26983/files/5b0dbb9e..efe3d469 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983 PR: https://git.openjdk.org/jdk/pull/26983 From mbaesken at openjdk.org Thu Oct 30 09:32:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 30 Oct 2025 09:32:21 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly Message-ID: When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error : ` java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr` instead we see in the log e.g. : `Java Heap (reserved=67584KB, committed=65536KB)` so it looks like adding asan to the build changes those memory values a bit. We should disable this test when using asan enabled binaries . ------------- Commit messages: - JDK-8364741 Changes: https://git.openjdk.org/jdk/pull/28055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364741 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28055/head:pull/28055 PR: https://git.openjdk.org/jdk/pull/28055 From azafari at openjdk.org Thu Oct 30 11:13:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 30 Oct 2025 11:13:06 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 22:14:59 GMT, Ioi Lam wrote: >> You may already noticed that the root of all these UB complains is the option `-XX:SharedBaseAddress` as zero which is a corner case. > > Sorry, my suggested fix had a typo: > > > address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { > - address requested_addr = _requested_static_archive_bottom + offset; > - address buffered_addr = requested_addr - _buffer_to_requested_delta; > + address buffered_addr = _buffer_bottom + offset; > > > This way this function will not depend on `-XX:SharedBaseAddress` Done and fixed the problem here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2477592763 From kevinw at openjdk.org Thu Oct 30 11:43:29 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 30 Oct 2025 11:43:29 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3399147490 From azafari at openjdk.org Thu Oct 30 12:54:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 30 Oct 2025 12:54:09 GMT Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365 Message-ID: Added a missed header file and fixed copyright year. Tested on macosx-aarch64 ASAN build. ------------- Commit messages: - 8370874: [asan] ASAN build fails after JDK-8368365 Changes: https://git.openjdk.org/jdk/pull/28058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370874 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28058/head:pull/28058 PR: https://git.openjdk.org/jdk/pull/28058 From shade at openjdk.org Thu Oct 30 13:53:36 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Oct 2025 13:53:36 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Wed, 29 Oct 2025 09:36:54 GMT, Severin Gehwolf wrote: >> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also no need to touch the other getter >> - Whitespace > >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. > > Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. @jerboaa -- tell me which way you lean :) I would like to integrate the fix in some form. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3468126453 From sspitsyn at openjdk.org Thu Oct 30 14:22:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 14:22:55 GMT Subject: RFR: 8369609: calls from Continuations to invalidate_jvmti_stack must be more accurate [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:55:22 GMT, Serguei Spitsyn wrote: >> This is a simple fix is to make calls to `invalidate_jvmti_stack()` from Contunuations code more accurate. We need these calls for pure/plain continuations only which are not executed in a context of virtual threads. >> >> Testing: >> - TBD: Run mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unintentionally added new empty line Thank you for review, David! I've updated the JBS description too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27878#issuecomment-3468267928 From sspitsyn at openjdk.org Thu Oct 30 14:27:24 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 14:27:24 GMT Subject: Integrated: 8369609: calls from Continuations to invalidate_jvmti_stack must be more accurate In-Reply-To: References: Message-ID: <8VLEa1z-Wp53xHlOURATwu69Ui8HZJb8dmmGIH2gxoE=.00ab26d1-e2dd-4fcb-b312-ae76e9215372@github.com> On Fri, 17 Oct 2025 20:05:24 GMT, Serguei Spitsyn wrote: > This is a simple fix is to make calls to `invalidate_jvmti_stack()` from Contunuations code more accurate. We need these calls for pure/plain continuations only which are not executed in a context of virtual threads. > > Testing: > - TBD: Run mach5 tiers 1-6 This pull request has now been integrated. Changeset: a33aa65f Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/a33aa65fbc70a91fe21e9016c393bb5a764cd75a Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod 8369609: calls from Continuations to invalidate_jvmti_stack must be more accurate Reviewed-by: pchilanomate, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27878 From lmesnik at openjdk.org Thu Oct 30 15:38:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 15:38:19 GMT Subject: Integrated: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This pull request has now been integrated. Changeset: ed36b9bb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ed36b9bb6f3d429db6accfb3b096e50e7f2217ff Stats: 29 lines in 13 files changed: 15 ins; 1 del; 13 mod 8370851: Mark hotspot and jdk tests incompatible with test thread factory Reviewed-by: alanb, kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28030 From matsaave at openjdk.org Thu Oct 30 16:05:00 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 30 Oct 2025 16:05:00 GMT Subject: RFR: 8365940: Misleading macro in jvm_md.h:57 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 07:46:45 GMT, Kim Barrett wrote: >> The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests. > > src/hotspot/os/posix/include/jvm_md.h line 57: > >> 55: // Linux releases. Here we define JVM_MAXPATHLEN to be MAXPATHLEN + 1, >> 56: // so buffers declared in VM are always >= 4096. >> 57: #define JVM_MAXPATHLEN (MAXPATHLEN + 1) > > Per the comment immediately preceeding the definition, JVM_MAXPATHLEN exists > to support "JVM and the rest of JDK are built on different Linux releases". We > used to have the JVM and the rest of the JDK separable, and could use > (somewhat) different versions of them together. But that model was elminated > years ago. > > All uses of JVM_MAXPATHLEN are in HotSpot. (There are also > unused *definitions* of that name in > jdk.hotspot.agent/share/native/libsaproc/sadis.c.) > > Looking around, there are many uses of MAXPATHLEN in HotSpot. If we really > need JVM_MAXPATHLEN, how sure are we that all of those uses of MAXPATHLEN are > okay? > > So maybe it would be better to just remove JVM_MAXPATHLEN and use MAXPATHLEN > everywhere. Thanks for finding that, I was also unsure whether or not the comment above was still valid today. I agree that if JVM_MAXPATHLEN is actually unneeded it can be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28049#discussion_r2478673652 From sgehwolf at openjdk.org Thu Oct 30 16:43:48 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Oct 2025 16:43:48 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Wed, 29 Oct 2025 09:36:54 GMT, Severin Gehwolf wrote: >> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also no need to touch the other getter >> - Whitespace > >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. > > Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > @jerboaa -- tell me which way you lean :) I would like to integrate the fix in some form. Ideally the test should be included. But OK to include as a follow-up RFE. I regularly run tests as root. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3468970782 From sgehwolf at openjdk.org Thu Oct 30 16:49:34 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Oct 2025 16:49:34 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace OK. But we need the regression test as that code changes again with https://bugs.openjdk.org/browse/JDK-8365606 and testing all those corner cases manually isn't going to scale. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28006#pullrequestreview-3400641173 From kdnilsen at openjdk.org Thu Oct 30 17:40:10 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 30 Oct 2025 17:40:10 GMT Subject: RFR: 8370646: TestLargeUTF8Length.java needs lots of memory Message-ID: Do not run this test unless the test environment has at least 15 GB of RAM. ------------- Commit messages: - Add @requires maxMemory to TestLargeUTF8Length.java Changes: https://git.openjdk.org/jdk/pull/28069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370646 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28069/head:pull/28069 PR: https://git.openjdk.org/jdk/pull/28069 From simonis at openjdk.org Thu Oct 30 17:59:42 2025 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 30 Oct 2025 17:59:42 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Thu, 30 Oct 2025 16:40:32 GMT, Severin Gehwolf wrote: >>> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Without a proper regression test this is bound to fall through the cracks again. So are you sure this cannot be tested? It should be fine if the test needs root privileges (we could skip it if not root). But it would be better than not having one. > >> @jerboaa -- tell me which way you lean :) I would like to integrate the fix in some form. > > Ideally the test should be included. But OK to include as a follow-up RFE. I regularly run tests as root. Thanks @jerboaa. I've created https://bugs.openjdk.org/browse/JDK-8370966 for the regression test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3469339573 From shade at openjdk.org Thu Oct 30 19:13:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Oct 2025 19:13:10 GMT Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 [v2] In-Reply-To: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> References: <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com> Message-ID: On Mon, 27 Oct 2025 17:59:23 GMT, Aleksey Shipilev wrote: >> See the bug for more discussion. >> >> We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). >> >> But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. >> >> Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. >> >> We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. >> >> I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. >> >> Additional testing: >> - [x] Reproducer with local Docker now passes >> - [x] Reproducer with ECS Fargate now passes >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host >> - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Also no need to touch the other getter > - Whitespace Thank you both! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3469659631 From shade at openjdk.org Thu Oct 30 19:13:11 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Oct 2025 19:13:11 GMT Subject: Integrated: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 17:40:45 GMT, Aleksey Shipilev wrote: > See the bug for more discussion. > > We are seeing customer regressions in 21.0.9, notably on ECS Fargate. We root-caused it to [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420). That patch removed the handling of `hierarchical_memory_limit`, look at [this hunk](https://github.com/openjdk/jdk/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9L118-L131). > > But at least cgroupv1 still needs them in some conditions, notably in ECS. There is a way to reproduce it with local Docker as well. The key is to set up host cgroup that would not be visible to the container, and so that the only way for container to know the memory limits would be to look into `hierarchical_*` values that kernel computes itself. > > Unfortunately, it is not easy to revert the offending hunks from 21.0.9, as there were follow-up refactoring backports. So, to make it work, this PR reinstantiates the hunks using the new cgroups support code. It also makes code (subjectively) easier to read, and is in the spirit of past refactorings. > > We are planning to pick this patch up to 21.0.9, at least into Corretto downstream as soon as possible to unbreak users. Therefore, the patch is also kept as crisp as possible. > > I tried to come up with a regression test for it, but could not: local reproducers require amending _host_ configuration, which requires superuser privileges, among other hassle it introduces. > > Additional testing: > - [x] Reproducer with local Docker now passes > - [x] Reproducer with ECS Fargate now passes > - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv1 host > - [x] Linux x86_64 server fastdebug, `containers/` passes on cgroupsv2 host This pull request has now been integrated. Changeset: c49a94bf Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c49a94bf89876c4d6c777a9452618afa564c5c23 Stats: 33 lines in 3 files changed: 22 ins; 3 del; 8 mod 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420 Reviewed-by: simonis, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/28006 From matsaave at openjdk.org Thu Oct 30 19:42:33 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 30 Oct 2025 19:42:33 GMT Subject: RFR: 8365940: Misleading macro in jvm_md.h:57 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 16:01:57 GMT, Matias Saavedra Silva wrote: >> src/hotspot/os/posix/include/jvm_md.h line 57: >> >>> 55: // Linux releases. Here we define JVM_MAXPATHLEN to be MAXPATHLEN + 1, >>> 56: // so buffers declared in VM are always >= 4096. >>> 57: #define JVM_MAXPATHLEN (MAXPATHLEN + 1) >> >> Per the comment immediately preceeding the definition, JVM_MAXPATHLEN exists >> to support "JVM and the rest of JDK are built on different Linux releases". We >> used to have the JVM and the rest of the JDK separable, and could use >> (somewhat) different versions of them together. But that model was elminated >> years ago. >> >> All uses of JVM_MAXPATHLEN are in HotSpot. (There are also >> unused *definitions* of that name in >> jdk.hotspot.agent/share/native/libsaproc/sadis.c.) >> >> Looking around, there are many uses of MAXPATHLEN in HotSpot. If we really >> need JVM_MAXPATHLEN, how sure are we that all of those uses of MAXPATHLEN are >> okay? >> >> So maybe it would be better to just remove JVM_MAXPATHLEN and use MAXPATHLEN >> everywhere. > > Thanks for finding that, I was also unsure whether or not the comment above was still valid today. I agree that if JVM_MAXPATHLEN is actually unneeded it can be removed. After further inspection, MAXPATHLEN seems to only be used within the hotspot/os directory and other areas in Hotspot rely on JVM_MAXPATHLEN. Tampering with this could cause some issues since the value of JVM_MAXPATHLEN varies between platforms and does not necessarily rely on MAXPATHLEN. The simple fix in this PR is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28049#discussion_r2479305235 From iklam at openjdk.org Thu Oct 30 23:00:37 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 30 Oct 2025 23:00:37 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 Message-ID: In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: if (forceBase >= end) { throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); } ------------- Commit messages: - Removed sanity test - Fix with sanity test Changes: https://git.openjdk.org/jdk/pull/28077/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28077&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370975 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28077/head:pull/28077 PR: https://git.openjdk.org/jdk/pull/28077 From phh at openjdk.org Thu Oct 30 23:54:02 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 30 Oct 2025 23:54:02 GMT Subject: RFR: 8370646: TestLargeUTF8Length.java needs lots of memory In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 17:33:47 GMT, Kelvin Nilsen wrote: > Do not run this test unless the test environment has at least 15 GB of RAM. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28069#pullrequestreview-3402106282 From wkemper at openjdk.org Fri Oct 31 00:01:12 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 31 Oct 2025 00:01:12 GMT Subject: RFR: 8370646: TestLargeUTF8Length.java needs lots of memory In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 17:33:47 GMT, Kelvin Nilsen wrote: > Do not run this test unless the test environment has at least 15 GB of RAM. Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28069#pullrequestreview-3402114370 From ysr at openjdk.org Fri Oct 31 00:06:02 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Fri, 31 Oct 2025 00:06:02 GMT Subject: RFR: 8370646: TestLargeUTF8Length.java needs lots of memory In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 17:33:47 GMT, Kelvin Nilsen wrote: > Do not run this test unless the test environment has at least 15 GB of RAM. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28069#pullrequestreview-3402120192 From kdnilsen at openjdk.org Fri Oct 31 00:09:12 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 31 Oct 2025 00:09:12 GMT Subject: Integrated: 8370646: TestLargeUTF8Length.java needs lots of memory In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 17:33:47 GMT, Kelvin Nilsen wrote: > Do not run this test unless the test environment has at least 15 GB of RAM. This pull request has now been integrated. Changeset: 3c1010b5 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/3c1010b57f2f8258a2ccf59b9f86fc8debd71918 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8370646: TestLargeUTF8Length.java needs lots of memory Reviewed-by: phh, wkemper, ysr ------------- PR: https://git.openjdk.org/jdk/pull/28069 From iklam at openjdk.org Fri Oct 31 01:22:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 31 Oct 2025 01:22:06 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v8] In-Reply-To: <32KpeIgao1DjFREsAogfAuw4_0k6aaOSp_IwuB-uEVk=.dfd6ba22-4c35-4447-94ca-cd76c5a02276@github.com> References: <32KpeIgao1DjFREsAogfAuw4_0k6aaOSp_IwuB-uEVk=.dfd6ba22-4c35-4447-94ca-cd76c5a02276@github.com> Message-ID: On Thu, 30 Oct 2025 09:28:56 GMT, Afshin Zafari wrote: >> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. >> Specific casts are used to avoid UBSAN error. >> >> Tests: >> linux-x64-debug: tier1 passed > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > suggested change is applied. one error is addressed. one remains still. src/hotspot/share/cds/archiveBuilder.cpp line 1035: > 1033: > 1034: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { > 1035: // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic. This comment is no longer needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2479910240 From iklam at openjdk.org Fri Oct 31 01:34:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 31 Oct 2025 01:34:03 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: <5ZUsKd_RPtNYuy28mXxQqvdN9mGLP_5Xlp_U9TZRhQY=.0ffd3d80-b38b-4137-81b8-dab0eef9e8d9@github.com> References: <5ZUsKd_RPtNYuy28mXxQqvdN9mGLP_5Xlp_U9TZRhQY=.0ffd3d80-b38b-4137-81b8-dab0eef9e8d9@github.com> Message-ID: On Wed, 22 Oct 2025 22:16:23 GMT, Ioi Lam wrote: >> For this line, the UB is non-null ptr + non-zero offset becomes 0, as this output shows: >> >> ----------System.err:(32/2579)---------- >> TEST FAILED: Error processing option SharedBaseAddress with valid value '-server -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=TestOptionsWithRanges.jsa -Xshare:dump -XX:SharedBaseAddress=0'! JVM exited with unexpected error code = 134 [0x86] >> stdout content[] >> stderr content[/Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43: runtime error: applying non-zero offset to non-null pointer 0x0003c0000000 produced null pointer >> #0 0x1076111f8 in RelocateBufferToRequested::RelocateBufferToRequested(ArchiveBuilder*) archiveBuilder.cpp:1104 >> #1 0x10760c67c in ArchiveBuilder::relocate_to_requested() archiveBuilder.cpp:1170 >> #2 0x1075ec2a0 in AOTMetaspace::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) aotMetaspace.cpp:1084 >> #3 0x1075eb120 in AOTMetaspace::dump_static_archive_impl(StaticArchiveBuilder&, JavaThread*) aotMetaspace.cpp:1067 >> #4 0x1075ea4cc in AOTMetaspace::dump_static_archive(JavaThread*) aotMetaspace.cpp:850 >> #5 0x108eb1820 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:903 >> #6 0x10847d40c in JNI_CreateJavaVM jni.cpp:3678 >> #7 0x102403a00 in JavaMain java.c:494 >> #8 0x10240a400 in ThreadJavaMain java_md_macosx.m:679 >> #9 0x19387fbc4 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6bc4) >> #10 0x19387ab7c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1b7c) >> >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/afshin/scratch/8366062_ubsan_nullptr_plus_nz_offset/src/hotspot/share/cds/archiveBuilder.cpp:1104:43 in >> ] > > I see. Now I understand what's going on here. When the asan failure happens, the value of `_buffer_to_requested_delta` is `0 - (intptr_t)bottom` address new_bottom = bottom + _buffer_to_requested_delta; So I think it's OK to change the above line to address new_bottom = (address)((intx)bottom + _buffer_to_requested_delta); Your other changes use `uintptr_t`, but here `_buffer_to_requested_delta` can be positive or negative. It has the `intx` type, so we should do the `(intx)` type cast. The next line doesn't need to be changed, as neither `top` nor `new_top` will be zeros. address new_top = top + _buffer_to_requested_delta; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2479924433 From haosun at openjdk.org Fri Oct 31 01:42:01 2025 From: haosun at openjdk.org (Hao Sun) Date: Fri, 31 Oct 2025 01:42:01 GMT Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari wrote: > Added a missed header file and fixed copyright year. > Tested on macosx-aarch64 ASAN build. src/hotspot/share/sanitizers/address.cpp line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Please keep it as it is. `XX, YY` means that this file was created at `XX` year and lastly updated at `YY` year. If `XX == YY` then use `XX`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28058#discussion_r2479927268 From haosun at openjdk.org Fri Oct 31 03:57:03 2025 From: haosun at openjdk.org (Hao Sun) Date: Fri, 31 Oct 2025 03:57:03 GMT Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari wrote: > Added a missed header file and fixed copyright year. > Tested on macosx-aarch64 ASAN build. LGTM except the copyright year change. Note that we encountered this build failure in our internal CI as well. It failed on both x86_64 and AArch64. With this patch, the build can pass on both x86_64 and AArch64 now. ------------- Marked as reviewed by haosun (Committer). PR Review: https://git.openjdk.org/jdk/pull/28058#pullrequestreview-3402505581 From stefank at openjdk.org Fri Oct 31 07:21:01 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 31 Oct 2025 07:21:01 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam wrote: > In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. > > I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. > > I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: > > > if (forceBase >= end) { > throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); > } I'm skeptical to adding MULTILINE to all users of these regex functions. And with that said, something is fishy here. Why do you need to match over multiple lines? I see that the bug report makes it look like you have multiple lines, but the linked output from the test doesn't have them. Could you give a more comprehensive explanation what this solves? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471601865 From dholmes at openjdk.org Fri Oct 31 07:36:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 31 Oct 2025 07:36:02 GMT Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari wrote: > Added a missed header file and fixed copyright year. > Tested on macosx-aarch64 ASAN build. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28058#pullrequestreview-3402884237 From stefank at openjdk.org Fri Oct 31 07:36:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 31 Oct 2025 07:36:05 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam wrote: > In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. > > I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. > > I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: > > > if (forceBase >= end) { > throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); > } I now see that this is the way the OutputAnalyzer deals with all the other regex functions, so ignore my skepticism. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471636863 From dholmes at openjdk.org Fri Oct 31 07:36:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 31 Oct 2025 07:36:04 GMT Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365 In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 01:34:20 GMT, Hao Sun wrote: >> Added a missed header file and fixed copyright year. >> Tested on macosx-aarch64 ASAN build. > > src/hotspot/share/sanitizers/address.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > Please keep it as it is. > > `XX, YY` means that this file was created at `XX` year and lastly updated at `YY` year. If `XX == YY` then use `XX`. This file was added by https://github.com/openjdk/jdk/pull/27446 with this copyright notice, but there is no indication that any of the content was copied from elsewhere from a file with the 1998 copyright notice, in which case it should not be present. Maybe @tstuefe will notice this and comment on that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28058#discussion_r2480388184 From stefank at openjdk.org Fri Oct 31 07:47:13 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 31 Oct 2025 07:47:13 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 In-Reply-To: References: Message-ID: <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com> On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam wrote: > In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. > > I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. > > I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: > > > if (forceBase >= end) { > throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); > } Changes requested by stefank (Reviewer). test/lib/jdk/test/lib/process/OutputAnalyzer.java line 359: > 357: private boolean matchesHelper(String s, Pattern pattern) { > 358: return s != null && pattern.matcher(s).find(); > 359: } This function is named `matchesX` so why is it using `Matcher::find` instead of `Matcher::matches`? That seems confusing. test/lib/jdk/test/lib/process/OutputAnalyzer.java line 364: > 362: Pattern pattern = Pattern.compile(regexp, Pattern.MULTILINE); > 363: return matchesHelper(stdout, pattern) || matchesHelper(stderr, pattern); > 364: } I'd like to suggest that you don't hard-code `stdout` and `stderr` here and use something like this (with updated name as suggested above): Suggestion: private boolean findIn(String regexp, String... strings) { Pattern pattern = Pattern.compile(regexp, Pattern.MULTILINE); for (String string : strings) { if (pattern.matcher(string).find()) { return true; } } return false; } and then the code you have that looks like this: return matchesHelper(getStdout(), null, regexp); can get rid of the `null`: return findIn(regexp, getStdout()); ------------- PR Review: https://git.openjdk.org/jdk/pull/28077#pullrequestreview-3402888668 PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480391654 PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480406005 From stefank at openjdk.org Fri Oct 31 07:47:14 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 31 Oct 2025 07:47:14 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 In-Reply-To: <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com> References: <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com> Message-ID: On Fri, 31 Oct 2025 07:35:18 GMT, Stefan Karlsson wrote: >> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. >> >> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. >> >> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: >> >> >> if (forceBase >= end) { >> throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); >> } > > test/lib/jdk/test/lib/process/OutputAnalyzer.java line 359: > >> 357: private boolean matchesHelper(String s, Pattern pattern) { >> 358: return s != null && pattern.matcher(s).find(); >> 359: } > > This function is named `matchesX` so why is it using `Matcher::find` instead of `Matcher::matches`? That seems confusing. If it truly is `find` you need, then I think you need to fix the names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480398463 From stefank at openjdk.org Fri Oct 31 08:41:28 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 31 Oct 2025 08:41:28 GMT Subject: RFR: 8370975: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail on macos 26 In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam wrote: > In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines. > > I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`. > > I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case: > > > if (forceBase >= end) { > throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test."); > } I took a closer look at this and I think the crucial part is that we are using `find` and not the change to use `MULTILINE`. `MULTILINE` seems to only be needed if you want to use `^` and `$` in your regex. I added some temporary test to OutputAnalyzerTest to show this: public static boolean findIn(String regex, String... strings) { Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE); for (String string : strings) { if (pattern.matcher(string).find()) { return true; } } return false; } private static void testFindIn() { String stdout = "some stdout"; String stderr = "A little dog\nThe small cat\nA small horse"; check(findIn("little", stdout, stderr)); // Does not work with matches() `.` doesn't matche newlines check(findIn(".*A little dog.*", stdout, stderr)); check(findIn("A.*", stdout, stderr)); check(findIn("T.*", stdout, stderr)); check(findIn(".*cat", stdout, stderr)); check(findIn(".*horse", stdout, stderr)); check(!findIn("frog", stdout, stderr)); // Does not require multi-line check(findIn("dog\nThe", stdout, stderr)); // Requires MULTILINE check(findIn("^The small cat", stdout, stderr)); check(findIn("The small cat$", stdout, stderr)); check(findIn("^The small cat$", stdout, stderr)); } private static void check(boolean b) { if (!b) { throw new RuntimeException("Check failed"); } } Now play around with changing the `find` to `matches` and/or removing `MULTILINE`. So, I would prefer to see the following: 1) Fix the title to indicate that your updating the OutputAnalyzer 2) Fix the summary that states that MULTILINE is needed to match over newlines 3) Introduce the new "find" function (or rename matches) 4) Add tests 5) Preferably, use one RFE for the above enhancements and Bug for the test failure ------------- PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471893950 From phubner at openjdk.org Fri Oct 31 09:32:02 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 31 Oct 2025 09:32:02 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 09:24:16 GMT, Matthias Baesken wrote: > When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error : > ` > java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr` > > instead we see in the log e.g. : > `Java Heap (reserved=67584KB, committed=65536KB)` > > so it looks like adding asan to the build changes those memory values a bit. > We should disable this test when using asan enabled binaries . test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32: > 30: * @modules java.base/jdk.internal.misc > 31: * @requires vm.flagless > 32: * @requires !vm.asan Instead of disabling the test entirely, could we check for `Java Heap` or (`Java Heap` and `committed=65536KB`)? I'm not too fussed either way, but this seems like a useful sanity test to have so maybe we could just refactor it a bit. @afshin-zafari does asan ever impact the `committed` memory in NMT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2480706632 From azafari at openjdk.org Fri Oct 31 11:27:38 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 31 Oct 2025 11:27:38 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v9] In-Reply-To: References: Message-ID: > It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. > Specific casts are used to avoid UBSAN error. > > Tests: > linux-x64-debug: tier1 passed Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: reviews applied. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26983/files - new: https://git.openjdk.org/jdk/pull/26983/files/efe3d469..99c23e5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983 PR: https://git.openjdk.org/jdk/pull/26983 From azafari at openjdk.org Fri Oct 31 11:31:03 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 31 Oct 2025 11:31:03 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v8] In-Reply-To: References: <32KpeIgao1DjFREsAogfAuw4_0k6aaOSp_IwuB-uEVk=.dfd6ba22-4c35-4447-94ca-cd76c5a02276@github.com> Message-ID: On Fri, 31 Oct 2025 01:19:24 GMT, Ioi Lam wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> suggested change is applied. one error is addressed. one remains still. > > src/hotspot/share/cds/archiveBuilder.cpp line 1035: > >> 1033: >> 1034: address ArchiveBuilder::offset_to_buffered_address(u4 offset) const { >> 1035: // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic. > > This comment is no longer needed. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2481113722 From azafari at openjdk.org Fri Oct 31 11:31:05 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 31 Oct 2025 11:31:05 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v6] In-Reply-To: References: <5ZUsKd_RPtNYuy28mXxQqvdN9mGLP_5Xlp_U9TZRhQY=.0ffd3d80-b38b-4137-81b8-dab0eef9e8d9@github.com> Message-ID: On Fri, 31 Oct 2025 01:31:42 GMT, Ioi Lam wrote: >> I see. > > Now I understand what's going on here. When the asan failure happens, the value of `_buffer_to_requested_delta` is `0 - (intptr_t)bottom` > > > address new_bottom = bottom + _buffer_to_requested_delta; > > > So I think it's OK to change the above line to > > > address new_bottom = (address)((intx)bottom + _buffer_to_requested_delta); > > > Your other changes use `uintptr_t`, but here `_buffer_to_requested_delta` can be positive or negative. It has the `intx` type, so we should do the `(intx)` type cast. > > The next line doesn't need to be changed, as neither `top` nor `new_top` will be zeros. > > > address new_top = top + _buffer_to_requested_delta; Thanks for your suggestions. They work fine. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2481112668 From azafari at openjdk.org Fri Oct 31 12:59:03 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 31 Oct 2025 12:59:03 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 09:28:58 GMT, Paul H?bner wrote: >> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error : >> ` >> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr` >> >> instead we see in the log e.g. : >> `Java Heap (reserved=67584KB, committed=65536KB)` >> >> so it looks like adding asan to the build changes those memory values a bit. >> We should disable this test when using asan enabled binaries . > > test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32: > >> 30: * @modules java.base/jdk.internal.misc >> 31: * @requires vm.flagless >> 32: * @requires !vm.asan > > Instead of disabling the test entirely, could we check for `Java Heap` or (`Java Heap` and `committed=65536KB`)? I'm not too fussed either way, but this seems like a useful sanity test to have so maybe we could just refactor it a bit. @afshin-zafari does asan ever impact the `committed` memory in NMT? The unexpected value is for `reserved` and not `committed`. But any way, ASAN should/could not impact internal NMT memory regions, at least directly. The question here is why there is extra 2048K bytes in reserved memory, comparing with non-asan build? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2481326324 From mbaesken at openjdk.org Fri Oct 31 13:10:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 31 Oct 2025 13:10:04 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 12:55:15 GMT, Afshin Zafari wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32: >> >>> 30: * @modules java.base/jdk.internal.misc >>> 31: * @requires vm.flagless >>> 32: * @requires !vm.asan >> >> Instead of disabling the test entirely, could we check for `Java Heap` or (`Java Heap` and `committed=65536KB`)? I'm not too fussed either way, but this seems like a useful sanity test to have so maybe we could just refactor it a bit. @afshin-zafari does asan ever impact the `committed` memory in NMT? > > The unexpected value is for `reserved` and not `committed`. But any way, ASAN should/could not impact internal NMT memory regions, at least directly. > The question here is why there is extra 2048K bytes in reserved memory, comparing with non-asan build? It is a little bit surprising indeed. We set `"-Xmx64M", "-Xms64M",` in the test, so a higher reserved value is a bit strange but still we get it this way (on Linux x86_64) - Java Heap (reserved=67584KB, committed=65536KB) (mmap: reserved=67584KB, committed=65536KB, at peak) @tstuefe do you maybe have an idea / explanation why with ASAN-enabled binaries we get a higher value for 'reserved'? The test expects `output_detail.shouldContain("Java Heap (reserved=65536KB, committed=65536KB)");` (and from what I see we get this otherwise when testing on our large set of OS/CPU platforms) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2481355578 From jsikstro at openjdk.org Fri Oct 31 15:03:09 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 31 Oct 2025 15:03:09 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly In-Reply-To: References: Message-ID: <5Ijk8bQ8nehFkJdrjRH0-nmv7QB5OZKZCLD--AEpFZo=.cb96b397-62cc-4c27-95b4-421385a8ae9b@github.com> On Fri, 31 Oct 2025 13:07:28 GMT, Matthias Baesken wrote: >> The unexpected value is for `reserved` and not `committed`. But any way, ASAN should/could not impact internal NMT memory regions, at least directly. >> The question here is why there is extra 2048K bytes in reserved memory, comparing with non-asan build? > > It is a little bit surprising indeed. > We set > `"-Xmx64M", "-Xms64M",` > in the test, so a higher reserved value is a bit strange but still we get it this way (on Linux x86_64) > > - Java Heap (reserved=67584KB, committed=65536KB) > (mmap: reserved=67584KB, committed=65536KB, at peak) > > > @tstuefe do you maybe have an idea / explanation why with ASAN-enabled binaries we get a higher value for 'reserved'? > The test expects > `output_detail.shouldContain("Java Heap (reserved=65536KB, committed=65536KB)");` > (and from what I see we get this otherwise when testing on our large set of OS/CPU platforms) I'm just spitballing here based on my experience listening to @xmas92 talk about ASAN in ZGC. Could it be that ASAN is reserving memory at the lower end of the virtual address space, making it difficult to get zero-based Compressed Oops. In that case, we need som extra memory to "efficiently implement null checks.", which turns out to be 2M in this case, which looks like an extra large page. https://github.com/openjdk/jdk/blob/8236800deb5b99a027b0944f6c512c0f31d030df/src/hotspot/share/memory/memoryReserver.cpp#L612-L614 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2481708629 From duke at openjdk.org Fri Oct 31 15:55:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 31 Oct 2025 15:55:47 GMT Subject: RFR: 8366272: The os::xxx APIs do not manage errno correctly Message-ID: Hi, please consider the following changes: In this PR the handling of `errno` is improved by inspection of the codebase and fixing potential overwrites of `errno` by other methods. Potential overwrites are addressed using `ErrnoPreserver` functionality where necessary. Tested in tiers 1 - 5. ------------- Commit messages: - 8366272: Improved errno management in os:xxx methods Changes: https://git.openjdk.org/jdk/pull/28086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366272 Stats: 18 lines in 6 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28086/head:pull/28086 PR: https://git.openjdk.org/jdk/pull/28086 From iklam at openjdk.org Fri Oct 31 17:19:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 31 Oct 2025 17:19:07 GMT Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp [v9] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 11:27:38 GMT, Afshin Zafari wrote: >> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB. >> Specific casts are used to avoid UBSAN error. >> >> Tests: >> linux-x64-debug: tier1 passed > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > reviews applied. LGTM Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3405299963 PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3405300261 From coleenp at openjdk.org Fri Oct 31 18:13:08 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Oct 2025 18:13:08 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v5] In-Reply-To: <7KCTM19LDq03i-J6lxi50UkqvGD8Tb_k49IA3S4tXU8=.5b4e889c-5e3d-4fd2-87e6-9912ef94bf75@github.com> References: <5R5VmBHN-Imel1ijzXqZFGgmp20anXh4Q3C2V_MUNZ0=.1893458f-7d03-4150-94dc-cef7fbe54f3a@github.com> <7mADCmeLtJyhzXIYSPRPjcSwGDJROqDgwm4Awq_Vl84=.cb9b5193-dd60-49ce-841a-9f3bad48010d@github.com> <7KCTM19LDq03i-J6lxi50UkqvGD8Tb_k49IA3S4tXU8=.5b4e889c-5e3d-4fd2-87e6-9912ef94bf75@github.com> Message-ID: On Tue, 28 Oct 2025 13:06:50 GMT, Coleen Phillimore wrote: >> ClassWriter.newUTF8() returns the index in the constant pool so you can use that information >> >> >> int maxCPIndex = cw.newUTF8(Integer.toString(-1)); >> int maxEntry = 65535 - maxCPIndex - 1; > > I think I figured it out. It's sort of um interesting. Oh thank you! that's very helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2482296425 From coleenp at openjdk.org Fri Oct 31 18:21:21 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Oct 2025 18:21:21 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v6] In-Reply-To: References: Message-ID: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Simplify the test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/e45c594f..c1ad4e3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=04-05 Stats: 15 lines in 1 file changed: 1 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From azafari at openjdk.org Fri Oct 31 18:49:03 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 31 Oct 2025 18:49:03 GMT Subject: RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly In-Reply-To: <5Ijk8bQ8nehFkJdrjRH0-nmv7QB5OZKZCLD--AEpFZo=.cb96b397-62cc-4c27-95b4-421385a8ae9b@github.com> References: <5Ijk8bQ8nehFkJdrjRH0-nmv7QB5OZKZCLD--AEpFZo=.cb96b397-62cc-4c27-95b4-421385a8ae9b@github.com> Message-ID: On Fri, 31 Oct 2025 14:58:11 GMT, Joel Sikstr?m wrote: >> It is a little bit surprising indeed. >> We set >> `"-Xmx64M", "-Xms64M",` >> in the test, so a higher reserved value is a bit strange but still we get it this way (on Linux x86_64) >> >> - Java Heap (reserved=67584KB, committed=65536KB) >> (mmap: reserved=67584KB, committed=65536KB, at peak) >> >> >> @tstuefe do you maybe have an idea / explanation why with ASAN-enabled binaries we get a higher value for 'reserved'? >> The test expects >> `output_detail.shouldContain("Java Heap (reserved=65536KB, committed=65536KB)");` >> (and from what I see we get this otherwise when testing on our large set of OS/CPU platforms) > > I'm just spitballing here based on my experience listening to @xmas92 talk about ASAN in ZGC. Could it be that ASAN is reserving memory at the lower end of the virtual address space, making it difficult to get zero-based Compressed Oops. In that case, we need som extra memory to "efficiently implement null checks.", which turns out to be 2M in this case, which looks like an extra large page. > https://github.com/openjdk/jdk/blob/8236800deb5b99a027b0944f6c512c0f31d030df/src/hotspot/share/memory/memoryReserver.cpp#L612-L614 Thanks for sharing your info. It describes the 2M diff in reserved amount. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2482387794 From matsaave at openjdk.org Fri Oct 31 18:58:05 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 31 Oct 2025 18:58:05 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v6] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 18:21:21 GMT, Coleen Phillimore wrote: >> Check for constant pool index overflow and throw ClassFormatError instead of crashing. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Simplify the test. src/hotspot/share/classfile/classFileParser.cpp line 5529: > 5527: // Check for overflow. cp_size is a u2. > 5528: assert(sizeof(cp_size) == sizeof(u2), "this overflow test depends on this"); > 5529: guarantee_property(cp_size > _orig_cp_size, "Overflow in constant pool size for hidden class %s", CHECK); Isn't this technically UB behavior? It isn't guaranteed that a u2 will overflow to a low value. It might be safer have cp_size be an int and then guarantee that cp_size < 65535. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2482403035 From coleenp at openjdk.org Fri Oct 31 19:15:26 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Oct 2025 19:15:26 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v6] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 18:53:38 GMT, Matias Saavedra Silva wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify the test. > > src/hotspot/share/classfile/classFileParser.cpp line 5529: > >> 5527: // Check for overflow. cp_size is a u2. >> 5528: assert(sizeof(cp_size) == sizeof(u2), "this overflow test depends on this"); >> 5529: guarantee_property(cp_size > _orig_cp_size, "Overflow in constant pool size for hidden class %s", CHECK); > > Isn't this technically UB behavior? It isn't guaranteed that a u2 will overflow to a low value. It might be safer have cp_size be an int and then guarantee that cp_size < 65535. Doing a cast to u4 and an overflow check might be the best thing. Then I won't need the assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2482441449 From coleenp at openjdk.org Fri Oct 31 19:24:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Oct 2025 19:24:23 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v7] In-Reply-To: References: Message-ID: > Check for constant pool index overflow and throw ClassFormatError instead of crashing. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add an explicit overflow test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27964/files - new: https://git.openjdk.org/jdk/pull/27964/files/c1ad4e3e..ae7f90ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27964&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27964/head:pull/27964 PR: https://git.openjdk.org/jdk/pull/27964 From coleenp at openjdk.org Fri Oct 31 19:33:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Oct 2025 19:33:04 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v6] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 19:12:50 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5529: >> >>> 5527: // Check for overflow. cp_size is a u2. >>> 5528: assert(sizeof(cp_size) == sizeof(u2), "this overflow test depends on this"); >>> 5529: guarantee_property(cp_size > _orig_cp_size, "Overflow in constant pool size for hidden class %s", CHECK); >> >> Isn't this technically UB behavior? It isn't guaranteed that a u2 will overflow to a low value. It might be safer have cp_size be an int and then guarantee that cp_size < 65535. > > Doing a cast to u4 and an overflow check might be the best thing. Then I won't need the assert. I made this change and reran the VM jck tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2482474917 From matsaave at openjdk.org Fri Oct 31 19:46:03 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 31 Oct 2025 19:46:03 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v7] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 19:24:23 GMT, Coleen Phillimore wrote: >> Check for constant pool index overflow and throw ClassFormatError instead of crashing. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add an explicit overflow test. Looks good! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27964#pullrequestreview-3405895065 From kbarrett at openjdk.org Fri Oct 31 20:27:02 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 31 Oct 2025 20:27:02 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v6] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 19:30:06 GMT, Coleen Phillimore wrote: >> Doing a cast to u4 and an overflow check might be the best thing. Then I won't need the assert. > > I made this change and reran the VM jck tests. > Isn't this technically UB behavior? It isn't guaranteed that a u2 will overflow to a low value. It might be safer have cp_size be an int and then guarantee that cp_size < 65535. [drive-by comment] Unsigned integer arithmetic is modular arithmetic. Overflow is not UB, it's wrap-around. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2482579619 From liach at openjdk.org Fri Oct 31 22:59:03 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 31 Oct 2025 22:59:03 GMT Subject: RFR: 8364360: Defining hidden class with no room in constant pool crashes the VM [v7] In-Reply-To: References: Message-ID: <6u5ZlirxmwTcECZyc86WNYQNYnBSuAvKasAHP_98fXw=.391e1500-1ccd-46cb-8b23-46d9391d651e@github.com> On Fri, 31 Oct 2025 19:24:23 GMT, Coleen Phillimore wrote: >> Check for constant pool index overflow and throw ClassFormatError instead of crashing. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add an explicit overflow test. This updated parser and test look good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27964#pullrequestreview-3406455308