From jrose at openjdk.org Sat Feb 1 00:10:50 2025 From: jrose at openjdk.org (John R Rose) Date: Sat, 1 Feb 2025 00:10:50 GMT Subject: [jdk24] RFR: 8348890: Fix docs for -XX:AOT* options in java man page In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:20:42 GMT, Ioi Lam wrote: > Hi all, > > This pull request contains a backport of commit [cdc84acd](https://github.com/openjdk/jdk/commit/cdc84acdcc7689c2b2e42075a26939da14a1ba34) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Ioi Lam on 31 Jan 2025 and was reviewed by John R Rose. > > Thanks! Thanks. The changes at the end, about the interaction between `AOTClassLinking` and `AOTMode`, are necessary to explain why the JEP 483 command line examples work as advertised. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23404#pullrequestreview-2588086307 From iklam at openjdk.org Sat Feb 1 00:34:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 1 Feb 2025 00:34:55 GMT Subject: [jdk24] RFR: 8348890: Fix docs for -XX:AOT* options in java man page In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:30:33 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> This pull request contains a backport of commit [cdc84acd](https://github.com/openjdk/jdk/commit/cdc84acdcc7689c2b2e42075a26939da14a1ba34) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Ioi Lam on 31 Jan 2025 and was reviewed by John R Rose. >> >> Thanks! > > Good. Thanks @vnkozlov and @rose00 for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23404#issuecomment-2628619329 From iklam at openjdk.org Sat Feb 1 00:34:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 1 Feb 2025 00:34:55 GMT Subject: [jdk24] Integrated: 8348890: Fix docs for -XX:AOT* options in java man page In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:20:42 GMT, Ioi Lam wrote: > Hi all, > > This pull request contains a backport of commit [cdc84acd](https://github.com/openjdk/jdk/commit/cdc84acdcc7689c2b2e42075a26939da14a1ba34) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Ioi Lam on 31 Jan 2025 and was reviewed by John R Rose. > > Thanks! This pull request has now been integrated. Changeset: 5f5ed961 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/5f5ed961db8462b0e01ca83194722d4456ba2372 Stats: 41 lines in 1 file changed: 6 ins; 1 del; 34 mod 8348890: Fix docs for -XX:AOT* options in java man page Reviewed-by: kvn, jrose Backport-of: cdc84acdcc7689c2b2e42075a26939da14a1ba34 ------------- PR: https://git.openjdk.org/jdk/pull/23404 From alanb at openjdk.org Sat Feb 1 08:16:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 1 Feb 2025 08:16:53 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov wrote: > The fix implements streaming output support for attach protocol. > See JBS issue for evaluation, summary of the changes in the 1st comment. > Testing: tier1..4,hs-tier5-svc Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2628846029 From shade at openjdk.org Sat Feb 1 14:09:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 1 Feb 2025 14:09:54 GMT Subject: RFR: 8348402: PerfDataManager stalls shutdown for 1ms [v4] In-Reply-To: References: <7NPgtVYfbGwY1Go4y2NHro2chnexIw17gdaa1Yn7Bzo=.645b027a-4834-46b3-92cd-bcf9b8c1ff71@github.com> Message-ID: <6LK_37saxFEylVeIBc8G8A5DZDCk8j9p7POdH2ZE3Fw=.20114bb1-d901-4140-a62b-752e57e5c7a8@github.com> On Fri, 31 Jan 2025 08:30:29 GMT, Aleksey Shipilev wrote: >> Found this when studying Leyden performance. [JDK-8049304](https://bugs.openjdk.org/browse/JDK-8049304) added 1ms sleep on destruction path to catch up with threads updating the counters. >> >> I was not able to confidently prove the deletion race is benign. Even though `sleep` is not really a fix for that race either, I think it is safer to use GlobalCounter to coordinate deletions. >> >> This improves startup (roundtrip) tests for the expected 1ms: >> >> >> $ hyperfine -w 10 -r 100 ... >> >> # Before >> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello >> Time (mean ? ?): 20.0 ms ? 0.3 ms [User: 11.7 ms, System: 16.0 ms] >> Range (min ? max): 19.0 ms ? 21.7 ms 1000 runs >> >> # After >> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello >> Time (mean ? ?): 19.0 ms ? 0.3 ms [User: 11.9 ms, System: 15.8 ms] >> Range (min ? max): 18.2 ms ? 20.8 ms 1000 runs >> >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `all` >> - [x] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > David's review: more comments. Also reinstate has_PerfData in unprotected update. Thanks! I re-ran the tests locally, and they still pass. So I am integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23293#issuecomment-2628966696 From shade at openjdk.org Sat Feb 1 14:09:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 1 Feb 2025 14:09:55 GMT Subject: Integrated: 8348402: PerfDataManager stalls shutdown for 1ms In-Reply-To: <7NPgtVYfbGwY1Go4y2NHro2chnexIw17gdaa1Yn7Bzo=.645b027a-4834-46b3-92cd-bcf9b8c1ff71@github.com> References: <7NPgtVYfbGwY1Go4y2NHro2chnexIw17gdaa1Yn7Bzo=.645b027a-4834-46b3-92cd-bcf9b8c1ff71@github.com> Message-ID: On Fri, 24 Jan 2025 09:27:07 GMT, Aleksey Shipilev wrote: > Found this when studying Leyden performance. [JDK-8049304](https://bugs.openjdk.org/browse/JDK-8049304) added 1ms sleep on destruction path to catch up with threads updating the counters. > > I was not able to confidently prove the deletion race is benign. Even though `sleep` is not really a fix for that race either, I think it is safer to use GlobalCounter to coordinate deletions. > > This improves startup (roundtrip) tests for the expected 1ms: > > > $ hyperfine -w 10 -r 100 ... > > # Before > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello > Time (mean ? ?): 20.0 ms ? 0.3 ms [User: 11.7 ms, System: 16.0 ms] > Range (min ? max): 19.0 ms ? 21.7 ms 1000 runs > > # After > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello > Time (mean ? ?): 19.0 ms ? 0.3 ms [User: 11.9 ms, System: 15.8 ms] > Range (min ? max): 18.2 ms ? 20.8 ms 1000 runs > > > Additional testing: > - [x] Linux AArch64 server fastdebug, `all` > - [x] Linux x86_64 server fastdebug, `all` This pull request has now been integrated. Changeset: 305bbdae Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/305bbdae7fe40e33cf2baa100c134bd85ecaa553 Stats: 56 lines in 5 files changed: 34 ins; 4 del; 18 mod 8348402: PerfDataManager stalls shutdown for 1ms Reviewed-by: dholmes, pchilanomate, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/23293 From jpai at openjdk.org Sun Feb 2 13:22:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 2 Feb 2025 13:22:44 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 19:42:55 GMT, Volkan Yazici wrote: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added test/lib/jdk/test/lib/Asserts.java line 623: > 621: * @throws IOException on I/O failures > 622: */ > 623: public static void assertFileContentsEqual(Path f1, Path f2) throws IOException { Hello Volkan, is this new method needed? Can its call sites instead be replaced with `java.nio.file.Files.mismatch(...)` call? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1938490806 From dholmes at openjdk.org Mon Feb 3 07:41:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Feb 2025 07:41:48 GMT Subject: RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed [v13] In-Reply-To: References: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> Message-ID: On Fri, 31 Jan 2025 21:43:02 GMT, Serguei Spitsyn wrote: >> Below is the root cause of the bug described by Patricio: >> The root of the issue is similar to [JDK-8345543](https://bugs.openjdk.org/browse/JDK-8345543), but instead of `JavaThreadBlockedOnMonitorEnterState`, the interaction here is with its equivalent for Object.wait, `JavaThreadInObjectWaitState`. >> >> We change the `Thread.State` of the carrier to `TIMED_WAITING` before we try preempting the `vthread`. So we can see the `Thread.State` of the vthread as `TIMED_WAITING` before even calling `try_preempt()` (when the state is `RUNNING` we return the `Thread.State` of the carrier). Then when we check for `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`, we caught the `vthread` in `afterYield()` still with the transitional state of `TIMED_WAITING`, which is mapped to `Thread.State.RUNNABLE`. >> >> The fix is to delay the state change to `JavaThreadStatus::IN_OBJECT_WAIT*` the point after block with the `try_preempt()` call. The fix is not elegant and hacky but I do not see a better solution. The ugliness comes from the fact that the `ObjectMonitor::wait()` is called from two places: `ObjectSynchronizer::wait()` and `ObjectSynchronizer::waitUninterruptibly()`. We do not need the `JavaThreadInObjectWaitState` in the second cases, so the object is defined in the `JVM_MonitorWait()` but not in the `ObjectMonitor::wait()`. >> Maybe, deep refactoring the`JavaThreadInObjectWaitState` base class `JavaThreadStatusChanger` could be a better solution but it is going to be much more intrusive. >> >> Testing: >> - Checked the failed test does not fail with the fix: `serviceability/jvmti/vthread/GetThreadState/GetThreadState.java` >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: better clarification in the comments Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23126#pullrequestreview-2589121296 From vyazici at openjdk.org Mon Feb 3 09:25:08 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Feb 2025 09:25:08 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v2] In-Reply-To: References: Message-ID: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Remove `assertFileContentsEqual()` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23401/files - new: https://git.openjdk.org/jdk/pull/23401/files/29571eab..421d19d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=00-01 Stats: 56 lines in 7 files changed: 6 ins; 44 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From vyazici at openjdk.org Mon Feb 3 09:28:54 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Feb 2025 09:28:54 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v2] In-Reply-To: References: Message-ID: On Sun, 2 Feb 2025 13:20:39 GMT, Jaikiran Pai wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove `assertFileContentsEqual()` > > test/lib/jdk/test/lib/Asserts.java line 623: > >> 621: * @throws IOException on I/O failures >> 622: */ >> 623: public static void assertFileContentsEqual(Path f1, Path f2) throws IOException { > > Hello Volkan, is this new method needed? Can its call sites instead be replaced with `java.nio.file.Files.mismatch(...)` call? I thought it reports more useful diagnostics compared to the earlier `file compare failed` message. Nevertheless, replaced it with `Files::mismatch` in 421d19d468d62bdb04aee458c72a338a5c053e73. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1939052590 From mli at openjdk.org Mon Feb 3 09:32:29 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 3 Feb 2025 09:32:29 GMT Subject: RFR: 8348575: SpinLockT is typedef'ed but unused [v2] In-Reply-To: References: Message-ID: <2AVZSDr1LWvHC-ATP-u79NVW3Kac6W0WZvsSZhFSkXU=.f78edb83-044c-469a-be04-2e8c5caa5456@github.com> > Hi, > Can you help to review this simple patch? > > SpinLockT is typedef'ed, but there is no usage of it. I think this is a legacy code from long time before. Also remove/modify some related comment. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23298/files - new: https://git.openjdk.org/jdk/pull/23298/files/46682ab2..0ae21541 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23298&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23298&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23298/head:pull/23298 PR: https://git.openjdk.org/jdk/pull/23298 From mli at openjdk.org Mon Feb 3 09:32:29 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 3 Feb 2025 09:32:29 GMT Subject: RFR: 8348575: SpinLockT is typedef'ed but unused [v2] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 06:14:09 GMT, David Holmes wrote: > Good catch! That typedef has actually never been used. > > A couple of minor suggestions on the comments, but I will approve ahead of time, so it doesn't get held up awaiting my re-review. Although I think this should count as trivial you will need a second review anyway if you make the suggested changes. @dholmes-ora Sorry for the delay, I've been on vacation. Thank you for reviewing! I just updated the patch. I think this patch is trivial? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23298#issuecomment-2630401176 From dholmes at openjdk.org Mon Feb 3 11:57:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Feb 2025 11:57:49 GMT Subject: RFR: 8348575: SpinLockT is typedef'ed but unused [v2] In-Reply-To: <2AVZSDr1LWvHC-ATP-u79NVW3Kac6W0WZvsSZhFSkXU=.f78edb83-044c-469a-be04-2e8c5caa5456@github.com> References: <2AVZSDr1LWvHC-ATP-u79NVW3Kac6W0WZvsSZhFSkXU=.f78edb83-044c-469a-be04-2e8c5caa5456@github.com> Message-ID: On Mon, 3 Feb 2025 09:32:29 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this simple patch? >> >> SpinLockT is typedef'ed, but there is no usage of it. I think this is a legacy code from long time before. Also remove/modify some related comment. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > minor LGTM ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23298#pullrequestreview-2589680755 From mli at openjdk.org Mon Feb 3 12:35:51 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 3 Feb 2025 12:35:51 GMT Subject: RFR: 8348575: SpinLockT is typedef'ed but unused [v2] In-Reply-To: <2AVZSDr1LWvHC-ATP-u79NVW3Kac6W0WZvsSZhFSkXU=.f78edb83-044c-469a-be04-2e8c5caa5456@github.com> References: <2AVZSDr1LWvHC-ATP-u79NVW3Kac6W0WZvsSZhFSkXU=.f78edb83-044c-469a-be04-2e8c5caa5456@github.com> Message-ID: <7pOSofrWLd7Tzz_PWCs023hrpVl_GbDaU15PxTvvb0c=.eb4e4f00-13e3-4997-8436-0af9c16eb0de@github.com> On Mon, 3 Feb 2025 09:32:29 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this simple patch? >> >> SpinLockT is typedef'ed, but there is no usage of it. I think this is a legacy code from long time before. Also remove/modify some related comment. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > minor Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23298#issuecomment-2630821545 From mli at openjdk.org Mon Feb 3 12:35:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 3 Feb 2025 12:35:52 GMT Subject: Integrated: 8348575: SpinLockT is typedef'ed but unused In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 12:05:25 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > > SpinLockT is typedef'ed, but there is no usage of it. I think this is a legacy code from long time before. Also remove/modify some related comment. > > Thanks This pull request has now been integrated. Changeset: 3f1d9b57 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/3f1d9b573546685215af06031656efe6f1429caf Stats: 11 lines in 1 file changed: 0 ins; 9 del; 2 mod 8348575: SpinLockT is typedef'ed but unused Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23298 From coleenp at openjdk.org Mon Feb 3 13:57:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 3 Feb 2025 13:57:52 GMT Subject: RFR: 8337548: Parallel class loading can pass is_superclass true for interfaces [v4] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 14:18:11 GMT, Coleen Phillimore wrote: >> There's an optimization in class loading that looks up class being loaded while loading its superclass, and if the class is found, it will check the superclass name against klass->_super and match class loaders. It's supposed to be a optimization to short circuit taking out the LOAD_SUPER (now called DETECT_CIRCULARITY) placeholder for the class being loaded. So for example, loading class C, super S, we take out a DETECT_CIRCULARITY placeholder for C to detect if S then tries to load C as a super class by the same thread. >> >> This optimization is almost never done because it requires just the right timing for a parallel thread to load the class right before this thread reaches the if statement (perhaps some long stall). The only case where this code is reached normally is for redefinition. Loading a new class file version will find the class in the System Dictionary because we can only redefine already loaded classes. >> >> It should be harmess to remove this if-statement in the case of redefinition also, but I think having a placeholder created for a known already-loaded class seems to break an understanding of how this works. So I opted to just add to the comment and restructure the method a little bit. The dictionary->find_class() call doesn't need to be inside the SystemDictionary_lock. >> >> Tested with tier1-4 and internal parallel class loading tests. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some restructuring and comment changes and is_superclass Thanks for reviewing David and Ioi. I ran tests tier 1-8 on this change with no failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23322#issuecomment-2631069548 From coleenp at openjdk.org Mon Feb 3 13:57:57 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 3 Feb 2025 13:57:57 GMT Subject: Integrated: 8337548: Parallel class loading can pass is_superclass true for interfaces In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 23:02:12 GMT, Coleen Phillimore wrote: > There's an optimization in class loading that looks up class being loaded while loading its superclass, and if the class is found, it will check the superclass name against klass->_super and match class loaders. It's supposed to be a optimization to short circuit taking out the LOAD_SUPER (now called DETECT_CIRCULARITY) placeholder for the class being loaded. So for example, loading class C, super S, we take out a DETECT_CIRCULARITY placeholder for C to detect if S then tries to load C as a super class by the same thread. > > This optimization is almost never done because it requires just the right timing for a parallel thread to load the class right before this thread reaches the if statement (perhaps some long stall). The only case where this code is reached normally is for redefinition. Loading a new class file version will find the class in the System Dictionary because we can only redefine already loaded classes. > > It should be harmess to remove this if-statement in the case of redefinition also, but I think having a placeholder created for a known already-loaded class seems to break an understanding of how this works. So I opted to just add to the comment and restructure the method a little bit. The dictionary->find_class() call doesn't need to be inside the SystemDictionary_lock. > > Tested with tier1-4 and internal parallel class loading tests. This pull request has now been integrated. Changeset: d330421d Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/d330421d28b62eae19114994d7266e9c0038dd94 Stats: 44 lines in 2 files changed: 18 ins; 16 del; 10 mod 8337548: Parallel class loading can pass is_superclass true for interfaces Reviewed-by: iklam ------------- PR: https://git.openjdk.org/jdk/pull/23322 From coleenp at openjdk.org Mon Feb 3 14:05:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 3 Feb 2025 14:05:52 GMT Subject: RFR: 8337548: Parallel class loading can pass is_superclass true for interfaces [v4] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 14:18:11 GMT, Coleen Phillimore wrote: >> There's an optimization in class loading that looks up class being loaded while loading its superclass, and if the class is found, it will check the superclass name against klass->_super and match class loaders. It's supposed to be a optimization to short circuit taking out the LOAD_SUPER (now called DETECT_CIRCULARITY) placeholder for the class being loaded. So for example, loading class C, super S, we take out a DETECT_CIRCULARITY placeholder for C to detect if S then tries to load C as a super class by the same thread. >> >> This optimization is almost never done because it requires just the right timing for a parallel thread to load the class right before this thread reaches the if statement (perhaps some long stall). The only case where this code is reached normally is for redefinition. Loading a new class file version will find the class in the System Dictionary because we can only redefine already loaded classes. >> >> It should be harmess to remove this if-statement in the case of redefinition also, but I think having a placeholder created for a known already-loaded class seems to break an understanding of how this works. So I opted to just add to the comment and restructure the method a little bit. The dictionary->find_class() call doesn't need to be inside the SystemDictionary_lock. >> >> Tested with tier1-4 and internal parallel class loading tests. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some restructuring and comment changes and is_superclass Sorry David, I thought you had approved this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23322#issuecomment-2631093712 From sspitsyn at openjdk.org Mon Feb 3 16:03:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Feb 2025 16:03:48 GMT Subject: RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed [v13] In-Reply-To: References: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> Message-ID: On Fri, 31 Jan 2025 21:43:02 GMT, Serguei Spitsyn wrote: >> Below is the root cause of the bug described by Patricio: >> The root of the issue is similar to [JDK-8345543](https://bugs.openjdk.org/browse/JDK-8345543), but instead of `JavaThreadBlockedOnMonitorEnterState`, the interaction here is with its equivalent for Object.wait, `JavaThreadInObjectWaitState`. >> >> We change the `Thread.State` of the carrier to `TIMED_WAITING` before we try preempting the `vthread`. So we can see the `Thread.State` of the vthread as `TIMED_WAITING` before even calling `try_preempt()` (when the state is `RUNNING` we return the `Thread.State` of the carrier). Then when we check for `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`, we caught the `vthread` in `afterYield()` still with the transitional state of `TIMED_WAITING`, which is mapped to `Thread.State.RUNNABLE`. >> >> The fix is to delay the state change to `JavaThreadStatus::IN_OBJECT_WAIT*` the point after block with the `try_preempt()` call. The fix is not elegant and hacky but I do not see a better solution. The ugliness comes from the fact that the `ObjectMonitor::wait()` is called from two places: `ObjectSynchronizer::wait()` and `ObjectSynchronizer::waitUninterruptibly()`. We do not need the `JavaThreadInObjectWaitState` in the second cases, so the object is defined in the `JVM_MonitorWait()` but not in the `ObjectMonitor::wait()`. >> Maybe, deep refactoring the`JavaThreadInObjectWaitState` base class `JavaThreadStatusChanger` could be a better solution but it is going to be much more intrusive. >> >> Testing: >> - Checked the failed test does not fail with the fix: `serviceability/jvmti/vthread/GetThreadState/GetThreadState.java` >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: better clarification in the comments Thank you for review, David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23126#issuecomment-2631415547 From vyazici at openjdk.org Mon Feb 3 19:10:34 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Feb 2025 19:10:34 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v3] In-Reply-To: References: Message-ID: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Replace forgotten `assertFileContentsEqual()` calls - Merge remote-tracking branch 'upstream/master' into LargeFile - Remove `assertFileContentsEqual()` - Move file content assertion to `test/lib/Asserts` - Move HTTP-specific temp. file methods to `test.lib.Utils` - Replace the `docs/test1` folder with dynamically created files - Employ `TestUtil::assertFilesEqual` in `sun.net.httpserver` tests - Improve `TestUtil::getAFile` - Improve `TestUtil::compareFiles` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23401/files - new: https://git.openjdk.org/jdk/pull/23401/files/421d19d4..a7c44540 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=01-02 Stats: 8138 lines in 188 files changed: 1548 ins; 4470 del; 2120 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From vyazici at openjdk.org Mon Feb 3 19:26:03 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Feb 2025 19:26:03 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v4] In-Reply-To: References: Message-ID: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: - Assert that multiple files can be served using the same `FileServerHandler` - Remove redundant `@build` dependencies ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23401/files - new: https://git.openjdk.org/jdk/pull/23401/files/a7c44540..4efc42f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=02-03 Stats: 23 lines in 7 files changed: 10 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From amenkov at openjdk.org Mon Feb 3 20:12:15 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 3 Feb 2025 20:12:15 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> Message-ID: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> On Sat, 1 Feb 2025 08:14:15 GMT, Alan Bateman wrote: > Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2631965659 From dholmes at openjdk.org Mon Feb 3 20:43:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Feb 2025 20:43:15 GMT Subject: RFR: 8337548: Parallel class loading can pass is_superclass true for interfaces [v4] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 14:18:11 GMT, Coleen Phillimore wrote: >> There's an optimization in class loading that looks up class being loaded while loading its superclass, and if the class is found, it will check the superclass name against klass->_super and match class loaders. It's supposed to be a optimization to short circuit taking out the LOAD_SUPER (now called DETECT_CIRCULARITY) placeholder for the class being loaded. So for example, loading class C, super S, we take out a DETECT_CIRCULARITY placeholder for C to detect if S then tries to load C as a super class by the same thread. >> >> This optimization is almost never done because it requires just the right timing for a parallel thread to load the class right before this thread reaches the if statement (perhaps some long stall). The only case where this code is reached normally is for redefinition. Loading a new class file version will find the class in the System Dictionary because we can only redefine already loaded classes. >> >> It should be harmess to remove this if-statement in the case of redefinition also, but I think having a placeholder created for a known already-loaded class seems to break an understanding of how this works. So I opted to just add to the comment and restructure the method a little bit. The dictionary->find_class() call doesn't need to be inside the SystemDictionary_lock. >> >> Tested with tier1-4 and internal parallel class loading tests. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some restructuring and comment changes and is_superclass Okay. Approved. ------------- PR Review: https://git.openjdk.org/jdk/pull/23322#pullrequestreview-2590956526 From coleenp at openjdk.org Mon Feb 3 20:55:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 3 Feb 2025 20:55:18 GMT Subject: RFR: 8337548: Parallel class loading can pass is_superclass true for interfaces [v4] In-Reply-To: References: Message-ID: <2fQ3U6Q7hAMO-komosdGrzoyE5ZNT0rzGuUUjDAd-Ck=.27b9c252-1495-436a-b10f-3e3950ba3f7c@github.com> On Fri, 31 Jan 2025 14:18:11 GMT, Coleen Phillimore wrote: >> There's an optimization in class loading that looks up class being loaded while loading its superclass, and if the class is found, it will check the superclass name against klass->_super and match class loaders. It's supposed to be a optimization to short circuit taking out the LOAD_SUPER (now called DETECT_CIRCULARITY) placeholder for the class being loaded. So for example, loading class C, super S, we take out a DETECT_CIRCULARITY placeholder for C to detect if S then tries to load C as a super class by the same thread. >> >> This optimization is almost never done because it requires just the right timing for a parallel thread to load the class right before this thread reaches the if statement (perhaps some long stall). The only case where this code is reached normally is for redefinition. Loading a new class file version will find the class in the System Dictionary because we can only redefine already loaded classes. >> >> It should be harmess to remove this if-statement in the case of redefinition also, but I think having a placeholder created for a known already-loaded class seems to break an understanding of how this works. So I opted to just add to the comment and restructure the method a little bit. The dictionary->find_class() call doesn't need to be inside the SystemDictionary_lock. >> >> Tested with tier1-4 and internal parallel class loading tests. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some restructuring and comment changes and is_superclass Thank you, David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23322#issuecomment-2632049248 From jiangli at openjdk.org Tue Feb 4 01:16:14 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 4 Feb 2025 01:16:14 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK Message-ID: Please review runtime/jni/atExit/TestAtExit.java test change: - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: - JNI_GetDefaultJavaVMInitArgs - JNI_GetCreatedJavaVMs - JNI_CreateJavaVM On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. ------------- Commit messages: - Fix typo. - - Remove BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit and don't link with libjvm for libatExit. Changes: https://git.openjdk.org/jdk/pull/23431/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23431&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349178 Stats: 56 lines in 2 files changed: 52 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23431/head:pull/23431 PR: https://git.openjdk.org/jdk/pull/23431 From alanb at openjdk.org Tue Feb 4 06:09:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Feb 2025 06:09:10 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> Message-ID: On Mon, 3 Feb 2025 20:09:14 GMT, Alex Menkov wrote: > > Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? > > I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output. Thread.dump_to_file is an example that needs this. There will be many more in the future. So while not for this PR we should we thinking about a follow-up to put in the infrastructure to support this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2632961617 From stuefe at openjdk.org Tue Feb 4 07:04:13 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Feb 2025 07:04:13 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> Message-ID: On Mon, 3 Feb 2025 20:09:14 GMT, Alex Menkov wrote: >> Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? > >> Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? > > I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output. @alexmenkov Oh, this is great, many thanks for doing this work! Good explanations too. I had a cursory view over the changes. Will do a more thorough review, and play around with this, when I am back home. With streaming, what is the expected behavior if a command takes too long? Jcmd stops with timeout, and the hotspot JVM then discards the results? Unless the tests are easy to fix, I don't see any problem with just running them in old buffered mode. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2633044064 From dholmes at openjdk.org Tue Feb 4 10:45:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Feb 2025 10:45:09 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com> On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. > - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: > - JNI_GetDefaultJavaVMInitArgs > - JNI_GetCreatedJavaVMs > - JNI_CreateJavaVM > > On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. > > For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. > > TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a _static_ JDK we have to rewrite the test to perform a _dynamic_ lookup! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2633523332 From dfuchs at openjdk.org Tue Feb 4 10:59:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 4 Feb 2025 10:59:14 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v4] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 19:26:03 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: > > - Assert that multiple files can be served using the same `FileServerHandler` > - Remove redundant `@build` dependencies test/jdk/com/sun/net/httpserver/SelCacheTest.java line 77: > 75: s2 = HttpsServer.create(addr, 0); > 76: // Assert that both files share the same parent and can be served from the same `FileServerHandler` > 77: assert smallFilePath.getParent().equals(largeFilePath.getParent()); I see what you are doing here. On the one hand I thought that it would be better placed right after line 66, but on the other hand we want it inside the `try { }` so that files will be deleted on `finally` even if it fires. So LGTM. test/jdk/com/sun/net/httpserver/SelCacheTest.java line 145: > 143: fout.close(); > 144: > 145: if (count != filePath.toFile().length()) { Maybe we could use assertEquals here for better diagnosability test/jdk/com/sun/net/httpserver/SelCacheTest.java line 149: > 147: } > 148: Path tempPath = temp.toPath(); > 149: assert Files.mismatch(filePath, tempPath) < 0; I would suggest using `assertEquals` with -1 here to ensure that: 1. the test will fail if the files don't match even if asserts are disabled, and 2. we see at which place mismatch was detected in the exception message test/jdk/com/sun/net/httpserver/Test1.java line 160: > 158: } > 159: Path tempPath = temp.toPath(); > 160: assert Files.mismatch(filePath, tempPath) < 0; Same suggestions WRT assertEquals here test/jdk/com/sun/net/httpserver/Test12.java line 182: > 180: } > 181: Path tempPath = temp.toPath(); > 182: assert Files.mismatch(filePath, tempPath) < 0; and here as well test/jdk/com/sun/net/httpserver/Test13.java line 184: > 182: } > 183: Path tempPath = temp.toPath(); > 184: assert Files.mismatch(filePath, tempPath) < 0; ditto test/jdk/com/sun/net/httpserver/Test9.java line 202: > 200: } > 201: Path tempPath = temp.toPath(); > 202: assert Files.mismatch(filePath, tempPath) < 0; And in all other places where this pattern appears in this PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940924335 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940936508 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940935266 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940941328 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940942729 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940943725 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940945015 From vyazici at openjdk.org Tue Feb 4 12:04:47 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 12:04:47 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v5] In-Reply-To: References: Message-ID: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com> > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Replace `assert`s with conditionally thrown exceptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23401/files - new: https://git.openjdk.org/jdk/pull/23401/files/4efc42f7..9c7c6af0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=03-04 Stats: 90 lines in 9 files changed: 47 ins; 21 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From vyazici at openjdk.org Tue Feb 4 12:17:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 12:17:12 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v4] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 10:46:33 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: >> >> - Assert that multiple files can be served using the same `FileServerHandler` >> - Remove redundant `@build` dependencies > > test/jdk/com/sun/net/httpserver/SelCacheTest.java line 149: > >> 147: } >> 148: Path tempPath = temp.toPath(); >> 149: assert Files.mismatch(filePath, tempPath) < 0; > > I would suggest using `assertEquals` with -1 here to ensure that: > > 1. the test will fail if the files don't match even if asserts are disabled, and > 2. we see at which place mismatch was detected in the exception message In 9c7c6af013e0495b08bcd248e30d83385bcc35b5, - Used `Asserts::assertEquals` to compare `count` and `filePath.toFile().length()` (as you requested above) - Replaced `assert Files.mismatch(...) < 0` with a **newly added** `Asserts::assertFileContentsEqual` I opted for a new method (using `Files::mismatch` under the hood) since it - Provides better diagnostics (source & target paths) - Doesn't bother call-sites with `IOException`s (in line with JUnit, AssertJ, etc. assertions) - Saves ~11 LoC at each call-site @jaikiran, earlier you wanted me to remove `Asserts::assertFileContentsEqual` in favor of a check against `Files::mismatch`. I switched back to the old behavior, because of the advantages I shared above, plus we import `Asserts` for `assertEquals` anyway. @dfuch, @jaikiran, I would appreciate your input before resolving this conversation. > test/jdk/com/sun/net/httpserver/Test1.java line 160: > >> 158: } >> 159: Path tempPath = temp.toPath(); >> 160: assert Files.mismatch(filePath, tempPath) < 0; > > Same suggestions WRT assertEquals here Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5. > test/jdk/com/sun/net/httpserver/Test12.java line 182: > >> 180: } >> 181: Path tempPath = temp.toPath(); >> 182: assert Files.mismatch(filePath, tempPath) < 0; > > and here as well Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5. > test/jdk/com/sun/net/httpserver/Test13.java line 184: > >> 182: } >> 183: Path tempPath = temp.toPath(); >> 184: assert Files.mismatch(filePath, tempPath) < 0; > > ditto Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5. > test/jdk/com/sun/net/httpserver/Test9.java line 202: > >> 200: } >> 201: Path tempPath = temp.toPath(); >> 202: assert Files.mismatch(filePath, tempPath) < 0; > > And in all other places where this pattern appears in this PR Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941055912 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056394 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056606 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056800 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056994 From jsjolen at openjdk.org Tue Feb 4 12:39:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 4 Feb 2025 12:39:14 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov wrote: > The fix implements streaming output support for attach protocol. > See JBS issue for evaluation, summary of the changes in the 1st comment. > Testing: tier1..4,hs-tier5-svc Hi Alex, Thank you for this. It's very good to have this feature. I'm still reading the code, but I'm submitting these comments as a first round. I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed? Thanks, Johan src/hotspot/share/services/attachListener.cpp line 53: > 51: > 52: // Stream for printing attach operation results. > 53: // Supports buffered and streaming output for commands which can produce lenghtly reply. "lengthy" src/hotspot/share/services/attachListener.cpp line 56: > 54: // > 55: // To support streaming output platform implementation need to implement AttachOperation::get_reply_writer() method > 56: // and ctor allow_streaming argument should be set to true. Strange mix of "need" and "should". Can we split this into multiple sentences? Here's a suggestion, though I'm not sure if it's 100% correct :-). An output platform implementation supports streaming if it implements AttachOperation::get_reply_writer(). Streaming is enabled if the allow_streaming in the constructor is set to true. src/hotspot/share/services/attachListener.cpp line 139: > 137: } > 138: } else { > 139: /* TODO: handle buffer overflow Important `TODO` :-). src/hotspot/share/services/diagnosticFramework.cpp line 389: > 387: int count = 0; > 388: while (iter.has_next()) { > 389: if(_source == DCmd_Source_MBean && count > 0) { Pre-existing style: Space between `if` and condition missing. ------------- PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2592338074 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940877174 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940882015 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940886089 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940875712 From jsjolen at openjdk.org Tue Feb 4 13:53:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 4 Feb 2025 13:53:26 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> On Thu, 30 Jan 2025 12:55:35 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix in shendoahCardTable Some issues found from misses made during merging. test/hotspot/gtest/nmt/test_vmatree.cpp line 831: > 829: tty->cr(); > 830: } > 831: } This looks like a test which was added when you merged in an earlier version of https://github.com/openjdk/jdk/pull/20994 This should be removed. test/hotspot/jtreg/compiler/stringopts/TestFluidAndNonFluid.java line 1: > 1: /* Incorrect merge resolution. test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 325: > 323: output.shouldMatch("\\[0x[0]*" + Long.toHexString(addr) + " - 0x[0]*" > 324: + Long.toHexString(addr + size) > 325: + "\\] committed " + sizeString); Not sure why this is changed. test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java line 182: > 180: throw new RuntimeException("Expected a higher delta between stack committed of with and without pretouch." + > 181: "Expected: " + expected_delta + " Actual: " + actual_delta); > 182: } Is this meant to be part of this PR? test/micro/org/openjdk/bench/vm/compiler/FluidSBBench.java line 1: > 1: /* This must be the result of an incorrect merge conflict resolution. It should be deleted. ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2550042933 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941207799 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941201897 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941199974 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941201150 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941198899 From jsjolen at openjdk.org Tue Feb 4 14:01:31 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 4 Feb 2025 14:01:31 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 30 Jan 2025 12:55:35 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix in shendoahCardTable src/hotspot/share/nmt/virtualMemoryTracker.cpp line 2: > 1: /* > 2: * Copyright (c) 2013, 2025, Oracle and/or its affiliates. All rights reserved. Weird, another copyright issue here src/hotspot/share/nmt/virtualMemoryTracker.hpp line 3: > 1: /* > 2: * Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Incorrect copyright addition. src/hotspot/share/nmt/virtualMemoryTracker.hpp line 27: > 25: > 26: #ifndef NMT_VIRTUALMEMORYTRACKER_HPP > 27: #define NMT_VIRTUALMEMORYTRACKER_HPP This shouldn't be changed??? src/hotspot/share/nmt/vmatree.cpp line 81: > 79: stA.out.set_tag(tag); > 80: LEQ_A.state.out.set_tag(tag); > 81: stB.in.set_tag(tag); Commented out assert and an addition I'm trying to wrap my head around. Does this fix a pre-existing bug? If so, this should be a separate PR for mainline before this PR is integrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941220423 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941219903 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941219525 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1941214505 From dfuchs at openjdk.org Tue Feb 4 14:20:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 4 Feb 2025 14:20:10 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v5] In-Reply-To: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com> References: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com> Message-ID: On Tue, 4 Feb 2025 12:04:47 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Replace `assert`s with conditionally thrown exceptions Generally LGTM - still one place calling `assert Files.mismatch(..)...` test/jdk/com/sun/net/httpserver/SelCacheTest.java line 80: > 78: s2 = HttpsServer.create(addr, 0); > 79: // Assert that both files share the same parent and can be served from the same `FileServerHandler` > 80: assertEquals(smallFilePath.getParent(), largeFilePath.getParent()); That's OK. You could have kept `assert` here as it should not happen and would point to an issue with the logic in the test. But assertEquals will show us both paths if that happens, which is a +. test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java line 180: > 178: }); > 179: response.join(); > 180: assert Files.mismatch(src, dest) < 0; Missed call to `assertFileContentsEqual`? ------------- PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2592973383 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941241819 PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941256241 From vyazici at openjdk.org Tue Feb 4 14:26:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 14:26:23 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v6] In-Reply-To: References: Message-ID: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23401/files - new: https://git.openjdk.org/jdk/pull/23401/files/9c7c6af0..5e9b30f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From vyazici at openjdk.org Tue Feb 4 14:26:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 14:26:24 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v5] In-Reply-To: References: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com> Message-ID: On Tue, 4 Feb 2025 14:15:00 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace `assert`s with conditionally thrown exceptions > > test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java line 180: > >> 178: }); >> 179: response.join(); >> 180: assert Files.mismatch(src, dest) < 0; > > Missed call to `assertFileContentsEqual`? Doh! :facepalm: Fixed in 5e9b30f431676c714cf81b85846f16c58c0dcdf6. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941272158 From vyazici at openjdk.org Tue Feb 4 14:29:13 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 14:29:13 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v4] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 10:47:22 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: >> >> - Assert that multiple files can be served using the same `FileServerHandler` >> - Remove redundant `@build` dependencies > > test/jdk/com/sun/net/httpserver/SelCacheTest.java line 145: > >> 143: fout.close(); >> 144: >> 145: if (count != filePath.toFile().length()) { > > Maybe we could use assertEquals here for better diagnosability Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941277359 From dfuchs at openjdk.org Tue Feb 4 16:38:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 4 Feb 2025 16:38:14 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v6] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest` Approving subject to tier2 still passing and tests keeping stable. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2593438203 From jiangli at openjdk.org Tue Feb 4 16:53:10 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 4 Feb 2025 16:53:10 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com> References: <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com> Message-ID: <2Nds-2Yjm3OCM766NqCT2jUCMuP7p0FbRQXSRtS9e6Y=.66a07400-9597-4609-bb06-88b43d402468@github.com> On Tue, 4 Feb 2025 10:42:50 GMT, David Holmes wrote: > @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a _static_ JDK we have to rewrite the test to perform a _dynamic_ lookup! @dholmes-ora Thanks for the forthright response. JNI functions are already dynamically called. E.g. in the same test here: res = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL); We don't need to change those at all to work on static-jdk. The existing design of JNI functions can work on both dynamic JDK and static JDK. The calls fixed by this PR are the very few exceptions that do not follow the design principle. I do think we should fix them by following the right patterns/conventions. Note `LoadJavaVM` in JDK code (https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.base/unix/native/libjli/java_md.c#L524C1-L524C11) calls these functions 'properly', see https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.base/unix/native/libjli/java_md.c#L548. So far I've only found this test in hotspot tier1 and libExplicitAttach (AttachTest_id0) in JDK tier1 with the issue. @dholmes-ora If we don't go this change, do you have any other suggestion? One other possible alternative that I can think is using weak symbols, however I think that's no better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634531490 From jiangli at openjdk.org Tue Feb 4 17:20:12 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 4 Feb 2025 17:20:12 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. > - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: > - JNI_GetDefaultJavaVMInitArgs > - JNI_GetCreatedJavaVMs > - JNI_CreateJavaVM > > On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. > > For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. > > TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634595988 From alanb at openjdk.org Tue Feb 4 19:07:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Feb 2025 19:07:16 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou wrote: >> Please review runtime/jni/atExit/TestAtExit.java test change: >> >> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. >> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: >> - JNI_GetDefaultJavaVMInitArgs >> - JNI_GetCreatedJavaVMs >> - JNI_CreateJavaVM >> >> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. >> >> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. >> >> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. > > Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup! A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM). So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634824084 From jiangli at openjdk.org Tue Feb 4 19:45:20 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 4 Feb 2025 19:45:20 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:04:22 GMT, Alan Bateman wrote: > A static build isn't really suitable for custom launchers (or anything that embeds a VM). Just want to provide some relevant data point. We build custom launcher and statically link with the libjvm (for hermetic case). If libjvm is statically linked with the launcher, then there's actually no need to change the direct calls to those JNI_ functions. The direct calls are not problematic on static build. > An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. The alternative also sounds reasonable to me. We could skip running on static JDK if a test explicitly requires libjvm.so, libjava.so, etc at runtime, at least initially. > At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway. That's a good point. We can add a `vm.static.jdk` to help test selection. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634906630 From amenkov at openjdk.org Tue Feb 4 19:51:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Feb 2025 19:51:26 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> Message-ID: <6alqVi_g6MPcYJ2ikBumixTicMK3IpoSVmpFLM9AMiI=.a0b9137f-5f15-4e81-b1fd-c2c79c90915e@github.com> On Tue, 4 Feb 2025 06:06:18 GMT, Alan Bateman wrote: > > > Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool? > > > > > > I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output. > > Thread.dump_to_file is an example that needs this. There will be many more in the future. So while not for this PR we should we thinking about a follow-up to put in the infrastructure to support this. We have [JDK-8336723](https://bugs.openjdk.org/browse/JDK-8336723) to implement streaming output for commands implemented in java. This PR is lower level and provides functionality required for JDK-8336723 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634917509 From amenkov at openjdk.org Tue Feb 4 20:07:09 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Feb 2025 20:07:09 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com> <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com> Message-ID: <1_BKSEInasVApGdnYKQqc354hLaqfv0hWdhJ8JXsnak=.93b1ab2e-ceb4-4dd2-8d38-8f7cfdc45cb4@github.com> On Tue, 4 Feb 2025 07:01:52 GMT, Thomas Stuefe wrote: > With streaming, what is the expected behavior if a command takes too long? Jcmd stops with timeout, and the hotspot JVM then discards the results? When a tool is run interactively (I mean not as part of a testing) there is no timeouts - the tools forward any output from the target VM to stdout until communication channel (socket/pipe) is closed. With streaming the tool just prints command output earlier. If jcmd is killed while the command is in progress, the VM completes the command anyway (we don't have a way to stop it), results are discarded. > Unless the tests are easy to fix, I don't see any problem with just running them in old buffered mode. Yes, this is the plan for the next step - fix the tests of disable streaming output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634946997 From amenkov at openjdk.org Tue Feb 4 20:15:10 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Feb 2025 20:15:10 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Tue, 4 Feb 2025 12:36:06 GMT, Johan Sj?len wrote: > I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed? The protocol works as before. All command handlers are updated to set the result code earlier (after argument parsing, but before command execution). After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634963089 From amenkov at openjdk.org Tue Feb 4 20:26:17 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Feb 2025 20:26:17 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Tue, 4 Feb 2025 10:16:45 GMT, Johan Sj?len wrote: >> The fix implements streaming output support for attach protocol. >> See JBS issue for evaluation, summary of the changes in the 1st comment. >> Testing: tier1..4,hs-tier5-svc > > src/hotspot/share/services/attachListener.cpp line 139: > >> 137: } >> 138: } else { >> 139: /* TODO: handle buffer overflow > > Important `TODO` :-). This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307) @tstuefe Do you want to keep this comment to work on JDK-8319307? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1941840271 From vyazici at openjdk.org Tue Feb 4 20:27:16 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Feb 2025 20:27:16 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v6] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest` Successful `tier{1,2}` test run reports on 5e9b30f431676c714cf81b85846f16c58c0dcdf6 is attached to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23401#issuecomment-2634983113 From dholmes at openjdk.org Wed Feb 5 01:12:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Feb 2025 01:12:31 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:42:42 GMT, Jiangli Zhou wrote: >>> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup! >> >> A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM). >> >> So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway. > >> A static build isn't really suitable for custom launchers (or anything that embeds a VM). > > Just want to provide some relevant data point. We build custom launcher and statically link with the libjvm (for hermetic case). If libjvm is statically linked with the launcher, then there's actually no need to change the direct calls to those JNI_ functions. The direct calls are not problematic on static build. > >> An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. > > The alternative also sounds reasonable to me. We could skip running on static JDK if a test explicitly requires libjvm.so, libjava.so, etc at runtime, at least initially. > >> At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway. > > That's a good point. We can add a `vm.static.jdk` to help test selection. Thanks for clarifying @jianglizhou . Okay so the issue is only with the top-level invocation API functions: - JNI_GetDefaultJavaVMInitArgs - JNI_GetCreatedJavaVMs - JNI_CreateJavaVM and as noted launchers have the choice of either linking with libjvm.so or else using dynamic lookup. The former doesn't work with a static JDK (can we link with libjvm.a?). So in the context of fixing a couple of tests this is okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635480736 From dholmes at openjdk.org Wed Feb 5 01:15:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Feb 2025 01:15:29 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou wrote: > Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635483683 From jiangli at openjdk.org Wed Feb 5 03:07:14 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 5 Feb 2025 03:07:14 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. > - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: > - JNI_GetDefaultJavaVMInitArgs > - JNI_GetCreatedJavaVMs > - JNI_CreateJavaVM > > On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. > > For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. > > TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. I want to answer the question carefully to avoid possible confusions, so the comment below may provide extra information (also verbose) than just addressing the question. Please let me know if anything is unclear. > and as noted launchers have the choice of either linking with libjvm.so or else using dynamic lookup. The former doesn't work with a static JDK (can we link with libjvm.a?). Yes. A launcher executable can explicitly link with a native library, either using .so (shared library) or .a (static library) if the launcher code has any direct references to symbols defined in the native library. The launcher can also choose to do dynamic symbol lookup and avoids the need for explicitly linking with the native library. If a launcher executable is linked with libjvm.so at build time, it requires libjvm.so to be resolved (normally from the RPATH) and loaded successfully when the launcher executable is loaded. Otherwise the executable fails to load and start due to the missing libjvm.so dependency. If a launcher executable is statically linked with libjvm.a, runtime does not try to find the libjvm.a since that is already built into the executable. Same for a shared library (e.g. the libatExit.so used by the test) linked with libjvm.so, the shared library fails to be loaded if libjvm.so do not present at runtime. If launcher code choose to use dynamic symbol lookup and avoids linking with libjvm.so, the launcher code can support both dynamic case and static case. The `java` launcher does that. > So in the context of fixing a couple of tests this is okay. Yeah, since there are just few cases in the tests, I feel fixing these tests seem to be a good choice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635599602 From jiangli at openjdk.org Wed Feb 5 04:02:13 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 5 Feb 2025 04:02:13 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: <9sSVmY9slBPQpeUstbjzS7VurCl-ADBk5qYuu_oe20c=.c1159ed4-9f45-42fa-86e0-3e011279c114@github.com> On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes wrote: > > Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > > Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard. Other possible examples could be running the test on different JVM implementation (e.g. non-hotspot) that does not have libjvm.so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635649103 From stuefe at openjdk.org Wed Feb 5 07:27:10 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 5 Feb 2025 07:27:10 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Tue, 4 Feb 2025 20:23:57 GMT, Alex Menkov wrote: >> src/hotspot/share/services/attachListener.cpp line 139: >> >>> 137: } >>> 138: } else { >>> 139: /* TODO: handle buffer overflow >> >> Important `TODO` :-). > > This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307) > @tstuefe Do you want to keep this comment to work on JDK-8319307? You can remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1942361508 From azafari at openjdk.org Wed Feb 5 09:45:20 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 5 Feb 2025 09:45:20 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> Message-ID: On Tue, 4 Feb 2025 13:43:46 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in shendoahCardTable > > test/micro/org/openjdk/bench/vm/compiler/FluidSBBench.java line 1: > >> 1: /* > > This must be the result of an incorrect merge conflict resolution. It should be deleted. The file is deleted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1942544444 From azafari at openjdk.org Wed Feb 5 09:53:25 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 5 Feb 2025 09:53:25 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> Message-ID: On Tue, 4 Feb 2025 13:48:58 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in shendoahCardTable > > test/hotspot/gtest/nmt/test_vmatree.cpp line 831: > >> 829: tty->cr(); >> 830: } >> 831: } > > This looks like a test which was added when you merged in an earlier version of https://github.com/openjdk/jdk/pull/20994 > > This should be removed. Done. > test/hotspot/jtreg/compiler/stringopts/TestFluidAndNonFluid.java line 1: > >> 1: /* > > Incorrect merge resolution. Removed the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1942555378 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1942556962 From azafari at openjdk.org Wed Feb 5 10:38:21 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 5 Feb 2025 10:38:21 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> Message-ID: On Tue, 4 Feb 2025 13:44:52 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in shendoahCardTable > > test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java line 182: > >> 180: throw new RuntimeException("Expected a higher delta between stack committed of with and without pretouch." + >> 181: "Expected: " + expected_delta + " Actual: " + actual_delta); >> 182: } > > Is this meant to be part of this PR? Better and correct if not to. Changes are removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1942629076 From syan at openjdk.org Wed Feb 5 12:33:59 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 5 Feb 2025 12:33:59 GMT Subject: RFR: 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer Message-ID: Hi all, Test function `os_attempt_reserve_memory_between_combos_vm_Test::TestBody()` in "test/hotspot/gtest/runtime/test_os_reserve_between.cpp" file reported "applying non-zero offset 4096 to null pointer" by UndefinedBehaviorSanitizer. The var `min` cast from 0 to pointer and then apply non-zero offset `range_size` is undefined behavior. This PR cast pointer `min` to uintptr_t before add the offset `range_size`, and the cast back to pointer. This PR do not change the original logic but eliminate the undefined behaviour in code. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer Changes: https://git.openjdk.org/jdk/pull/23462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349465 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23462/head:pull/23462 PR: https://git.openjdk.org/jdk/pull/23462 From amitkumar at openjdk.org Wed Feb 5 14:07:28 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 5 Feb 2025 14:07:28 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 12:13:50 GMT, Coleen Phillimore wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. > > Thanks David and Johan for the reviews. Hi @coleenp, I am repeating the message from Theresa, since she is part of OpenJ9 and can't accept OpenJDK Terms: `serviceability/jvmti/RedefineClasses/RedefineVerifyError.java` I believe the correct behavior should be throwing a ClassFormatException since the generated class is not well formed. According to the JVM specification in section 4.7.3 The Code Attribute: If the method is either native or abstract, and is not a class or interface initialization method, then its method_info structure must not have a Code attribute in its attributes table. Otherwise, its method_info structure must have exactly one Code attribute in its attributes table. also The value of code_length must be greater than zero Can you clarify why VerifyError is expected to be caught here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2636942548 From pchilanomate at openjdk.org Wed Feb 5 15:57:15 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 5 Feb 2025 15:57:15 GMT Subject: RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed [v13] In-Reply-To: References: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> Message-ID: On Fri, 31 Jan 2025 21:43:02 GMT, Serguei Spitsyn wrote: >> Below is the root cause of the bug described by Patricio: >> The root of the issue is similar to [JDK-8345543](https://bugs.openjdk.org/browse/JDK-8345543), but instead of `JavaThreadBlockedOnMonitorEnterState`, the interaction here is with its equivalent for Object.wait, `JavaThreadInObjectWaitState`. >> >> We change the `Thread.State` of the carrier to `TIMED_WAITING` before we try preempting the `vthread`. So we can see the `Thread.State` of the vthread as `TIMED_WAITING` before even calling `try_preempt()` (when the state is `RUNNING` we return the `Thread.State` of the carrier). Then when we check for `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`, we caught the `vthread` in `afterYield()` still with the transitional state of `TIMED_WAITING`, which is mapped to `Thread.State.RUNNABLE`. >> >> The fix is to delay the state change to `JavaThreadStatus::IN_OBJECT_WAIT*` the point after block with the `try_preempt()` call. The fix is not elegant and hacky but I do not see a better solution. The ugliness comes from the fact that the `ObjectMonitor::wait()` is called from two places: `ObjectSynchronizer::wait()` and `ObjectSynchronizer::waitUninterruptibly()`. We do not need the `JavaThreadInObjectWaitState` in the second cases, so the object is defined in the `JVM_MonitorWait()` but not in the `ObjectMonitor::wait()`. >> Maybe, deep refactoring the`JavaThreadInObjectWaitState` base class `JavaThreadStatusChanger` could be a better solution but it is going to be much more intrusive. >> >> Testing: >> - Checked the failed test does not fail with the fix: `serviceability/jvmti/vthread/GetThreadState/GetThreadState.java` >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: better clarification in the comments Looks good to me. Hopefully we can simplify this in the future if we follow the path of 8347979. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23126#pullrequestreview-2596245410 From sspitsyn at openjdk.org Wed Feb 5 16:21:13 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Feb 2025 16:21:13 GMT Subject: RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed [v13] In-Reply-To: References: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> Message-ID: On Fri, 31 Jan 2025 21:43:02 GMT, Serguei Spitsyn wrote: >> Below is the root cause of the bug described by Patricio: >> The root of the issue is similar to [JDK-8345543](https://bugs.openjdk.org/browse/JDK-8345543), but instead of `JavaThreadBlockedOnMonitorEnterState`, the interaction here is with its equivalent for Object.wait, `JavaThreadInObjectWaitState`. >> >> We change the `Thread.State` of the carrier to `TIMED_WAITING` before we try preempting the `vthread`. So we can see the `Thread.State` of the vthread as `TIMED_WAITING` before even calling `try_preempt()` (when the state is `RUNNING` we return the `Thread.State` of the carrier). Then when we check for `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`, we caught the `vthread` in `afterYield()` still with the transitional state of `TIMED_WAITING`, which is mapped to `Thread.State.RUNNABLE`. >> >> The fix is to delay the state change to `JavaThreadStatus::IN_OBJECT_WAIT*` the point after block with the `try_preempt()` call. The fix is not elegant and hacky but I do not see a better solution. The ugliness comes from the fact that the `ObjectMonitor::wait()` is called from two places: `ObjectSynchronizer::wait()` and `ObjectSynchronizer::waitUninterruptibly()`. We do not need the `JavaThreadInObjectWaitState` in the second cases, so the object is defined in the `JVM_MonitorWait()` but not in the `ObjectMonitor::wait()`. >> Maybe, deep refactoring the`JavaThreadInObjectWaitState` base class `JavaThreadStatusChanger` could be a better solution but it is going to be much more intrusive. >> >> Testing: >> - Checked the failed test does not fail with the fix: `serviceability/jvmti/vthread/GetThreadState/GetThreadState.java` >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: better clarification in the comments Thank you for review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23126#issuecomment-2637351675 From sspitsyn at openjdk.org Wed Feb 5 16:21:14 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Feb 2025 16:21:14 GMT Subject: Integrated: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed In-Reply-To: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> References: <0vNhBxUeUU5PNGSXJsEYvf0G-G7kfqU2CPXLmjYFFfE=.7c07eabb-3a94-4eaa-b945-7c8e1d79524e@github.com> Message-ID: On Wed, 15 Jan 2025 08:15:40 GMT, Serguei Spitsyn wrote: > Below is the root cause of the bug described by Patricio: > The root of the issue is similar to [JDK-8345543](https://bugs.openjdk.org/browse/JDK-8345543), but instead of `JavaThreadBlockedOnMonitorEnterState`, the interaction here is with its equivalent for Object.wait, `JavaThreadInObjectWaitState`. > > We change the `Thread.State` of the carrier to `TIMED_WAITING` before we try preempting the `vthread`. So we can see the `Thread.State` of the vthread as `TIMED_WAITING` before even calling `try_preempt()` (when the state is `RUNNING` we return the `Thread.State` of the carrier). Then when we check for `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`, we caught the `vthread` in `afterYield()` still with the transitional state of `TIMED_WAITING`, which is mapped to `Thread.State.RUNNABLE`. > > The fix is to delay the state change to `JavaThreadStatus::IN_OBJECT_WAIT*` the point after block with the `try_preempt()` call. The fix is not elegant and hacky but I do not see a better solution. The ugliness comes from the fact that the `ObjectMonitor::wait()` is called from two places: `ObjectSynchronizer::wait()` and `ObjectSynchronizer::waitUninterruptibly()`. We do not need the `JavaThreadInObjectWaitState` in the second cases, so the object is defined in the `JVM_MonitorWait()` but not in the `ObjectMonitor::wait()`. > Maybe, deep refactoring the`JavaThreadInObjectWaitState` base class `JavaThreadStatusChanger` could be a better solution but it is going to be much more intrusive. > > Testing: > - Checked the failed test does not fail with the fix: `serviceability/jvmti/vthread/GetThreadState/GetThreadState.java` > - Ran mach5 tiers 1-6 This pull request has now been integrated. Changeset: b9b62a02 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/b9b62a02488ee9c1a5a7a9ede87505781dfc0f73 Stats: 51 lines in 3 files changed: 33 ins; 12 del; 6 mod 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/23126 From duke at openjdk.org Wed Feb 5 16:22:34 2025 From: duke at openjdk.org (duke) Date: Wed, 5 Feb 2025 16:22:34 GMT Subject: Withdrawn: 8343249: [Windows] Implement SpinPause In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 06:29:29 GMT, Julian Waters wrote: > SpinPause is currently not implemented on any Windows platforms, due to a lack of access to assembly in the Microsoft compiler. The YieldProcessor macro can act as a stand in for this purpose, as it compiles down to a single pause instruction on x64 (Which seems to be all that one needs to implement SpinPause in HotSpot). I am less certain about the Windows/ARM64 implementation. There, YieldProcessor compiles down to dmb ishst; yield and I am unsure whether that is a correct SpinPause implementation. If need be, I can retract the ARM64 implementation and only have this for x86 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21781 From amenkov at openjdk.org Wed Feb 5 20:11:53 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Feb 2025 20:11:53 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v2] In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: > The fix implements streaming output support for attach protocol. > See JBS issue for evaluation, summary of the changes in the 1st comment. > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23405/files - new: https://git.openjdk.org/jdk/pull/23405/files/052319f9..96d01f7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=00-01 Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405 PR: https://git.openjdk.org/jdk/pull/23405 From dholmes at openjdk.org Thu Feb 6 04:59:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 04:59:36 GMT Subject: RFR: 8349417: Fix NULL usage from JDK-8346433 Message-ID: Trivial replacement of NULL with nullptr Testing: Windows build Thanks ------------- Commit messages: - 8349417: Fix NULL usage from JDK-8346433 Changes: https://git.openjdk.org/jdk/pull/23483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349417 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23483/head:pull/23483 PR: https://git.openjdk.org/jdk/pull/23483 From dholmes at openjdk.org Thu Feb 6 07:03:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 07:03:19 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 14:04:18 GMT, Amit Kumar wrote: >> Thanks David and Johan for the reviews. > > Hi @coleenp, > > I am repeating the message from Theresa, since she is part of OpenJ9 and can't accept OpenJDK Terms: > > > `serviceability/jvmti/RedefineClasses/RedefineVerifyError.java` I believe the correct behavior should be throwing a ClassFormatException since the generated class is not well formed. > > According to the JVM specification in section 4.7.3 The Code Attribute: > > If the method is either native or abstract, and is not a class or interface > initialization method, then its method_info structure must not have a Code attribute > in its attributes table. Otherwise, its method_info structure must have exactly > one Code attribute in its attributes table. > also > The value of code_length must be greater than zero > > Can you clarify why VerifyError is expected to be caught here? Hi Amit (@offamitkumar ), I think the answer to that is already given above: https://github.com/openjdk/jdk/pull/22116#discussion_r1850265592 > The JVMTI code for redefinition returns JVMTI_ERROR_FAILS_VERIFICATION and not the pending exception to the caller. The agent eventually in java.instrument/share/native/libinstrument/JavaExceptions.c will recreate the VerifyError based on the JVMTI error code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2638992732 From ccheung at openjdk.org Thu Feb 6 07:22:53 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 6 Feb 2025 07:22:53 GMT Subject: RFR: 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output Message-ID: The `TestParallelGCWithCDS.java` test runs with small max heap and failed intermittently due to the expected output is missing. Instead of keep adding the expected output, the fix is just check that the JVM hasn't crashed. Also updating the `TestSerialGCWithCDS.java` test with similar fix. Passed tier3 testing. ------------- Commit messages: - 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output Changes: https://git.openjdk.org/jdk/pull/23485/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349508 Stats: 15 lines in 2 files changed: 0 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23485/head:pull/23485 PR: https://git.openjdk.org/jdk/pull/23485 From chagedorn at openjdk.org Thu Feb 6 07:29:09 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 6 Feb 2025 07:29:09 GMT Subject: RFR: 8349417: Fix NULL usage from JDK-8346433 In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 04:55:25 GMT, David Holmes wrote: > Trivial replacement of NULL with nullptr > > Testing: Windows build > > Thanks Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23483#pullrequestreview-2597859404 From dholmes at openjdk.org Thu Feb 6 07:35:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 07:35:15 GMT Subject: RFR: 8349417: Fix NULL usage from JDK-8346433 In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 07:26:24 GMT, Christian Hagedorn wrote: >> Trivial replacement of NULL with nullptr >> >> Testing: Windows build >> >> Thanks > > Looks good and trivial. Thanks for the review @chhagedorn ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23483#issuecomment-2639039506 From dholmes at openjdk.org Thu Feb 6 07:35:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 07:35:16 GMT Subject: Integrated: 8349417: Fix NULL usage from JDK-8346433 In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 04:55:25 GMT, David Holmes wrote: > Trivial replacement of NULL with nullptr > > Testing: Windows build > > Thanks This pull request has now been integrated. Changeset: 30f71622 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/30f71622a1c86e297bf6d4b24d90e7531a0f19c2 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8349417: Fix NULL usage from JDK-8346433 Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/23483 From dholmes at openjdk.org Thu Feb 6 08:17:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 08:17:09 GMT Subject: RFR: 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 07:17:28 GMT, Calvin Cheung wrote: > The `TestParallelGCWithCDS.java` test runs with small max heap and failed intermittently due to the expected output is missing. Instead of keep adding the expected output, the fix is just check that the JVM hasn't crashed. Also updating the `TestSerialGCWithCDS.java` test with similar fix. > > Passed tier3 testing. Seems reasonable. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23485#pullrequestreview-2597946032 From syan at openjdk.org Thu Feb 6 09:33:19 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 6 Feb 2025 09:33:19 GMT Subject: [jdk24] Withdrawn: 8322983: Virtual Threads: exclude 2 tests In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 01:51:51 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [cf28fd4c](https://github.com/openjdk/jdk/commit/cf28fd4cbc6507eb69fcfeb33622316eb5b6b0c5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Evgeny Nikitin on 20 Dec 2024 and was reviewed by Jaikiran Pai, Leonid Mesnik and SendaoYan. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22872 From sspitsyn at openjdk.org Thu Feb 6 10:50:30 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Feb 2025 10:50:30 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected Message-ID: The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspend Thread()` and others are returned. For instance, some `SingleStep` events can be posted. The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. Testing: - Ran mach5 tiers 1-6 ------------- Commit messages: - 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected Changes: https://git.openjdk.org/jdk/pull/23490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316397 Stats: 22 lines in 2 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490 PR: https://git.openjdk.org/jdk/pull/23490 From mdoerr at openjdk.org Thu Feb 6 12:08:13 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 6 Feb 2025 12:08:13 GMT Subject: RFR: 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer In-Reply-To: References: Message-ID: <5f0GqaR8RsFCcesSqmBm7g7iWHaWpJIV3b0T7ELQZOc=.31430d86-1e86-4e81-ad9d-8863e3a959c3@github.com> On Wed, 5 Feb 2025 12:29:23 GMT, SendaoYan wrote: > Hi all, > Test function `os_attempt_reserve_memory_between_combos_vm_Test::TestBody()` in "test/hotspot/gtest/runtime/test_os_reserve_between.cpp" file reported "applying non-zero offset 4096 to null pointer" by UndefinedBehaviorSanitizer. The var `min` cast from 0 to pointer and then apply non-zero offset `range_size` is undefined behavior. > > This PR cast pointer `min` to uintptr_t before add the offset `range_size`, and the cast back to pointer. This solution similar to [JDK-8346714](https://github.com/openjdk/jdk/pull/22848). This PR do not change the original logic but eliminate the undefined behaviour in code. > > Change has been verified locally, test-fix only, no risk. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23462#pullrequestreview-2598481293 From amitkumar at openjdk.org Thu Feb 6 13:25:13 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 6 Feb 2025 13:25:13 GMT Subject: RFR: 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:29:23 GMT, SendaoYan wrote: > Hi all, > Test function `os_attempt_reserve_memory_between_combos_vm_Test::TestBody()` in "test/hotspot/gtest/runtime/test_os_reserve_between.cpp" file reported "applying non-zero offset 4096 to null pointer" by UndefinedBehaviorSanitizer. The var `min` cast from 0 to pointer and then apply non-zero offset `range_size` is undefined behavior. > > This PR cast pointer `min` to uintptr_t before add the offset `range_size`, and the cast back to pointer. This solution similar to [JDK-8346714](https://github.com/openjdk/jdk/pull/22848). This PR do not change the original logic but eliminate the undefined behaviour in code. > > Change has been verified locally, test-fix only, no risk. Marked as reviewed by amitkumar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23462#pullrequestreview-2598660609 From syan at openjdk.org Thu Feb 6 15:04:14 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 6 Feb 2025 15:04:14 GMT Subject: Integrated: 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:29:23 GMT, SendaoYan wrote: > Hi all, > Test function `os_attempt_reserve_memory_between_combos_vm_Test::TestBody()` in "test/hotspot/gtest/runtime/test_os_reserve_between.cpp" file reported "applying non-zero offset 4096 to null pointer" by UndefinedBehaviorSanitizer. The var `min` cast from 0 to pointer and then apply non-zero offset `range_size` is undefined behavior. > > This PR cast pointer `min` to uintptr_t before add the offset `range_size`, and the cast back to pointer. This solution similar to [JDK-8346714](https://github.com/openjdk/jdk/pull/22848). This PR do not change the original logic but eliminate the undefined behaviour in code. > > Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: 3fbae32d Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/3fbae32d0a9dbe612d4170e135a813c114fdcec2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer Reviewed-by: mdoerr, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/23462 From syan at openjdk.org Thu Feb 6 15:04:13 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 6 Feb 2025 15:04:13 GMT Subject: RFR: 8349465: [UBSAN] test_os_reserve_between.cpp reported applying non-zero offset to null pointer In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:29:23 GMT, SendaoYan wrote: > Hi all, > Test function `os_attempt_reserve_memory_between_combos_vm_Test::TestBody()` in "test/hotspot/gtest/runtime/test_os_reserve_between.cpp" file reported "applying non-zero offset 4096 to null pointer" by UndefinedBehaviorSanitizer. The var `min` cast from 0 to pointer and then apply non-zero offset `range_size` is undefined behavior. > > This PR cast pointer `min` to uintptr_t before add the offset `range_size`, and the cast back to pointer. This solution similar to [JDK-8346714](https://github.com/openjdk/jdk/pull/22848). This PR do not change the original logic but eliminate the undefined behaviour in code. > > Change has been verified locally, test-fix only, no risk. Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23462#issuecomment-2640069793 From azafari at openjdk.org Thu Feb 6 15:51:41 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 6 Feb 2025 15:51:41 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed merge problems ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/a0d133f9..873d5355 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=19-20 Stats: 284 lines in 7 files changed: 0 ins; 270 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From coleenp at openjdk.org Thu Feb 6 18:44:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 6 Feb 2025 18:44:23 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> >> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. Thanks for answering David. The new class should get a VerifyError not a ClassFormatError - the bytecodes were incorrect, as detected by the verifier. It's not missing a code attribute but the code is truncated as reported with -Xlog:exceptions: [0.339s][info][exceptions] Exception ()V @0: [ ] Reason: [ ] Error exists in the bytecode [ ] Bytecode: [ ] 0000000: [ ] > (0x00000007ff8850c8) [ ] thrown [/scratch/cphillim/hg/jdk-ci-pd/open/src/hotspot/share/classfile/verifier.cpp, line 293] [ ] for thread 0x000075ea2cbbe260 In the test the methods are here just don't have anything in them: { methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "", "()V", null, null); methodVisitor.visitCode(); methodVisitor.visitEnd(); } { methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "", "(Ljava/lang/String;)V", null, null); methodVisitor.visitCode(); classWriter.visitEnd(); } So VerifyError is the right exception. It might be that you need to add some nop() bytecode or something to generate the code attribute? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2640709606 From azafari at openjdk.org Thu Feb 6 18:58:24 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 6 Feb 2025 18:58:24 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Tue, 4 Feb 2025 13:56:50 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in shendoahCardTable > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2013, 2025, Oracle and/or its affiliates. All rights reserved. > > Weird, another copyright issue here Fixed. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > Incorrect copyright addition. Fixed. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 27: > >> 25: >> 26: #ifndef NMT_VIRTUALMEMORYTRACKER_HPP >> 27: #define NMT_VIRTUALMEMORYTRACKER_HPP > > This shouldn't be changed??? Done. > src/hotspot/share/nmt/vmatree.cpp line 81: > >> 79: stA.out.set_tag(tag); >> 80: LEQ_A.state.out.set_tag(tag); >> 81: stB.in.set_tag(tag); > > Commented out assert and an addition I'm trying to wrap my head around. Does this fix a pre-existing bug? If so, this should be a separate PR for mainline before this PR is integrated. Removed the commented out line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1945265638 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1945265403 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1945265243 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1945265068 From sspitsyn at openjdk.org Thu Feb 6 19:09:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Feb 2025 19:09:11 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v2] In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: On Wed, 5 Feb 2025 20:11:53 GMT, Alex Menkov wrote: >> The fix implements streaming output support for attach protocol. >> See JBS issue for evaluation, summary of the changes in the 1st comment. >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 70: > 68: > 69: private static void attach(LingeredApp app, boolean clientStreaming, boolean vmStreaming) throws Exception { > 70: HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid())); Q: It is confusing that both boolean arguments are not used. Would you like to get rid of them? test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 86: > 84: > 85: private static void verify(boolean clientStreaming, boolean vmStreaming, String out) throws Exception { > 86: System.out.println("Target VM output:"); Q: It is confusing that the boolean argument vmStreaming is not used. Would you like to get rid of it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945156555 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945158080 From naoto at openjdk.org Thu Feb 6 19:51:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 6 Feb 2025 19:51:21 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables Message-ID: This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349254 Stats: 137 lines in 3 files changed: 68 ins; 45 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/23498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498 PR: https://git.openjdk.org/jdk/pull/23498 From amenkov at openjdk.org Thu Feb 6 20:23:32 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 6 Feb 2025 20:23:32 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v3] In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com> > The fix implements streaming output support for attach protocol. > See JBS issue for evaluation, summary of the changes in the 1st comment. > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback - test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23405/files - new: https://git.openjdk.org/jdk/pull/23405/files/96d01f7c..d074f2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=01-02 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405 PR: https://git.openjdk.org/jdk/pull/23405 From jiangli at openjdk.org Thu Feb 6 20:26:16 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 6 Feb 2025 20:26:16 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes wrote: >> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > >> Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > > Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard. @dholmes-ora and @AlanBateman Could you please review and approve the change if there's no additional concerns? I also sent out https://github.com/openjdk/jdk/pull/23500, which applies the same principle to fix libExplicitAttach issue. I'm also in the process of adding the VMProps for static JDK as @AlanBateman suggested. That's needed to skip the tests require accessing tools in `bin/`, until we have a clear story on the tools support for static JDK/hermetic Java (that topic has been brought up in the hermetic Java meetings). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2640918286 From iklam at openjdk.org Thu Feb 6 20:57:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 6 Feb 2025 20:57:16 GMT Subject: RFR: 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 07:17:28 GMT, Calvin Cheung wrote: > The `TestParallelGCWithCDS.java` test runs with small max heap and failed intermittently due to the expected output is missing. Instead of keep adding the expected output, the fix is just check that the JVM hasn't crashed. Also updating the `TestSerialGCWithCDS.java` test with similar fix. > > Passed tier3 testing. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23485#pullrequestreview-2599909386 From jsjolen at openjdk.org Thu Feb 6 21:24:25 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 6 Feb 2025 21:24:25 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions Message-ID: Hi, Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. ```c++ static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); Thanks. ------------- Commit messages: - Don't use address, use void* Changes: https://git.openjdk.org/jdk/pull/23497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349580 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23497/head:pull/23497 PR: https://git.openjdk.org/jdk/pull/23497 From gziemski at openjdk.org Thu Feb 6 22:07:15 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 6 Feb 2025 22:07:15 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:11:09 GMT, Johan Sj?len wrote: > Hi, > > Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. > > ```c++ > static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); > > > Thanks. Changes requested by gziemski (Reviewer). src/hotspot/share/nmt/memTracker.hpp line 142: > 140: if (!enabled()) return; > 141: if (addr != nullptr) { > 142: VirtualMemoryTracker::remove_released_region((address)addr, size); What about here? ------------- PR Review: https://git.openjdk.org/jdk/pull/23497#pullrequestreview-2600104431 PR Review Comment: https://git.openjdk.org/jdk/pull/23497#discussion_r1945539268 From ccheung at openjdk.org Thu Feb 6 22:37:15 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 6 Feb 2025 22:37:15 GMT Subject: RFR: 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 08:14:18 GMT, David Holmes wrote: >> The `TestParallelGCWithCDS.java` test runs with small max heap and failed intermittently due to the expected output is missing. Instead of keep adding the expected output, the fix is just check that the JVM hasn't crashed. Also updating the `TestSerialGCWithCDS.java` test with similar fix. >> >> Passed tier3 testing. > > Seems reasonable. > > Thanks Thanks @dholmes-ora, @iklam for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23485#issuecomment-2641271380 From ccheung at openjdk.org Thu Feb 6 22:37:15 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 6 Feb 2025 22:37:15 GMT Subject: Integrated: 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 07:17:28 GMT, Calvin Cheung wrote: > The `TestParallelGCWithCDS.java` test runs with small max heap and failed intermittently due to the expected output is missing. Instead of keep adding the expected output, the fix is just check that the JVM hasn't crashed. Also updating the `TestSerialGCWithCDS.java` test with similar fix. > > Passed tier3 testing. This pull request has now been integrated. Changeset: a0c7f661 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/a0c7f661bedaf50b22cf83c798be46e8e5004b60 Stats: 15 lines in 2 files changed: 0 ins; 12 del; 3 mod 8349508: runtime/cds/appcds/TestParallelGCWithCDS.java should not check for specific output Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.org/jdk/pull/23485 From syan at openjdk.org Fri Feb 7 02:29:30 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 02:29:30 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer Message-ID: Hi all, Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. This PR change the type of var `hi_end` from `char*` to `size_t` will eliminate the undefined behaviour, and do not change the original logic. Risk is low. Additional testing: - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 ------------- Commit messages: - 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer Changes: https://git.openjdk.org/jdk/pull/23508/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23508&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349554 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23508/head:pull/23508 PR: https://git.openjdk.org/jdk/pull/23508 From amenkov at openjdk.org Fri Feb 7 02:41:22 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Feb 2025 02:41:22 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v3] In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Tue, 4 Feb 2025 10:10:41 GMT, Johan Sj?len wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback - test > > src/hotspot/share/services/attachListener.cpp line 53: > >> 51: >> 52: // Stream for printing attach operation results. >> 53: // Supports buffered and streaming output for commands which can produce lenghtly reply. > > "lengthy" Fixed > src/hotspot/share/services/attachListener.cpp line 56: > >> 54: // >> 55: // To support streaming output platform implementation need to implement AttachOperation::get_reply_writer() method >> 56: // and ctor allow_streaming argument should be set to true. > > Strange mix of "need" and "should". > > Can we split this into multiple sentences? Here's a suggestion, though I'm not sure if it's 100% correct :-). > > > An output platform implementation supports streaming if it implements AttachOperation::get_reply_writer(). > Streaming is enabled if the allow_streaming in the constructor is set to true. Updated the comment > src/hotspot/share/services/diagnosticFramework.cpp line 389: > >> 387: int count = 0; >> 388: while (iter.has_next()) { >> 389: if(_source == DCmd_Source_MBean && count > 0) { > > Pre-existing style: Space between `if` and condition missing. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879751 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879963 PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879828 From amenkov at openjdk.org Fri Feb 7 02:41:22 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Feb 2025 02:41:22 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v3] In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Wed, 5 Feb 2025 07:24:29 GMT, Thomas Stuefe wrote: >> This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307) >> @tstuefe Do you want to keep this comment to work on JDK-8319307? > > You can remove it. Removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945880034 From amenkov at openjdk.org Fri Feb 7 02:41:22 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Feb 2025 02:41:22 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v2] In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: On Thu, 6 Feb 2025 17:34:01 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 70: > >> 68: >> 69: private static void attach(LingeredApp app, boolean clientStreaming, boolean vmStreaming) throws Exception { >> 70: HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid())); > > Q: It is confusing that both boolean arguments are not used. Would you like to get rid of them? Dropped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945880212 From amenkov at openjdk.org Fri Feb 7 02:44:36 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Feb 2025 02:44:36 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v2] In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> Message-ID: On Thu, 6 Feb 2025 17:35:08 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 86: > >> 84: >> 85: private static void verify(boolean clientStreaming, boolean vmStreaming, String out) throws Exception { >> 86: System.out.println("Target VM output:"); > > Q: It is confusing that the boolean argument vmStreaming is not used. Would you like to get rid of it? Added verification for expected value. Also updated logging and verification of clientStreaming to not fail on AIX (AIX does not support streaming output yet as I don't have an environment to test it) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945881941 From syan at openjdk.org Fri Feb 7 07:06:20 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 07:06:20 GMT Subject: RFR: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm fails Message-ID: Hi all, The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not. On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`. Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress. #include #include int main() { struct mallinfo info; info = mallinfo(); printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost); char* ptr = malloc(0x10000); info = mallinfo(); printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost); free(ptr); return 0; } - Without -fsanitize=address, mallinfo() works normally. gcc mallinfo.c && ./a.out 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920 - With -fsanitize=address, mallinfo() works abnormally. gcc -fsanitize=address mallinfo.c && ./a.out 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ------------- Commit messages: - 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm fails Changes: https://git.openjdk.org/jdk/pull/23510/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349623 Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23510/head:pull/23510 PR: https://git.openjdk.org/jdk/pull/23510 From stefank at openjdk.org Fri Feb 7 08:32:10 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 08:32:10 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:11:09 GMT, Johan Sj?len wrote: > Hi, > > Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. > > ```c++ > static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); > > > Thanks. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23497#pullrequestreview-2601101995 From stefank at openjdk.org Fri Feb 7 08:53:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 08:53:11 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 02:25:10 GMT, SendaoYan wrote: > Hi all, > > Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. > > This PR change the type of var `hi_end` from `char*` to `size_t` will eliminate the undefined behaviour, and do not change the original logic. Risk is low. > > Additional testing: > > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 I'm not convinced that this is the nicest way to fix the issue. This change now makes it so that some of the addresses are typed as pointers and `hi_end` is typed as an integer. When doing these kind of changes I think it is important to take a step back and think about the types and see if there are ways to make them consistent in the changed functions. I wonder if a change like: - if ((uintptr_t)hi_end < bytes) { + if ((uintptr_t)hi_end <= bytes) { Would silence the compiler as well? Given that it would filter away the problematic case that leads to a null pointer. But even that compares an address with a range, which is also unfortunate (IMHO). So, I think it would be nicer to extract the max range and use that in the comparison: uintptr_t max_range = hi_end - nullptr; if (max_range <= bytes) { Just to be a bit cleaner with the types. Or maybe even use the lowest attach point instead of nullptr: uintptr_t max_range = hi_end - lo_att; if (max_range < bytes) { and then we can keep `<` instead of `<=` because `hi_end - bytes` will then not evaluate to null. ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23508#pullrequestreview-2601143572 From jsjolen at openjdk.org Fri Feb 7 09:10:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 7 Feb 2025 09:10:11 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 22:03:54 GMT, Gerard Ziemski wrote: >> Hi, >> >> Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. >> >> ```c++ >> static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); >> >> >> Thanks. > > src/hotspot/share/nmt/memTracker.hpp line 142: > >> 140: if (!enabled()) return; >> 141: if (addr != nullptr) { >> 142: VirtualMemoryTracker::remove_released_region((address)addr, size); > > What about here? Hi, That's correct as VMT does take `address`, whilst the external API takes "regular" pointers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23497#discussion_r1946200788 From jsjolen at openjdk.org Fri Feb 7 10:40:22 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 7 Feb 2025 10:40:22 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> On Thu, 6 Feb 2025 15:51:41 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed merge problems More things to be removed. src/hotspot/share/nmt/vmatree.hpp line 215: > 213: tty->print_cr("Flag %s R: " INT64_FORMAT " C: " INT64_FORMAT, NMTUtil::tag_to_enum_name((MemTag)i), tag[i].reserve, tag[i].commit); > 214: } > 215: } This can be removed src/hotspot/share/nmt/vmatree.hpp line 267: > 265: }); > 266: tty->cr(); > 267: } This can be removed, I'm rather sure(?) src/hotspot/share/opto/stringopts.cpp line 173: > 171: } > 172: void add_control(Node* ctrl) { > 173: assert(!_control.contains(ctrl), "only push once"); Remove the changes in this file. src/hotspot/share/opto/stringopts.hpp line 1: > 1: /* Remove the changes in this file. test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp line 46: > 44: EXPECT_EQ(file->_summary.by_tag(mtTest)->committed(), sz(100)); > 45: tracker.free_memory(file, 50, 10); > 46: EXPECT_EQ(file->_summary.by_tag(mtTest)->committed(), sz(90)); This change should be done in mainline, not in this PR. test/hotspot/gtest/nmt/test_nmt_treap.cpp line 238: > 236: EXPECT_LE(unexpected_count, REPEATS / 2) << "SSL Avg: " << sll_sum / REPEATS << " Treap Avg: " << treap_sum / REPEATS; > 237: } > 238: These can be removed. We shouldn't have performance benchmarks running on tier1, as they'll use unnecessary CPU and time. We're also removing the treap in favour of the RB-tree soon :-). ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2601371143 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946317189 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946316910 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946316278 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946315914 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946309823 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1946313782 From syan at openjdk.org Fri Feb 7 11:04:09 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 11:04:09 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 08:50:22 GMT, Stefan Karlsson wrote: > Would silence the compiler - if ((uintptr_t)hi_end < bytes) { + if ((uintptr_t)hi_end <= bytes) { Yes. > Or maybe even use the lowest attach point instead of nullptr: uintptr_t max_range = hi_end - lo_att; if (max_range < bytes) { `hi_end` less than `lo_att` in some cases, `hi_end - lo_att` subtraction will overflow, and save a bigger value to `max_range`, so `if (max_range < bytes)` return false. Should we change like below: - if ((uintptr_t)hi_end < bytes) { + uintptr_t max_range = hi_end - lo_att; + if (max_range < bytes || hi_end < lo_att) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2642598127 From stefank at openjdk.org Fri Feb 7 12:54:09 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 12:54:09 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 11:01:29 GMT, SendaoYan wrote: > `hi_end` less than `lo_att` in some cases Do you know if that only happens in our tests and not in normal JVM runs? If it is only in testing then it would be preferable to add preconditions to the function and then fix the testing to adhere to the preconditions. With that said, an easy fix would be to just continue the tradition of the function and have early returns when this happens: if (hi_end < lo_att) { return nullptr; // no need to go on } uintptr_t max_range = hi_end - lo_att; if (max_range < bytes) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2642831766 From syan at openjdk.org Fri Feb 7 13:14:09 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 13:14:09 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: <0KO0hLhNnZAVa1LTbJS4hjZrEPtp74qD7n6chgQPzYE=.c441f83b-880f-459d-bab2-4151a18ceb15@github.com> On Fri, 7 Feb 2025 12:51:42 GMT, Stefan Karlsson wrote: > > `hi_end` less than `lo_att` in some cases > > Do you know if that only happens in our tests and not in normal JVM runs? It happens in normal JVM runs. The command is: build/linux-x86_64-server-slowdebug/images/jdk/bin/java -Xlog:os+map=trace -Xshare:dump -XX:SharedArchiveFile=build/linux-x86_64-server-slowdebug/images/jdk/lib/server/classes_nocoops_coh.jsa -server -XX:-UseCompressedOops -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xmx128M -Xms128M -XX:+UseG1GC The output snippet: [0.020s][debug][os,map] reserve_between (range [0x0000000000000000-0x0000000000400000), size 0x40000000, alignment 0x1000000, randomize: 1) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2642870928 From jpai at openjdk.org Fri Feb 7 13:20:11 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Feb 2025 13:20:11 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. src/java.base/share/native/libjli/args.c line 479: > 477: jboolean ret = JNI_FALSE; > 478: > 479: if (firstAppArgIndex != 0 && // If not 'java', return Hello Naoto, this is a pre-existing thing, but since we are changing this part of the code, I think the checks for `firstAppArgIndex` and `relaunch` can be moved before the call to `getenv()` (and now before `winGetEnv()` too) since the syscall to `getenv()` wasn't anyway changing the state of `firstAppArgIndex` or `relaunch`. I think doing those checks before the call to fetch the env value will simplify the conditional check here a bit, in terms of readability. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946511351 From jpai at openjdk.org Fri Feb 7 13:43:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Feb 2025 13:43:10 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. src/java.base/share/native/libjli/args.c line 472: > 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) { > 471: #ifdef _WIN32 > 472: char *env = winGetEnv(var_name); I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946542097 From jpai at openjdk.org Fri Feb 7 14:45:11 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Feb 2025 14:45:11 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. In (the Windows specific) `src/java.base/windows/native/libjli/cmdtoargs.c` there's an additional call to lookup (a different) `_JAVA_OPTIONS` environment variable through `getenv()` just to log out that environment variable's value. Should we replace that call to `getenv()` with `winGetEnv()` too? And on a more general note, should the calls to `getenv()` in the launcher's native code (for example, For example, the `getenv("CLASSPATH")`) be re-examined in context of this issue and have it replaced with this alternative? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2643130961 From syan at openjdk.org Fri Feb 7 15:06:09 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 15:06:09 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 08:50:22 GMT, Stefan Karlsson wrote: > But even that compares an address with a range, which is also unfortunate (IMHO). So, I think it would be nicer to extract the max range and use that in the comparison: > > ``` > uintptr_t max_range = hi_end - nullptr; > if (max_range <= bytes) { > ``` The expr `uintptr_t max_range = hi_end - nullptr;` will case gcc/ckang report compiler error: "invalid operands to binary expression ('char *const' and 'std::nullptr_t')" So should change like: - if ((uintptr_t)hi_end < bytes) { + if ((uintptr_t)hi_end <= bytes) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2643190382 From jpai at openjdk.org Fri Feb 7 15:10:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Feb 2025 15:10:13 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v6] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest` The updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2601992489 From stefank at openjdk.org Fri Feb 7 15:41:19 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 15:41:19 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 02:25:10 GMT, SendaoYan wrote: > Hi all, > > Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. > > This PR change the type of var `hi_end` from `char*` to `size_t` will eliminate the undefined behaviour, and do not change the original logic. Risk is low. > > Additional testing: > > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 Sure. Let's leave any potential type cleanups for the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2643270582 From gziemski at openjdk.org Fri Feb 7 15:48:14 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 7 Feb 2025 15:48:14 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 09:07:45 GMT, Johan Sj?len wrote: >> src/hotspot/share/nmt/memTracker.hpp line 142: >> >>> 140: if (!enabled()) return; >>> 141: if (addr != nullptr) { >>> 142: VirtualMemoryTracker::remove_released_region((address)addr, size); >> >> What about here? > > Hi, > > That's correct as VMT does take `address`, whilst the external API takes "regular" pointers. Hmm, looks weird. Are we planning on cleaning this up further up the chain then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23497#discussion_r1946738827 From gziemski at openjdk.org Fri Feb 7 15:48:13 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 7 Feb 2025 15:48:13 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:11:09 GMT, Johan Sj?len wrote: > Hi, > > Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. > > ```c++ > static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); > > > Thanks. LGTM ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23497#pullrequestreview-2602098317 From syan at openjdk.org Fri Feb 7 15:51:29 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 15:51:29 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer [v2] In-Reply-To: References: Message-ID: > Hi all, > > Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. > > This PR change the type of var `hi_end` from `char*` to `size_t` will eliminate the undefined behaviour, and do not change the original logic. Risk is low. > > Additional testing: > > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 > - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 SendaoYan has updated the pull request incrementally with one additional commit since the last revision: hi_end should not less or equals to bytes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23508/files - new: https://git.openjdk.org/jdk/pull/23508/files/8dca2b00..6430a35a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23508&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23508&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23508/head:pull/23508 PR: https://git.openjdk.org/jdk/pull/23508 From syan at openjdk.org Fri Feb 7 15:51:29 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 15:51:29 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 15:38:16 GMT, Stefan Karlsson wrote: > Sure. Let's leave any potential type cleanups for the future. Okey, PR has been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2643296386 From stuefe at openjdk.org Fri Feb 7 15:56:09 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Feb 2025 15:56:09 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 15:51:29 GMT, SendaoYan wrote: >> Hi all, >> >> Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. >> >> This PR change from `hi_end < bytes` to `hi_end <= bytes` will eliminate the undefined behaviour. Risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > hi_end should not less or equals to bytes. Good. Thanks for fixing this. @stefank thanks for looking at this. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23508#pullrequestreview-2602124927 From stefank at openjdk.org Fri Feb 7 16:14:15 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 16:14:15 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 15:51:29 GMT, SendaoYan wrote: >> Hi all, >> >> Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. >> >> This PR change from `hi_end < bytes` to `hi_end <= bytes` will eliminate the undefined behaviour. Risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > hi_end should not less or equals to bytes. Looks good. Thanks for fixing. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23508#pullrequestreview-2602167746 From stefank at openjdk.org Fri Feb 7 16:19:10 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 7 Feb 2025 16:19:10 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 15:51:29 GMT, SendaoYan wrote: >> Hi all, >> >> Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. >> >> This PR change from `hi_end < bytes` to `hi_end <= bytes` will eliminate the undefined behaviour. Risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-x64 >> - [ ] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > hi_end should not less or equals to bytes. The following is not a request to change your PR. It's merely an explanation of what I think could be done to this function to get rid of some of the comparisons of bytes/ranges with pointers: char* lower_limit = MAX2(min, absolute_min); char* upper_limit = MIN2(max, absolute_max); // Precondition check if (lower_limit >= upper_limit) { return nullptr; // no need to go on } // Calculate first attach points assert(alignment_adjusted < std::numeric_limits::max() - (uintptr_t)upper_limit, "overflow precondition"); char* const lo_att = align_up(lower_limit, alignment_adjusted); if (lo_att >= upper_limit) { // no attachment point within limits return nullptr; } if (bytes < size_t(upper_limit - lo_att)) { // no attachment point that can accommodate the request return nullptr; } // Now we are guaranteed to have an attachment point that can // accommodate the request char* hi_att = align_down(upper_limit - bytes, alignment_adjusted); assert(hi_att >= lo_att, "checked above"); This is completely untested ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2643376373 From duke at openjdk.org Fri Feb 7 18:14:12 2025 From: duke at openjdk.org (duke) Date: Fri, 7 Feb 2025 18:14:12 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated [v6] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote: >> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: >> >> >> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt >> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 >> 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt >> 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt >> 3574947 test/jdk/java/foreign/libTestDowncallStack.c >> 7128495 test/jdk/java/foreign/libTestUpcallStack.c >> >> >> **Other highlights:** >> >> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` >> - `test.lib.Asserts::assertFileContentsEqual` is added > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest` @vy Your change (at version 5e9b30f431676c714cf81b85846f16c58c0dcdf6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23401#issuecomment-2643664263 From naoto at openjdk.org Fri Feb 7 18:32:26 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Feb 2025 18:32:26 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v2] In-Reply-To: References: Message-ID: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23498/files - new: https://git.openjdk.org/jdk/pull/23498/files/48aa31a7..5a00388e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=00-01 Stats: 12 lines in 1 file changed: 9 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498 PR: https://git.openjdk.org/jdk/pull/23498 From naoto at openjdk.org Fri Feb 7 18:42:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Feb 2025 18:42:20 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v2] In-Reply-To: References: Message-ID: <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com> On Fri, 7 Feb 2025 13:41:03 GMT, Jaikiran Pai wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects review > > src/java.base/share/native/libjli/args.c line 472: > >> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) { >> 471: #ifdef _WIN32 >> 472: char *env = winGetEnv(var_name); > > I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS? The macro name is confusing, but `_WIN32` means Win32 API set and does not specify the target platform. This link (https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170) reads _WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined. So I believen `_WIN32` is correct here. > src/java.base/share/native/libjli/args.c line 479: > >> 477: jboolean ret = JNI_FALSE; >> 478: >> 479: if (firstAppArgIndex != 0 && // If not 'java', return > > Hello Naoto, this is a pre-existing thing, but since we are changing this part of the code, I think the checks for `firstAppArgIndex` and `relaunch` can be moved before the call to `getenv()` (and now before `winGetEnv()` too) since the syscall to `getenv()` wasn't anyway changing the state of `firstAppArgIndex` or `relaunch`. I think doing those checks before the call to fetch the env value will simplify the conditional check here a bit, in terms of readability. Thanks Jai. That is a good point. Moved those checks before winGetEnv(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946998326 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946998307 From naoto at openjdk.org Fri Feb 7 18:45:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Feb 2025 18:45:10 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables In-Reply-To: References: Message-ID: <6PQSLmZ9okO97NEKmvoiQBIO3y2Bq1mr1KeZOYIhHKU=.e0bb3458-2e39-45b8-9b13-1b9fee749b5a@github.com> On Fri, 7 Feb 2025 14:42:44 GMT, Jaikiran Pai wrote: > In (the Windows specific) `src/java.base/windows/native/libjli/cmdtoargs.c` there's an additional call to lookup (a different) `_JAVA_OPTIONS` environment variable through `getenv()` just to log out that environment variable's value. Should we replace that call to `getenv()` with `winGetEnv()` too? It is a debug code and simply log out the environment variables (as you pointed out), I think it is OK to leave it as it is. > And on a more general note, should the calls to `getenv()` in the launcher's native code (for example, For example, the `getenv("CLASSPATH")`) be re-examined in context of this issue and have it replaced with this alternative? I skimmed through all the `getenv()`s in the launcher, and I don't see other occurrences require this special handling. They all simply fails (as expected). I believe ones that are used for command line arguments are relevant in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2643714733 From jlu at openjdk.org Fri Feb 7 19:21:14 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 7 Feb 2025 19:21:14 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v2] In-Reply-To: References: Message-ID: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com> On Fri, 7 Feb 2025 18:32:26 GMT, Naoto Sato wrote: >> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects review Logic to get the UTF-16 string env value, and map back to a code page string looks good to me. All conversions are done with the `WC_NO_BEST_FIT_CHARS` flag, so indeed there should be no best-fit mappings done. All the failure checks on the return values of `MultiByteToWideChar` and `WideCharToMultiByte` look appropriate as well. I left a few comments. src/java.base/share/native/libjli/args.c line 603: > 601: /* > 602: * getenv() without best-fit mapping > 603: */ I think a quick comment that says something along the lines of env variable name: code page -> UTF-16 variable value : UTF-16 -> code page would be helpful to overview what is happening here. src/java.base/share/native/libjli/args.c line 611: > 609: LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t)); > 610: if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) { > 611: LPWSTR wcEnvVar = _wgetenv(wcVarName); Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API? I am also guessing it's the convention for Windows native code, although I'm not fully sure. test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32: > 30: * @requires (os.family == "windows") > 31: * @library /test/lib > 32: * @run junit DisableBestFitMappingTest I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included. ------------- PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2602530119 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947013548 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946999296 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947024510 From naoto at openjdk.org Fri Feb 7 20:05:49 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Feb 2025 20:05:49 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v3] In-Reply-To: References: Message-ID: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Reflects review - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars - Reflects review - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23498/files - new: https://git.openjdk.org/jdk/pull/23498/files/5a00388e..bf89fd40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=01-02 Stats: 6954 lines in 202 files changed: 2578 ins; 2754 del; 1622 mod Patch: https://git.openjdk.org/jdk/pull/23498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498 PR: https://git.openjdk.org/jdk/pull/23498 From naoto at openjdk.org Fri Feb 7 20:15:13 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Feb 2025 20:15:13 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v2] In-Reply-To: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com> References: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com> Message-ID: <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com> On Fri, 7 Feb 2025 18:53:40 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects review > > src/java.base/share/native/libjli/args.c line 603: > >> 601: /* >> 602: * getenv() without best-fit mapping >> 603: */ > > I think a quick comment that says something along the lines of > > > env variable name: code page -> UTF-16 > variable value : UTF-16 -> code page > > > would be helpful to overview what is happening here. Thanks. I modified the comment. > src/java.base/share/native/libjli/args.c line 611: > >> 609: LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t)); >> 610: if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) { >> 611: LPWSTR wcEnvVar = _wgetenv(wcVarName); > > Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API? I think the overhead is negligible. If we use the Get... function, we will need to allocate/deallocate the intermediate buffer, which will make the code complex. > test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32: > >> 30: * @requires (os.family == "windows") >> 31: * @library /test/lib >> 32: * @run junit DisableBestFitMappingTest > > I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included. I am not sure of this. Isn't it the issue in jtreg plugin? At least `make test TEST=...` will succeed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128400 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128384 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128439 From jlu at openjdk.org Fri Feb 7 22:49:11 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 7 Feb 2025 22:49:11 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote: >> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Reflects review > - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars > - Reflects review > - initial commit Looks good to me; reviewed CSR as well. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2603007217 From jlu at openjdk.org Fri Feb 7 22:49:12 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 7 Feb 2025 22:49:12 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v2] In-Reply-To: <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com> References: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com> <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com> Message-ID: On Fri, 7 Feb 2025 20:11:06 GMT, Naoto Sato wrote: >> src/java.base/share/native/libjli/args.c line 611: >> >>> 609: LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t)); >>> 610: if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) { >>> 611: LPWSTR wcEnvVar = _wgetenv(wcVarName); >> >> Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API? > > I think the overhead is negligible. If we use the Get... function, we will need to allocate/deallocate the intermediate buffer, which will make the code complex. OK, seems good to use `_wgetenv` then. >> test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32: >> >>> 30: * @requires (os.family == "windows") >>> 31: * @library /test/lib >>> 32: * @run junit DisableBestFitMappingTest >> >> I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included. > > I am not sure of this. Isn't it the issue in jtreg plugin? At least `make test TEST=...` will succeed. Oops, I thought the test would mark as "skipped" or something like that, but yes its a Windows only test, hence why it does not show up, duh. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947288085 PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947288095 From jiangli at openjdk.org Fri Feb 7 23:58:09 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 7 Feb 2025 23:58:09 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:04:22 GMT, Alan Bateman wrote: >> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > >> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup! > > A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM). > > So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway. @AlanBateman I created https://github.com/openjdk/jdk/pull/23528 for the VMProps change. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2644342524 From jpai at openjdk.org Sat Feb 8 07:18:17 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Feb 2025 07:18:17 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v3] In-Reply-To: <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com> References: <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com> Message-ID: On Fri, 7 Feb 2025 18:39:25 GMT, Naoto Sato wrote: >> src/java.base/share/native/libjli/args.c line 472: >> >>> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) { >>> 471: #ifdef _WIN32 >>> 472: char *env = winGetEnv(var_name); >> >> I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS? > > The macro name is confusing, but `_WIN32` means Win32 API set and does not specify the target platform. This link (https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170) reads > > > _WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined. > > > So I believe `_WIN32` is correct here. Thank you for that detail Naoto. I didn't realize `_WIN32` was a Windows standard macro - I was under the impression that it is defined by the JDK's build files and (like you noticed) even misunderstood it to be something else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947500611 From jpai at openjdk.org Sat Feb 8 07:18:17 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Feb 2025 07:18:17 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote: >> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Reflects review > - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars > - Reflects review > - initial commit The updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2603334817 From syan at openjdk.org Sat Feb 8 13:14:16 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 8 Feb 2025 13:14:16 GMT Subject: RFR: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 16:16:47 GMT, Stefan Karlsson wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> hi_end should not less or equals to bytes. > > The following is not a request to change your PR. It's merely an explanation of what I think could be done to this function to get rid of some of the comparisons of bytes/ranges with pointers: > > > char* lower_limit = MAX2(min, absolute_min); > char* upper_limit = MIN2(max, absolute_max); > > // Precondition check > if (lower_limit >= upper_limit) { > return nullptr; // no need to go on > } > > // Calculate first attach points > assert(alignment_adjusted < std::numeric_limits::max() - (uintptr_t)upper_limit, "overflow precondition"); > char* const lo_att = align_up(lower_limit, alignment_adjusted); > > if (lo_att >= upper_limit) { > // no attachment point within limits > return nullptr; > } > > if (bytes < size_t(upper_limit - lo_att)) { > // no attachment point that can accommodate the request > return nullptr; > } > > // Now we are guaranteed to have an attachment point that can > // accommodate the request > char* hi_att = align_down(upper_limit - bytes, alignment_adjusted); > assert(hi_att >= lo_att, "checked above"); > > > This is completely untested Thanks @stefank @tstuefe for the suggestions and reviews. The additional test has finish and no new failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23508#issuecomment-2645535307 From syan at openjdk.org Sat Feb 8 13:14:16 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 8 Feb 2025 13:14:16 GMT Subject: Integrated: 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 02:25:10 GMT, SendaoYan wrote: > Hi all, > > Function 'os::attempt_reserve_memory_between(char*, char*, size_t, size_t, bool)' 'src/hotspot/share/runtime/os.cpp' reported "runtime error: applying non-zero offset to non-null pointer 0x000000001000 produced null pointer" by address sanitizer. Gtest in function 'os_attempt_reserve_memory_between_combos_vm_Test::TestBody' at file test/hotspot/gtest/runtime/test_os_reserve_between.cpp call 'os::attempt_reserve_memory_between (min=0x0, max=0x1000, bytes=4096, alignment=4096, randomize=true)' trigger this failure. Before this PR, the pointer var `hi_end` get value from `max` 0x1000, and then apply offset `bytes`, and `max` equals `bytes`, thus address sanitizer report this failure. > > This PR change from `hi_end < bytes` to `hi_end <= bytes` will eliminate the undefined behaviour. Risk is low. > > Additional testing: > > - [x] jtreg tests(which include tier1/2/3 etc.) on linux-x64 > - [x] jtreg tests(which include tier1/2/3 etc.) on linux-aarch64 This pull request has now been integrated. Changeset: 8f6ccde9 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/8f6ccde9829ea0e4fe1c087e68bec4d9efb55c64 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8349554: [UBSAN] os::attempt_reserve_memory_between reported applying non-zero offset to non-null pointer produced null pointer Reviewed-by: stefank, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/23508 From kvn at openjdk.org Sun Feb 9 19:43:29 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sun, 9 Feb 2025 19:43:29 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 17:45:30 GMT, Vladimir Kozlov wrote: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp @dougxc and @tkrodriguez, please look if it affects Graal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2646553512 From kvn at openjdk.org Sun Feb 9 19:43:29 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sun, 9 Feb 2025 19:43:29 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix Zero and Minimal VM builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/11abd5e7..dda20f0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From cjplummer at openjdk.org Mon Feb 10 03:14:22 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Feb 2025 03:14:22 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero and Minimal VM builds I almost wished I hadn't looked because there is a lot of SA CodeBlob support that could use some cleanup. Most notably I think most of the wrapper subclasses are not needed by SA, and could be served by one common class. See what I'm doing in #23456 for JavaThread subclasses. Wrapper classes don't need to be 1-to-1 with the class type they are wrapping. A single wrapper class type can handle any number of hotspot types. It usually just make more sense for them to be 1-to-1, but when they are trivial and the implementation is replicated across subtypes, just having one wrapper class implement them all can simplify things. The other thing I noticed is a lot of the subtypes seem to be doing some unnecessary things like registering Observers, and they all do something like the following: 44 Type type = db.lookupType("BufferBlob"); Even when it never references "type". I'm not suggesting you clean up any of this now, but just pointed it out. I might file an issue and try to clean it up myself at some point. I still need to take a closer look at the SA changes. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38: > 36: public class CodeCache { > 37: private static GrowableArray heapArray; > 38: private static VirtualConstructor virtualConstructor; What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes. ------------- PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2604594200 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948335278 From cjplummer at openjdk.org Mon Feb 10 03:29:13 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Feb 2025 03:29:13 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 10 Feb 2025 02:47:58 GMT, Chris Plummer wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero and Minimal VM builds > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38: > >> 36: public class CodeCache { >> 37: private static GrowableArray heapArray; >> 38: private static VirtualConstructor virtualConstructor; > > What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes. I think I found the answer. Since there is no longer a vtable, TypeDataBase.addressTypeIsEqualToType() will no longer work for Codeblobs. I was wondering if the lack of a vtable might have some negative impact. Glad to see you found a solution. I hope the lack of a vtable does not creep in elsewhere. I know it will have some negative impact on things like the "findpc" functionality, which will no longer be able to tell the user that an address points to a Codeblob instance. There's no test for this, but users might run across it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948352958 From dholmes at openjdk.org Mon Feb 10 05:15:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Feb 2025 05:15:15 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: <6JhTT5S7sG4sOA7c7zkfV-QBentnCq6k7IdMvnZ1KXQ=.bfffe588-40b0-4d3e-afea-94a2a271bfc9@github.com> On Thu, 6 Feb 2025 10:45:29 GMT, Serguei Spitsyn wrote: > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran mach5 tiers 1-6 I am not at all sure about this. Why are virtual threads different to platform threads here? My recollection is that the handshake API deliberately does not wait for the suspension to occur, and that there is a separate mechanism to do that for code that needs it - in the old API we had `JvmtiEnv::is_thread_fully_suspended` src/hotspot/share/runtime/handshake.cpp line 804: > 802: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); > 803: _lock.wait_without_safepoint_check(1); > 804: } This would normally be incorrectly coded as you do not hold the lock around the state-change and so you may miss the notification. However, it is possible in this case that the overall handshake protocol prevents that from happening, but I cannot easily determine that. ------------- PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2604703300 PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1948403444 From ktakakuri at openjdk.org Mon Feb 10 06:23:38 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Mon, 10 Feb 2025 06:23:38 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform Message-ID: To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. After this fix, I verified that the test passed. https://github.com/openjdk/jdk/pull/22142 I refer to this fix. tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. Thanks. ------------- Commit messages: - 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform - 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform - 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform Changes: https://git.openjdk.org/jdk/pull/23536/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349288 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23536/head:pull/23536 PR: https://git.openjdk.org/jdk/pull/23536 From ktakakuri at openjdk.org Mon Feb 10 08:48:59 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Mon, 10 Feb 2025 08:48:59 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: > To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. > I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. > After this fix, I verified that the test passed. > > https://github.com/openjdk/jdk/pull/22142 > I refer to this fix. > tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. > > Thanks. Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23536/files - new: https://git.openjdk.org/jdk/pull/23536/files/aa14bd35..b18bbdac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23536/head:pull/23536 PR: https://git.openjdk.org/jdk/pull/23536 From azafari at openjdk.org Mon Feb 10 10:04:10 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 10 Feb 2025 10:04:10 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v3] In-Reply-To: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> Message-ID: > The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. > Some compilers do not mask the shift value to the base size and UBSAN catches the case. > In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. 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 four additional commits since the last revision: - Merge with master - size -> count in comments - removed extra blank lines - 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22807/files - new: https://git.openjdk.org/jdk/pull/22807/files/93baeb1b..00239755 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22807&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22807&range=01-02 Stats: 220638 lines in 6033 files changed: 108098 ins; 88113 del; 24427 mod Patch: https://git.openjdk.org/jdk/pull/22807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22807/head:pull/22807 PR: https://git.openjdk.org/jdk/pull/22807 From azafari at openjdk.org Mon Feb 10 10:04:11 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 10 Feb 2025 10:04:11 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v2] In-Reply-To: <2T8QiNDGZjC1qqGFoMaAsIBehDwrdLhaB3ENICIHy1g=.430718a8-bff2-419c-88f4-b737428ca385@github.com> References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> <2T8QiNDGZjC1qqGFoMaAsIBehDwrdLhaB3ENICIHy1g=.430718a8-bff2-419c-88f4-b737428ca385@github.com> Message-ID: <7kFhc2F0vpjErDwy5IhxpewZA-g3wqiarw3Ex1_AjJQ=.f14d99b3-e27d-419b-a0d0-3e9813595a3a@github.com> On Thu, 19 Dec 2024 08:46:57 GMT, Afshin Zafari wrote: >> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. >> Some compilers do not mask the shift value to the base size and UBSAN catches the case. >> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > removed extra blank lines Dear @kimbarrett and @dean-long, based on the discussions here and also considering that I have filed a bug regarding the mix of size and count usage, is there any other review points here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22807#issuecomment-2647494201 From dholmes at openjdk.org Mon Feb 10 10:16:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Feb 2025 10:16:15 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: <86_No6nGwjBtEc2mxOHUkN71Hjf8qp5ama5fx1obJE4=.dd438732-a372-4863-899a-f8317fd5476d@github.com> On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. > - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: > - JNI_GetDefaultJavaVMInitArgs > - JNI_GetCreatedJavaVMs > - JNI_CreateJavaVM > > On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. > > For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. > > TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. Okay - approved. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23431#pullrequestreview-2605294024 From azafari at openjdk.org Mon Feb 10 10:24:20 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 10 Feb 2025 10:24:20 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' Message-ID: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. ------------- Commit messages: - Merge branch '_8340110_ubsan_shift' of http://github.com/afshin-zafari/jdk into _8340110_ubsan_shift - comment added. - 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' Changes: https://git.openjdk.org/jdk/pull/23539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340110 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23539/head:pull/23539 PR: https://git.openjdk.org/jdk/pull/23539 From dholmes at openjdk.org Mon Feb 10 10:31:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Feb 2025 10:31:15 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 08:48:59 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform @ktakakuri I need to evaluate whether this is a general purpose fix that should work everywhere. ------------- PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2605330679 From dnsimon at openjdk.org Mon Feb 10 11:03:13 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 10 Feb 2025 11:03:13 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 19:36:28 GMT, Vladimir Kozlov wrote: > @dougxc and @tkrodriguez, please look if it affects Graal. I'm pretty sure JVMCI does not care about the virtual-ness of these C++ classes. Running tier9 in mach5 is a good way to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2647642674 From adinn at openjdk.org Mon Feb 10 11:07:14 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 10 Feb 2025 11:07:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com> On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero and Minimal VM builds src/hotspot/share/code/codeBlob.cpp line 58: > 56: #include > 57: > 58: // Virtual methods are not allowed in code blobs to simplify caching compiled code. Is it worth considering generating this code plus also some of the existing code in the header using an iterator template macro? e.g. #define CODEBLOBS_DO(do_codeblob_abstract, do_codeblob_nonleaf, \ do_codeblob_leaf) \ do_codeblob_abstract(CodeBlob) \ do_codeblob_leaf(nmethod, Nmethod, nmethod) \ do_codeblob_abstract(RuntimeBlob) \ do_codeblob_nonleaf(BufferBlob, Buffer, buffer) \ do_codeblob_leaf(AdapterBlob, Adapter, adapter) \ . . . \ do_codeblob_leaf(RuntimeStub, Runtime_Stub, runtime_stub) \ . . . The macro arguments to the templates would themselves be macros: do_codeblob_abstract(classname) // abstract, non-instantiable class do_codeblob_nonleaf(classname, kindname, accessorname) // instantiable, subclassable do_codeblob_leaf(classname, kindname, accessorname) // instantiable, non-subclassable Using a template macro like this to generate the code below -- *plus also* some of the code currently declared piecemeal in the header -- would guarantee all cases are covered now and will remain so later so when the macro is updated. I think it would probably also allow case handling code in AOT cache code to be generated. So, we would generate the code here as follows #define EMPTY1(classname) #define EMPTY3(classname, kindname, accessorname) #define assert_nonvirtual_leaf(classname, kindname, accessorname) \ static_assert(!std::is_polymorphic::value, \ "no virtual methods are allowed in " # classname ); CODEBLOBS_DO(empty1, empty3, assert_nonvirtual_leaf) #undef assert_nonvirtual_leaf Likewise in codeBlob.hpp we could generate `enum CodeBlobKind` to cover all the non-abstract classes and likewise generate the accessor methods `is_nmethod()`, `is_buffer_blob()` in class `CodeBlob` which allow the kind to be tested. #define codekind_enum_tag(classname, kindname, accessorname) \ kindname, enum CodeBlobKind : u1 { None, CODEBLOBS_DO(empty1, codekind_enum_tag, codekind_enum_tag) Number_Of_Kinds }; #define is_codeblob_define(classname, kindname, accessorname) \ void is_ # accessor_name () { return _kind == kindname; } class CodeBlob { . . . CODEBLOBS_DO(empty1, is_codeblob_define, is_codeblob_define); . . . There may be other opportunities to use the iterator (e.g. in vmStructs.cpp?) but this looks like a good start. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948849392 From vyazici at openjdk.org Mon Feb 10 12:15:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 10 Feb 2025 12:15:15 GMT Subject: Integrated: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 19:42:55 GMT, Volkan Yazici wrote: > Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: > > > $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt > $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 > 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt > 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt > 3574947 test/jdk/java/foreign/libTestDowncallStack.c > 7128495 test/jdk/java/foreign/libTestUpcallStack.c > > > **Other highlights:** > > - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` > - `test.lib.Asserts::assertFileContentsEqual` is added This pull request has now been integrated. Changeset: 55898922 Author: Volkan Yazici Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/55898922628a7fb1aef3ff6727a612baac3f6b1a Stats: 681 lines in 15 files changed: 235 ins; 281 del; 165 mod 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated Reviewed-by: dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23401 From jsjolen at openjdk.org Mon Feb 10 13:55:16 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Feb 2025 13:55:16 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: <_xgQURfOgpde08f9u5nUjqVVa4dztQ9i5QtslZJNSso=.849304f8-5ab8-4aa7-a3c8-dc0fb0748f21@github.com> On Fri, 7 Feb 2025 15:45:26 GMT, Gerard Ziemski wrote: >> Hi, >> >> That's correct as VMT does take `address`, whilst the external API takes "regular" pointers. > > Hmm, looks weird. Are we planning on cleaning this up further up the chain then? That is not the plan, no. I believe that the address typedef is there to signify that we are concerned with storing addresses, but not dereferencing them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23497#discussion_r1949094243 From jsjolen at openjdk.org Mon Feb 10 13:55:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Feb 2025 13:55:17 GMT Subject: Integrated: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:11:09 GMT, Johan Sj?len wrote: > Hi, > > Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. > > ```c++ > static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); > > > Thanks. This pull request has now been integrated. Changeset: f74c4dfe Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/f74c4dfe0b0c384a25f0b7a2330ba96d50b7fceb Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8349580: Do not use address in MemTracker top level functions Reviewed-by: gziemski, stefank ------------- PR: https://git.openjdk.org/jdk/pull/23497 From jsjolen at openjdk.org Mon Feb 10 14:17:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Feb 2025 14:17:39 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> On Thu, 6 Feb 2025 15:51:41 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed merge problems Hi! I've looked through some more of the PR and I've found multiple renamings from `type` to `tag`. It's great that you've done this, but can these changes be moved out into a separate PR for mainline? Keeping the diff minimal allows for much easier reviewing, and will let your hard work renaming type/flag to tag to be integrated sooner. I commented all the cases I found with "Move out into mainline PR". For `vmtCommon.hpp`: If I remember correctly this refactoring was made because we had 2 separate implementations, but now we only have one. Restoring the code such that the content of `vmtCommon.hpp` is put into `virtualMemoryTracker.hpp` will further make the diff smaller and make it easier to find the actual changes to the code. We're currently at +1528/-1846, that's a fairly large PR size. If we can make this smaller by separating out parts into multiple PRs and avoiding unnecessary refactoring of directory structure, then this can become quite a lot smaller and easier to review. I hope you'll consider making these changes, as I think it makes it easier on the reviewers. Thanks and all the best, Johan src/hotspot/share/nmt/mallocTracker.hpp line 163: > 161: } > 162: > 163: inline const MallocMemory* by_tag(MemTag mem_tag) const { Move out into mainline PR src/hotspot/share/nmt/mallocTracker.hpp line 241: > 239: > 240: static inline void record_arena_size_change(ssize_t size, MemTag mem_tag) { > 241: as_snapshot()->by_tag(mem_tag)->record_arena_size_change(size); Move out into mainline PR src/hotspot/share/nmt/mallocTracker.inline.hpp line 55: > 53: l = MallocLimitHandler::category_limit(mem_tag); > 54: if (l->sz > 0) { > 55: const MallocMemory* mm = as_snapshot()->by_tag(mem_tag); Move out into mainline PR src/hotspot/share/nmt/memBaseline.cpp line 64: > 62: > 63: // Sort into allocation site addresses and memory tag order for baseline comparison > 64: int compare_malloc_site_and_tag(const MallocSite& s1, const MallocSite& s2) { Move out into mainline PR src/hotspot/share/nmt/memBaseline.cpp line 235: > 233: break; > 234: case by_site_and_tag: > 235: malloc_sites_to_allocation_site_and_tag_order(); Move out into mainline PR src/hotspot/share/nmt/memBaseline.cpp line 275: > 273: > 274: void MemBaseline::malloc_sites_to_allocation_site_order() { > 275: if (_malloc_sites_order != by_site && _malloc_sites_order != by_site_and_tag) { Move out into mainline PR src/hotspot/share/nmt/memBaseline.cpp line 292: > 290: _malloc_sites.set_head(tmp.head()); > 291: tmp.set_head(nullptr); > 292: _malloc_sites_order = by_site_and_tag; Move out into mainline PR src/hotspot/share/nmt/memBaseline.hpp line 56: > 54: by_size, // by memory size > 55: by_site, // by call site where the memory is allocated from > 56: by_site_and_tag // by call site and memory tag Move out into mainline PR (and indentation of comment seems wrong) src/hotspot/share/nmt/memBaseline.hpp line 154: > 152: VirtualMemory* virtual_memory(MemTag mem_tag) { > 153: assert(baseline_type() != Not_baselined, "Not yet baselined"); > 154: return _virtual_memory_snapshot.by_tag(mem_tag); Move out into mainline PR src/hotspot/share/nmt/memBaseline.hpp line 207: > 205: void malloc_sites_to_allocation_site_order(); > 206: // Sort allocation sites in call site address and memory tag order > 207: void malloc_sites_to_allocation_site_and_tag_order(); Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 192: > 190: } > 191: > 192: void MemSummaryReporter::report_summary_of_tag(MemTag mem_tag, Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 201: > 199: if (mem_tag == mtThread) { > 200: const VirtualMemory* thread_stack_usage = > 201: (const VirtualMemory*)_vm_snapshot->by_tag(mtThreadStack); Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 243: > 241: } else if (mem_tag == mtThread) { > 242: const VirtualMemory* thread_stack_usage = > 243: _vm_snapshot->by_tag(mtThreadStack); Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 538: > 536: // thread stack is reported as part of thread category > 537: if (mem_tag == mtThreadStack) continue; > 538: diff_summary_of_tag(mem_tag, Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 608: > 606: > 607: > 608: void MemSummaryDiffReporter::diff_summary_of_tag(MemTag mem_tag, Move out into mainline PR src/hotspot/share/nmt/memReporter.cpp line 810: > 808: void MemDetailDiffReporter::diff_malloc_sites() const { > 809: MallocSiteIterator early_itr = _early_baseline.malloc_sites(MemBaseline::by_site_and_tag); > 810: MallocSiteIterator current_itr = _current_baseline.malloc_sites(MemBaseline::by_site_and_tag); Move out into mainline PR src/hotspot/share/nmt/memoryFileTracker.cpp line 47: > 45: VMATree::SummaryDiff diff = file->_tree.commit_mapping(offset, size, regiondata); > 46: for (int i = 0; i < mt_number_of_tags; i++) { > 47: VirtualMemory* summary = file->_summary.by_tag(NMTUtil::index_to_tag(i)); Move out into mainline PR src/hotspot/share/nmt/memoryFileTracker.cpp line 56: > 54: VMATree::SummaryDiff diff = file->_tree.release_mapping(offset, size); > 55: for (int i = 0; i < mt_number_of_tags; i++) { > 56: VirtualMemory* summary = file->_summary.by_tag(NMTUtil::index_to_tag(i)); Move out into mainline PR src/hotspot/share/nmt/memoryFileTracker.cpp line 187: > 185: snap->commit_memory(current->committed()); > 186: } > 187: } Revert this change src/hotspot/share/nmt/memoryFileTracker.hpp line 81: > 79: const MemoryFile* file = _files.at(d); > 80: for (int i = 0; i < mt_number_of_tags; i++) { > 81: f(NMTUtil::index_to_tag(i), file->_summary.by_tag(NMTUtil::index_to_tag(i))); Move out into mainline PR src/hotspot/share/nmt/nmtCommon.cpp line 33: > 31: > 32: #define MEMORY_TAG_DECLARE_NAME(tag, human_readable) \ > 33: { #tag, human_readable }, Move out into mainline PR src/hotspot/share/nmt/nmtCommon.hpp line 91: > 89: // Map memory tag to index > 90: static inline int tag_to_index(MemTag mem_tag) { > 91: assert(tag_is_valid(mem_tag), "Invalid tag (%u)", (unsigned)mem_tag); Move out into mainline PR ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2605844859 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949121262 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949121527 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949120937 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949120631 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949120394 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949120180 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949119941 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949118303 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949118619 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949118841 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949116400 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949115914 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949115644 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949110432 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949110306 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949110184 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949109029 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949108903 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949107753 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949105112 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949104485 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1949104091 From stuefe at openjdk.org Mon Feb 10 14:30:29 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Feb 2025 14:30:29 GMT Subject: RFR: 8349580: Do not use address in MemTracker top level functions In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:11:09 GMT, Johan Sj?len wrote: > Hi, > > Please consider this trivial patch. Note that this gives us consistency with `reserve_memory`. > > ```c++ > static inline void record_virtual_memory_reserve(void* addr, size_t size, /* ... */); > > > Thanks. We use `address` in most other parts of the JVM for "unspecified pointer". I would rather use address more consistently (also for APIs that today take "char*" for historical reasons). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23497#issuecomment-2648163859 From stefank at openjdk.org Mon Feb 10 16:26:12 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 10 Feb 2025 16:26:12 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero and Minimal VM builds We have a similar situation with oopDesc that are not allowed to have a vtable. The solution there is to use the Klass as the proxy vtable and then have a bunch of Klass::oop_ functions that act like virtual dispatch functions for associated oopDesc functions. I wonder if a similar approach can be use here? Such an approach would (to me at lest) have the benefit that we don't have to spread switch statements in various functions in the top-most class. If you are interested in seeing a prototype of this, take a look at this branch: https://github.com/openjdk/jdk/compare/master...stefank:jdk:code_blob_vptr Just a suggestion if you want to consider alternatives to these switch statements. ------------- PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2606457754 From kvn at openjdk.org Mon Feb 10 16:39:19 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 10 Feb 2025 16:39:19 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com> Message-ID: <1P7Q-yHC0Ho8DPfgzZfxR27NmNQPJ4LcgEbilqdaVNw=.0c023c74-b3d9-4139-8363-5ebdf1a1805d@github.com> On Mon, 10 Feb 2025 11:04:38 GMT, Andrew Dinn wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero and Minimal VM builds > > src/hotspot/share/code/codeBlob.cpp line 58: > >> 56: #include >> 57: >> 58: // Virtual methods are not allowed in code blobs to simplify caching compiled code. > > Is it worth considering generating this code plus also some of the existing code in the header using an iterator template macro? e.g. > > #define CODEBLOBS_DO(do_codeblob_abstract, do_codeblob_nonleaf, \ > do_codeblob_leaf) \ > do_codeblob_abstract(CodeBlob) \ > do_codeblob_leaf(nmethod, Nmethod, nmethod) \ > do_codeblob_abstract(RuntimeBlob) \ > do_codeblob_nonleaf(BufferBlob, Buffer, buffer) \ > do_codeblob_leaf(AdapterBlob, Adapter, adapter) \ > . . . \ > do_codeblob_leaf(RuntimeStub, Runtime_Stub, runtime_stub) \ > . . . > > The macro arguments to the templates would themselves be macros: > > do_codeblob_abstract(classname) // abstract, non-instantiable class > do_codeblob_nonleaf(classname, kindname, accessorname) // instantiable, subclassable > do_codeblob_leaf(classname, kindname, accessorname) // instantiable, non-subclassable > > Using a template macro like this to generate the code below -- *plus also* some of the code currently declared piecemeal in the header -- would guarantee all cases are covered now and will remain so later so when the macro is updated. I think it would probably also allow case handling code in AOT cache code to be generated. > > So, we would generate the code here as follows > > #define EMPTY1(classname) > #define EMPTY3(classname, kindname, accessorname) > > #define assert_nonvirtual_leaf(classname, kindname, accessorname) \ > static_assert(!std::is_polymorphic::value, \ > "no virtual methods are allowed in " # classname ); > > CODEBLOBS_DO(empty1, empty3, assert_nonvirtual_leaf) > > #undef assert_nonvirtual_leaf > > Likewise in codeBlob.hpp we could generate `enum CodeBlobKind` to cover all the non-abstract classes and likewise generate the accessor methods `is_nmethod()`, `is_buffer_blob()` in class `CodeBlob` which allow the kind to be tested. > > #define codekind_enum_tag(classname, kindname, accessorname) \ > kindname, > > enum CodeBlobKind : u1 { > None, > CODEBLOBS_DO(empty1, codekind_enum_tag, codekind_enum_tag) > Number_Of_Kinds > }; > > ... Thank you @adinn for suggestion but no, I don't like macros - hard to debug and they add more complexity in this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1949483501 From kvn at openjdk.org Mon Feb 10 16:50:12 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 10 Feb 2025 16:50:12 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 10 Feb 2025 03:25:30 GMT, Chris Plummer wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38: >> >>> 36: public class CodeCache { >>> 37: private static GrowableArray heapArray; >>> 38: private static VirtualConstructor virtualConstructor; >> >> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes. > > I think I found the answer. Since there is no longer a vtable, TypeDataBase.addressTypeIsEqualToType() will no longer work for Codeblobs. I was wondering if the lack of a vtable might have some negative impact. Glad to see you found a solution. I hope the lack of a vtable does not creep in elsewhere. I know it will have some negative impact on things like the "findpc" functionality, which will no longer be able to tell the user that an address points to a Codeblob instance. There's no test for this, but users might run across it. > What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes. I don't need any more mapping from CodeBlob class to corresponding virtual table name which does not exist anymore. `CodeBlob::_kind` field's value is used to determine which class should be used. I think `hashMap` is overkill here. I can construct array `Class cbClasses[]` and use `cbClasses[CodeBlob::_kind]` instead of `if/else` in `getClassFor`. But I would still need to check for unknown value of `CodeBlob::_kind` somehow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1949505126 From kvn at openjdk.org Mon Feb 10 17:06:13 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 10 Feb 2025 17:06:13 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 10 Feb 2025 16:23:53 GMT, Stefan Karlsson wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero and Minimal VM builds > > We have a similar situation with oopDesc that are not allowed to have a vtable. The solution there is to use the Klass as the proxy vtable and then have a bunch of Klass::oop_ functions that act like virtual dispatch functions for associated oopDesc functions. > > I wonder if a similar approach can be use here? Such an approach would (to me at lest) have the benefit that we don't have to spread switch statements in various functions in the top-most class. > > If you are interested in seeing a prototype of this, take a look at this branch: > https://github.com/openjdk/jdk/compare/master...stefank:jdk:code_blob_vptr > > Just a suggestion if you want to consider alternatives to these switch statements. Thank you, @stefank. This is very interesting suggestion which I may take. I will check it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2648688942 From jiangli at openjdk.org Mon Feb 10 18:08:16 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Feb 2025 18:08:16 GMT Subject: Integrated: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou wrote: > Please review runtime/jni/atExit/TestAtExit.java test change: > > - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage. > - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses: > - JNI_GetDefaultJavaVMInitArgs > - JNI_GetCreatedJavaVMs > - JNI_CreateJavaVM > > On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html). https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform. > > For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. > > TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run. This pull request has now been integrated. Changeset: 84b32cb6 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/84b32cb61c3e04189eb811fa052747e21ca6aff1 Stats: 56 lines in 2 files changed: 52 ins; 1 del; 3 mod 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23431 From jiangli at openjdk.org Mon Feb 10 18:08:15 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Feb 2025 18:08:15 GMT Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK In-Reply-To: References: Message-ID: <8c16ZISEufaQY3veBo1CAW-bZbTHlWaiJe9Fcw7KMOQ=.9f5abed1-c1ec-44e9-b052-468014d0b436@github.com> On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes wrote: >> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > >> Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example. > > Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard. Thanks, @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2648837104 From jsjolen at openjdk.org Mon Feb 10 18:28:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Feb 2025 18:28:11 GMT Subject: RFR: 8319055: JCMD should not buffer the whole output of commands [v3] In-Reply-To: References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com> <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com> Message-ID: On Tue, 4 Feb 2025 20:12:44 GMT, Alex Menkov wrote: > > I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed? > > The protocol works as before. All command handlers are updated to set the result code earlier (after argument parsing, but before command execution). After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering. Aha, I understand. Before, result code meant "Parsing OK, Command Execution OK", now it means "Parsing OK, starting Command Execution". That's fine by me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2648889826 From dlong at openjdk.org Mon Feb 10 20:04:10 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 10 Feb 2025 20:04:10 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v2] In-Reply-To: <7kFhc2F0vpjErDwy5IhxpewZA-g3wqiarw3Ex1_AjJQ=.f14d99b3-e27d-419b-a0d0-3e9813595a3a@github.com> References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> <2T8QiNDGZjC1qqGFoMaAsIBehDwrdLhaB3ENICIHy1g=.430718a8-bff2-419c-88f4-b737428ca385@github.com> <7kFhc2F0vpjErDwy5IhxpewZA-g3wqiarw3Ex1_AjJQ=.f14d99b3-e27d-419b-a0d0-3e9813595a3a@github.com> Message-ID: On Mon, 10 Feb 2025 10:00:17 GMT, Afshin Zafari wrote: > Dear @kimbarrett and @dean-long, based on the discussions here and also considering that I have filed a bug regarding the mix of size and count usage, is there any other review points here? I think it's better to go with Axel's suggestion and then have him review the change. @xmas92 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22807#issuecomment-2649109100 From jsjolen at openjdk.org Mon Feb 10 21:41:20 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Feb 2025 21:41:20 GMT Subject: RFR: 8349755: Fix corner case issues in async UL Message-ID: Hi, There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. Note, this fix introduces a third case: 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. Testing: GHA only, so far. All the best, Johan ------------- Commit messages: - Handle async UL corner-cases Changes: https://git.openjdk.org/jdk/pull/23513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349755 Stats: 53 lines in 4 files changed: 33 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From syan at openjdk.org Tue Feb 11 03:52:40 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 11 Feb 2025 03:52:40 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests Message-ID: Hi all, This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8349771: Replace usages of -mx and -ms in some monitor tests Changes: https://git.openjdk.org/jdk/pull/23553/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23553&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349771 Stats: 38 lines in 2 files changed: 0 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/23553.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23553/head:pull/23553 PR: https://git.openjdk.org/jdk/pull/23553 From dholmes at openjdk.org Tue Feb 11 07:25:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 11 Feb 2025 07:25:09 GMT Subject: RFR: 8349755: Fix corner case issues in async UL In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 10:21:37 GMT, Johan Sj?len wrote: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan This looks good to me. When you have nested logging I'm not even sure what the "right" order would be, so I'm not concerned in that regard. Can we add some debug-only logging by the log producer so that we can actually test this? Thanks src/hotspot/share/logging/logAsyncWriter.cpp line 124: > 122: if (resort_to_synchronous_logging()) { > 123: return false; > 124: } Suggestion: } // If we get here we know the AsyncLogWriter is initialized. ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2607881170 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1950348370 From jpai at openjdk.org Tue Feb 11 07:35:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 11 Feb 2025 07:35:10 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 03:48:38 GMT, SendaoYan wrote: > Hi all, > This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. > > As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. > > Change has been verified locally, test-fix only, no risk. test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved. Hello @sendaoYan, a comma is missing after the new copyright year, both here and in the other file in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23553#discussion_r1950359275 From aboldtch at openjdk.org Tue Feb 11 07:40:11 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 11 Feb 2025 07:40:11 GMT Subject: RFR: 8349755: Fix corner case issues in async UL In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 10:21:37 GMT, Johan Sj?len wrote: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Looks good. Have a few naming and code structure suggestions. src/hotspot/share/logging/logAsyncWriter.cpp line 96: > 94: // This function checks for cases where continuing with asynchronous logging may lead to stability issues, such as a deadlock. > 95: // If this returns true then we give up on logging asynchronously and do so synchronously instead. > 96: bool AsyncLogWriter::resort_to_synchronous_logging() { The name `resort_to_synchronous_logging` says something about what the callers of `enqueue` should do. I think something more in the line of `is_enqueue_disallowed` / `is_async_logging_disallowed` would be better. Or probably inverting the the logic, and have it be `is_enqueue_allowed`. src/hotspot/share/logging/logAsyncWriter.cpp line 106: > 104: is_recursively_logging || // A thread enqueuing a message has attempted to log something. > 105: alw == nullptr || // There is no AsyncLogWriter instance yet. > 106: this_thread == nullptr; // The current thread is unattached. I think an early return makes this more readable. Might even be worth just having four separate if statements. Suggestion: if (this_thread == nullptr) { // The current thread is unattached. return true; } bool is_async_log_thread = alw == this_thread; bool is_recursively_logging = holding_thread == this_thread; assert(!is_recursively_logging, "Do not log while holding the Async log lock"); return is_async_log_thread || // The async log producer is attempting to log, leading to recursive logging. is_recursively_logging || // A thread enqueuing a message has attempted to log something. alw == nullptr; // There is no AsyncLogWriter instance yet. Suggestion: if (this_thread == nullptr) { // The current thread is unattached. return true; } if (holding_thread == this_thread) { // A thread, while enqueuing a message, has attempted to log something. // Do not log while holding the Async log lock. // Try to catch possible occurrences in debug builds. DEBUG_ONLY(ShouldNotReachHere();) return true; } if (alw == nullptr) { // There is no AsyncLogWriter instance yet. return true; } if (this_thread == alw) { // The async log producer is attempting to log, leading to recursive logging. return true; } return false; ------------- Changes requested by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2607892358 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1950359423 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1950354412 From syan at openjdk.org Tue Feb 11 09:33:26 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 11 Feb 2025 09:33:26 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: > Hi all, > This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. > > As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. > > Change has been verified locally, test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add missing comma in file header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23553/files - new: https://git.openjdk.org/jdk/pull/23553/files/c016265e..844cda3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23553&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23553&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23553.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23553/head:pull/23553 PR: https://git.openjdk.org/jdk/pull/23553 From jpai at openjdk.org Tue Feb 11 10:07:11 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 11 Feb 2025 10:07:11 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 09:33:26 GMT, SendaoYan wrote: >> Hi all, >> This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. >> >> As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing comma in file header These changes look reasonable to me. I don't know why my `grep` missed these files in the JDK when I had proposed similar changes in different areas a few months back. I'm guessing you have run these tests after this update and they continue to pass? Please wait for reviews from others familiar with this area before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23553#pullrequestreview-2608234158 From stefank at openjdk.org Tue Feb 11 10:18:10 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 11 Feb 2025 10:18:10 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 09:33:26 GMT, SendaoYan wrote: >> Hi all, >> This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. >> >> As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing comma in file header Looks good to me. I think this is trivial enough that you can push this right away. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23553#pullrequestreview-2608263766 From syan at openjdk.org Tue Feb 11 11:31:11 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 11 Feb 2025 11:31:11 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 10:04:19 GMT, Jaikiran Pai wrote: > I'm guessing you have run these tests after this update and they continue to pass? Yes. Thanks @jaikiran @stefank for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23553#issuecomment-2650533806 From dholmes at openjdk.org Tue Feb 11 12:06:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 11 Feb 2025 12:06:10 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 09:33:26 GMT, SendaoYan wrote: >> Hi all, >> This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. >> >> As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. >> >> Change has been verified locally, test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing comma in file header LGTM2. I was waiting for the comma fix. :) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23553#pullrequestreview-2608520525 From syan at openjdk.org Tue Feb 11 12:41:29 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 11 Feb 2025 12:41:29 GMT Subject: RFR: 8349771: Replace usages of -mx and -ms in some monitor tests [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 12:03:43 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing comma in file header > > LGTM2. I was waiting for the comma fix. :) Thanks @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/23553#issuecomment-2650702251 From syan at openjdk.org Tue Feb 11 12:41:29 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 11 Feb 2025 12:41:29 GMT Subject: Integrated: 8349771: Replace usages of -mx and -ms in some monitor tests In-Reply-To: References: Message-ID: <4Cs8UBYaQ3JKX_cvAJ0olX3klmtqc4b2ny2Eco7sMKY=.f4717829-3232-49f2-bad2-a4bf67aa59a5@github.com> On Tue, 11 Feb 2025 03:48:38 GMT, SendaoYan wrote: > Hi all, > This PR updates two runtime/Monitor tests to replace the usage of the outdated `-mx` and `-ms` java launcher options with `-Xmx` and `-Xms`. > > As noted in [JDK-8349771](https://bugs.openjdk.org/browse/JDK-8349771), these outdated options will soon be deprecated for removal from the java launcher code. > > Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: 545d19f1 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/545d19f1fa102d35908528520dc19a7d16000d63 Stats: 38 lines in 2 files changed: 0 ins; 0 del; 38 mod 8349771: Replace usages of -mx and -ms in some monitor tests Reviewed-by: jpai, stefank, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23553 From jsjolen at openjdk.org Tue Feb 11 13:07:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 13:07:52 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v2] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Axel Boldt-Christmas Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/d99b779e..74236fad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=00-01 Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Tue Feb 11 13:07:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 13:07:52 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 13:05:08 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Axel Boldt-Christmas > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ~Take requested changes~ Edit: I misunderstood Github's UI, ignore this message. ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2608686095 From jsjolen at openjdk.org Tue Feb 11 13:32:55 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 13:32:55 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v3] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Add test - Trailing whitespace cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/74236fad..2a0b244a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=01-02 Stats: 53 lines in 3 files changed: 47 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From azafari at openjdk.org Tue Feb 11 13:39:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 11 Feb 2025 13:39:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v22] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: removed vmtCommon.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/873d5355..35c11b96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=20-21 Stats: 983 lines in 16 files changed: 447 ins; 519 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From jsjolen at openjdk.org Tue Feb 11 16:29:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 16:29:39 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v4] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Add test for non-debug build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/2a0b244a..9a923d6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=02-03 Stats: 50 lines in 4 files changed: 46 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From naoto at openjdk.org Tue Feb 11 17:23:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 11 Feb 2025 17:23:21 GMT Subject: Integrated: 8349254: Disable "best-fit" mapping on Windows environment variables In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote: > This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. This pull request has now been integrated. Changeset: 64281653 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/642816538fbaa5b74c6beb8a14d1738cdde28c10 Stats: 138 lines in 3 files changed: 74 ins; 43 del; 21 mod 8349254: Disable "best-fit" mapping on Windows environment variables Reviewed-by: jlu, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23498 From jsjolen at openjdk.org Tue Feb 11 17:23:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 17:23:05 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v5] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: wait() via method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/9a923d6f..c1c2ee7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=03-04 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From naoto at openjdk.org Tue Feb 11 17:23:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 11 Feb 2025 17:23:20 GMT Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment variables [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote: >> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed. > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Reflects review > - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars > - Reflects review > - initial commit Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2651520018 From jsjolen at openjdk.org Tue Feb 11 17:25:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 17:25:59 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v6] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Add log_debug for other type of enqueue also ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/c1c2ee7d..02b0d737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Tue Feb 11 17:31:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Feb 2025 17:31:53 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: Message-ID: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Use -Xlog:all=debug for entering the deathtest message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/02b0d737..7d2cf5ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From pchilanomate at openjdk.org Tue Feb 11 19:19:12 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 11 Feb 2025 19:19:12 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 10:45:29 GMT, Serguei Spitsyn wrote: > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran mach5 tiers 1-6 Hi Serguei, I investigated this issue but don?t agree with the patch. I added comments below. Thanks, Patricio src/hotspot/share/runtime/handshake.cpp line 800: > 798: // for virtual thread to reach a safe state before the JVMTI SuspendThread is returned. > 799: while (_handshakee->thread_state() != _thread_blocked && > 800: _handshakee->thread_state() != _thread_in_native) { We already wait for the target to reach a handshake-safe state when executing the `SuspendThreadHandshake`. It?s just that we don?t wait until the target suspends in `do_self_suspend()` since that can take arbitrarily long (e.g. target just waiting in native). ------------- Changes requested by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2609789365 PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1951455308 From pchilanomate at openjdk.org Tue Feb 11 19:23:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 11 Feb 2025 19:23:17 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 10:45:29 GMT, Serguei Spitsyn wrote: > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran mach5 tiers 1-6 Now, I was able to reproduce the crash and found the problem. The target is being suspended while creating the JvmtiThreadState in `JvmtiExport::at_single_stepping_point()`. It is found in the `_thread_blocked` state due to blocking while trying to acquire `JvmtiThreadState_lock`. We never process a suspend handshake when coming out of the blocked state though, since we can be holding VM monitors, so the target can continue executing until the next transition to Java or transition out of native. The agent then enables single stepping notifications for the target, and the target reaches `JvmtiExport::post_single_step()` and posts the event before the notifications are disabled again. Seems this issue can happen with other events too, it?s just that we probably don't have tests for them. I thought we can add a suspend check before making JVMTI callbacks. But although that would fix this issue, there is still always a race due to the `JvmtiJavaThreadEventTransition` object, since after switching to native a suspend request will succeed. So if the test would instead enable single stepping first (or some other event) and then suspend, we could still see the callback after suspending the target. Note that this last race can also happen with platform threads. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2651851154 From kvn at openjdk.org Tue Feb 11 23:58:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 11 Feb 2025 23:58:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 10 Feb 2025 03:11:22 GMT, Chris Plummer wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero and Minimal VM builds > > I almost wished I hadn't looked because there is a lot of SA CodeBlob support that could use some cleanup. Most notably I think most of the wrapper subclasses are not needed by SA, and could be served by one common class. See what I'm doing in #23456 for JavaThread subclasses. Wrapper classes don't need to be 1-to-1 with the class type they are wrapping. A single wrapper class type can handle any number of hotspot types. It usually just make more sense for them to be 1-to-1, but when they are trivial and the implementation is replicated across subtypes, just having one wrapper class implement them all can simplify things. > > The other thing I noticed is a lot of the subtypes seem to be doing some unnecessary things like registering Observers, and they all do something like the following: > > 44 Type type = db.lookupType("BufferBlob"); > > Even when it never references "type". > > I'm not suggesting you clean up any of this now, but just pointed it out. I might file an issue and try to clean it up myself at some point. > > I still need to take a closer look at the SA changes. Before I forgot to answer you, @plummercj I completely agree with your comment about cleaning up wrapper subclasses which do nothing. I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there? An other purpose could be a place holder for additional information in a future which never come. Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM. So yes, feel free to clean this up. I will help with review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652321179 From kvn at openjdk.org Wed Feb 12 00:11:28 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 00:11:28 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v3] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Add CodeBlob proxy vtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/dda20f0b..43ae0ed2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=01-02 Stats: 322 lines in 13 files changed: 175 ins; 90 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From kvn at openjdk.org Wed Feb 12 00:11:28 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 00:11:28 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero and Minimal VM builds I adopted Stefan's suggestion. I agree that it is more "future-proof". I also remove underscore `_` from `CodeBlobKind` names. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652333587 PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652335723 From kvn at openjdk.org Wed Feb 12 00:14:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 00:14:31 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v4] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix Minimal and Zero VM builds again ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/43ae0ed2..7d3dce0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From kvn at openjdk.org Wed Feb 12 00:22:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 00:22:31 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v5] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix Minimal and Zero VM builds once more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/7d3dce0e..1d108349 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From cjplummer at openjdk.org Wed Feb 12 03:06:15 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 12 Feb 2025 03:06:15 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Tue, 11 Feb 2025 23:55:46 GMT, Vladimir Kozlov wrote: > I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there? Possibly getName() didn't exist when PStack was first written. It would be good if PStack not only included the type name as it does now, but also the actual name of the blob, which getName() would return. > An other purpose could be a place holder for additional information in a future which never come. Yes, and you also see that with the Observer registration and the `Type type = db.lookupType()` code, which are only needed if you are going to lookup fields of the subtypes, which most don't ever do, yet they all have this code. > Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM. Yeah, that's not working right for CodeBlob subtypes that are not RuntimeStubs. Easy to fix though. > So yes, feel free to clean this up. I will help with review. Ok. Let me see where things are at after you are done with the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652549878 From dholmes at openjdk.org Wed Feb 12 03:43:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Feb 2025 03:43:11 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> On Mon, 10 Feb 2025 08:48:59 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform Changes requested by dholmes (Reviewer). test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 66: > 64: > 65: List command = new ArrayList<>(); > 66: //Execution command to prevent garbled characters Suggestion: // Force language to English before running systeminfo to get the OS version test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 68: > 66: //Execution command to prevent garbled characters > 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); > 68: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); I see the use of `chcp` in the test `./tools/jpackage/helpers/jdk/jpackage/test/Executor.java` so that is okay. However it doesn't set the path and it does not seem necessary to do so, and potentially assumes what the paths are anyway. So I think you can simplify this a little. test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 69: > 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); > 68: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); > 69: //Execute command to obtain OS Version Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2610660390 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1951891541 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1951893753 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1951891668 From dholmes at openjdk.org Wed Feb 12 08:46:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Feb 2025 08:46:14 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Tue, 11 Feb 2025 17:31:53 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Use -Xlog:all=debug for entering the deathtest message Changes requested by dholmes (Reviewer). src/hotspot/share/logging/logAsyncWriter.cpp line 45: > 43: > 44: ~AsyncLogLocker() { > 45: assert(_holder == nullptr || _holder == Thread::current_or_null(), "must be"); Don't understand this change. We are in the destructor so if the holder is null then this must be an unattached thread. So the original assert suffices. src/hotspot/share/logging/logAsyncWriter.cpp line 53: > 51: _holder = nullptr; > 52: _instance->_lock.wait(0/* no timeout */); > 53: _holder = Thread::current_or_null(); Suggestion: Thread* saved_holder = _holder; _holder = nullptr; _instance->_lock.wait(0/* no timeout */); _holder = saved_holder; test/hotspot/jtreg/runtime/logging/AsyncDeathTestDebug.java line 42: > 40: public static void main(String[] args) throws Exception { > 41: ProcessBuilder pb = > 42: ProcessTools.createLimitedTestJavaProcessBuilder("-Xlog:async", "-Xlog:all=debug"); If we are going to crash we should add `-XX:-CreateCoredumpOnCrash` test/hotspot/jtreg/runtime/logging/AsyncDeathTestNonProduct.java line 39: > 37: import jdk.test.lib.process.OutputAnalyzer; > 38: > 39: public class AsyncDeathNonProduct { Did you mean to call this `AsyncDeathNonDebug` ?? You could just have one test file and two @test sections: one for debug and one for non-debug, then adapt the logic accordingly. But this non-debug version isn't verifying the correct execution of recursive logging in product mode, because there is no actual recursive logging being performed - this test isn't doing anything. You would need some product logging to actually verify that but then anything that did `-Xlog:all` would crash. So perhaps just delete this version of the test. ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2611130551 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952173405 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952207501 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952182692 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952200622 From dholmes at openjdk.org Wed Feb 12 08:46:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Feb 2025 08:46:15 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 08:22:45 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Use -Xlog:all=debug for entering the deathtest message > > test/hotspot/jtreg/runtime/logging/AsyncDeathTestDebug.java line 42: > >> 40: public static void main(String[] args) throws Exception { >> 41: ProcessBuilder pb = >> 42: ProcessTools.createLimitedTestJavaProcessBuilder("-Xlog:async", "-Xlog:all=debug"); > > If we are going to crash we should add `-XX:-CreateCoredumpOnCrash` Also does this mean we are going to crash on the very first log_debug? You have two logging statements that will trigger the crash but only one of them can be reached with the way the testing is structured. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952187695 From sspitsyn at openjdk.org Wed Feb 12 09:30:10 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Feb 2025 09:30:10 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: <6JhTT5S7sG4sOA7c7zkfV-QBentnCq6k7IdMvnZ1KXQ=.bfffe588-40b0-4d3e-afea-94a2a271bfc9@github.com> References: <6JhTT5S7sG4sOA7c7zkfV-QBentnCq6k7IdMvnZ1KXQ=.bfffe588-40b0-4d3e-afea-94a2a271bfc9@github.com> Message-ID: On Mon, 10 Feb 2025 05:11:41 GMT, David Holmes wrote: >> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp endThread()` and others are returned. For instance, some `SingleStep` events can be posted. >> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. >> >> Testing: >> - Ran mach5 tiers 1-6 > > src/hotspot/share/runtime/handshake.cpp line 804: > >> 802: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >> 803: _lock.wait_without_safepoint_check(1); >> 804: } > > This would normally be incorrectly coded as you do not hold the lock around the state-change and so you may miss the notification. However, it is possible in this case that the overall handshake protocol prevents that from happening, but I cannot easily determine that. Thank you for the comment, David. You are right. It is why waiting is with the timeout: `_lock.wait_without_safepoint_check(1);` But this is not fully correct either. I see, Patricio also disagreed with my hack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1952280789 From sspitsyn at openjdk.org Wed Feb 12 09:35:25 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Feb 2025 09:35:25 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 10:45:29 GMT, Serguei Spitsyn wrote: > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran mach5 tiers 1-6 Thank you for the comment and nice analysis, Patricio! It helps. Will try to find a right fix for this. How many test runs did it take to reproduce this? My observation is that it is not easy to reproduce. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2653123640 From shade at openjdk.org Wed Feb 12 10:21:34 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Feb 2025 10:21:34 GMT Subject: RFR: 8349888: AOTMode=create crashes in AOTClassLinker::class_category_name Message-ID: Reliably reproduces in current mainline, see the bug for reproducer. I think we are crashing after feeding `nullptr` to `class_category_name`. That `nullptr` is from `ArchiveBuilder::current()->get_buffered_addr` of `HelloStream`, which is skipped, as per warning message right before the crash. So it looks like the fix is to check if we are dealing with class that is available in the buffer before reaching for its buffered address. @iklam, see if this is a right fix? Additional testing: - [x] Linux x86_64 server fastdebug, reproducer now passes - [x] Linux x86_64 server fastdebug, `runtime/cds` passes ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/23581/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23581&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349888 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23581.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23581/head:pull/23581 PR: https://git.openjdk.org/jdk/pull/23581 From jsjolen at openjdk.org Wed Feb 12 12:30:27 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 12 Feb 2025 12:30:27 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 08:16:00 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Use -Xlog:all=debug for entering the deathtest message > > src/hotspot/share/logging/logAsyncWriter.cpp line 45: > >> 43: >> 44: ~AsyncLogLocker() { >> 45: assert(_holder == nullptr || _holder == Thread::current_or_null(), "must be"); > > Don't understand this change. We are in the destructor so if the holder is null then this must be an unattached thread. So the original assert suffices. True, this is an unnecessary change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952555392 From jsjolen at openjdk.org Wed Feb 12 12:34:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 12 Feb 2025 12:34:09 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 08:26:07 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/logging/AsyncDeathTestDebug.java line 42: >> >>> 40: public static void main(String[] args) throws Exception { >>> 41: ProcessBuilder pb = >>> 42: ProcessTools.createLimitedTestJavaProcessBuilder("-Xlog:async", "-Xlog:all=debug"); >> >> If we are going to crash we should add `-XX:-CreateCoredumpOnCrash` > > Also does this mean we are going to crash on the very first log_debug? You have two logging statements that will trigger the crash but only one of them can be reached with the way the testing is structured. You're right, we do crash on the very first log_debug we reach (when in debug mode) as this hits the `ShouldNotReachHere()`. Both can be reached, but when one has been reached the other one won't be reached. I think it's fine, we're simply trying to see whether the recursive logging case is handled correctly. > If we are going to crash we should add -XX:-CreateCoredumpOnCrash What's your thinking here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952561164 From jsjolen at openjdk.org Wed Feb 12 12:42:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 12 Feb 2025 12:42:57 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v8] In-Reply-To: References: Message-ID: <-3t-C2fJU1w2xvOK1oXaXh_j0VNnnwguJo-J7m7CI-M=.045faafe-5a97-48b0-ab83-86d604b26a31@github.com> > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/logging/logAsyncWriter.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/7d2cf5ec..8663ebcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Wed Feb 12 12:42:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 12 Feb 2025 12:42:57 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 08:35:35 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Use -Xlog:all=debug for entering the deathtest message > > test/hotspot/jtreg/runtime/logging/AsyncDeathTestNonProduct.java line 39: > >> 37: import jdk.test.lib.process.OutputAnalyzer; >> 38: >> 39: public class AsyncDeathNonProduct { > > Did you mean to call this `AsyncDeathNonDebug` ?? > > You could just have one test file and two @test sections: one for debug and one for non-debug, then adapt the logic accordingly. But this non-debug version isn't verifying the correct execution of recursive logging in product mode, because there is no actual recursive logging being performed - this test isn't doing anything. You would need some product logging to actually verify that but then anything that did `-Xlog:all` would crash. So perhaps just delete this version of the test. I meant to call it `NonProduct`, and the rest of your message is confusing to me so I've probably misunderstood what my test does and what `NOT_PRODUCT` means :-). I've got: ```c++ NOT_PRODUCT(log_debug(deathtest)("Induce a recursive log for testing");) I thought `NON_PRODUCT` means that this is included regardless of `assert`s being enabled, but will not be shipped in a product build of the JDK. That's what I want to do, as that let's me test recursive logging without any asserts being triggered. I'll look into the test section suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1952571548 From kvn at openjdk.org Wed Feb 12 16:28:32 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 16:28:32 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix Zero VM build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/1d108349..b09ddce6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=04-05 Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From pchilanomate at openjdk.org Wed Feb 12 17:06:14 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 12 Feb 2025 17:06:14 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 09:32:23 GMT, Serguei Spitsyn wrote: > Thank you for the comment and nice analysis, Patricio! It helps. Will try to find a right fix for this. How many test runs did it take to reproduce this? My observation is that it is not easy to reproduce. > I attached a patch in JBS that makes the crash easier to reproduce. Give it a try. Running the test with -Xint crashes for me in very few attempts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2654339078 From iklam at openjdk.org Wed Feb 12 17:53:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Feb 2025 17:53:13 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 09:58:46 GMT, Aleksey Shipilev wrote: > Reliably reproduces in current mainline, see the bug for reproducer. I think we are crashing after feeding `nullptr` to `class_category_name`. That `nullptr` is from `ArchiveBuilder::current()->get_buffered_addr` of `HelloStream`, which is skipped, as per warning message right before the crash. > > So it looks like the fix is to check if we are dealing with class that is available in the buffer before reaching for its buffered address. @iklam, see if this is a right fix? > > Additional testing: > - [x] Linux x86_64 server fastdebug, reproducer now passes > - [x] Linux x86_64 server fastdebug, `runtime/cds` passes The proposed fix doesn't address the root cause -- when EpisonGC is used, `HelloStream$$Lambda` is archived: $ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -XX:AOTCache=app.aot -Xlog:cds+resolve=trace::none | grep Hello Resolved class [ 14] HelloStream -> java.util.List Resolved class [ 28] HelloStream -> java.util.stream.Stream Resolved class [ 36] HelloStream -> java.util.stream.Collectors Resolved class [ 45] HelloStream -> java.lang.String Resolved class [ 48] HelloStream -> java.lang.System Resolved class [ 54] HelloStream -> java.io.PrintStream Resolved class [ 65] HelloStream -> HelloStream Resolved class [ 85] HelloStream -> java.lang.invoke.LambdaMetafactory Resolved invokeinterface [ 19] HelloStream -> java.util.List.stream:()Ljava/util/stream/Stream; Resolved invokeinterface [ 27] HelloStream -> java.util.stream.Stream.filter:(Ljava/util/function/Predicate;)Ljava/util/stream/Stream; Resolved invokeinterface [ 41] HelloStream -> java.util.stream.Stream.collect:(Ljava/util/stream/Collector;)Ljava/lang/Object; Resolved invokevirtual [ 53] HelloStream -> java.io.PrintStream.println:(Ljava/lang/String;)V Resolved invokevirtual [ 61] HelloStream -> java.lang.String.contains:(Ljava/lang/CharSequence;)Z Resolved indy [ 23] HelloStream Skipping HelloStream: Unsupported location Hello Archiving CP entries for HelloStream$$Lambda+0x80000000e archived klass CP entry [ 2]: HelloStream$$Lambda+0x80000000e app => HelloStream$$Lambda+0x80000000e app archived klass CP entry [ 6]: HelloStream$$Lambda+0x80000000e app => java/lang/Object boot archived method CP entry [ 8]: HelloStream$$Lambda+0x80000000e java/lang/Object.:()V => java/lang/Object vs when EpisonGC is not used -- `HelloStream$$Lambda` is not archived: $ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:+UnlockExperimentalVMOptions -XX:-UseEpsilonGC -XX:AOTCache=app.aot -Xlog:cds+resolve=trace::none | grep Hello Resolved class [ 14] HelloStream -> java.util.List Resolved class [ 28] HelloStream -> java.util.stream.Stream Resolved class [ 36] HelloStream -> java.util.stream.Collectors Resolved class [ 45] HelloStream -> java.lang.String Resolved class [ 48] HelloStream -> java.lang.System Resolved class [ 54] HelloStream -> java.io.PrintStream Resolved class [ 65] HelloStream -> HelloStream Resolved class [ 85] HelloStream -> java.lang.invoke.LambdaMetafactory Resolved invokeinterface [ 19] HelloStream -> java.util.List.stream:()Ljava/util/stream/Stream; Resolved invokeinterface [ 27] HelloStream -> java.util.stream.Stream.filter:(Ljava/util/function/Predicate;)Ljava/util/stream/Stream; Resolved invokeinterface [ 41] HelloStream -> java.util.stream.Stream.collect:(Ljava/util/stream/Collector;)Ljava/lang/Object; Resolved invokevirtual [ 53] HelloStream -> java.io.PrintStream.println:(Ljava/lang/String;)V Resolved invokevirtual [ 61] HelloStream -> java.lang.String.contains:(Ljava/lang/CharSequence;)Z Resolved indy [ 23] HelloStream Skipping HelloStream: Unsupported location I'll investigate more and come up with a better fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23581#issuecomment-2654450406 From iklam at openjdk.org Wed Feb 12 17:57:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Feb 2025 17:57:11 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 09:58:46 GMT, Aleksey Shipilev wrote: > Reliably reproduces in current mainline, see the bug for reproducer. I think we are crashing after feeding `nullptr` to `class_category_name`. That `nullptr` is from `ArchiveBuilder::current()->get_buffered_addr` of `HelloStream`, which is skipped, as per warning message right before the crash. > > So it looks like the fix is to check if we are dealing with class that is available in the buffer before reaching for its buffered address. @iklam, see if this is a right fix? > > Additional testing: > - [x] Linux x86_64 server fastdebug, reproducer now passes > - [x] Linux x86_64 server fastdebug, `runtime/cds` passes @shipilev do you want me to take over this bug? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23581#issuecomment-2654457781 From shade at openjdk.org Wed Feb 12 18:06:26 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Feb 2025 18:06:26 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 17:54:36 GMT, Ioi Lam wrote: > @shipilev do you want me to take over this bug? Yes, please. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23581#issuecomment-2654478405 From shade at openjdk.org Wed Feb 12 18:10:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Feb 2025 18:10:16 GMT Subject: Withdrawn: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 09:58:46 GMT, Aleksey Shipilev wrote: > Reliably reproduces in current mainline, see the bug for reproducer. I think we are crashing after feeding `nullptr` to `class_category_name`. That `nullptr` is from `ArchiveBuilder::current()->get_buffered_addr` of `HelloStream`, which is skipped, as per warning message right before the crash. > > So it looks like the fix is to check if we are dealing with class that is available in the buffer before reaching for its buffered address. @iklam, see if this is a right fix? > > Additional testing: > - [x] Linux x86_64 server fastdebug, reproducer now passes > - [x] Linux x86_64 server fastdebug, `runtime/cds` passes This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23581 From shade at openjdk.org Wed Feb 12 19:17:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Feb 2025 19:17:19 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms Message-ID: See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. 2. Avoid timed-wait on Monitor, when a sleep would suffice. 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC -cp JavacBenchApp.jar JavacBenchApp 1 1 # Before Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] Range (min ? max): 489.8 ms ? 502.6 ms 100 runs # After Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] Range (min ? max): 479.8 ms ? 494.3 ms 100 runs Additional testing: - [ ] Linux x86_64 server fastdebug, `tier1` - [ ] Linux AArch64 server fastdebug, `all` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/23593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349927 Stats: 31 lines in 1 file changed: 15 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/23593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23593/head:pull/23593 PR: https://git.openjdk.org/jdk/pull/23593 From duke at openjdk.org Wed Feb 12 19:32:15 2025 From: duke at openjdk.org (Abdelhak Zaaim) Date: Wed, 12 Feb 2025 19:32:15 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:13:18 GMT, Aleksey Shipilev wrote: > See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: > 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. > 2. Avoid timed-wait on Monitor, when a sleep would suffice. > 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. > > I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: > > > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ > -cp JavacBenchApp.jar JavacBenchApp 1 1 > > # Before > Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] > Range (min ? max): 489.8 ms ? 502.6 ms 100 runs > > # After > Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] > Range (min ? max): 479.8 ms ? 494.3 ms 100 runs > > > Additional testing: > - [ ] Linux x86_64 server fastdebug, `tier1` > - [ ] Linux AArch64 server fastdebug, `all` Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23593#pullrequestreview-2612997667 From kvn at openjdk.org Wed Feb 12 20:21:13 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 12 Feb 2025 20:21:13 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero VM build It is ready for re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2654754643 From sspitsyn at openjdk.org Wed Feb 12 22:33:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Feb 2025 22:33:11 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 17:03:55 GMT, Patricio Chilano Mateo wrote: > I attached a patch in JBS that makes the crash easier to reproduce. Give it a try. Running the test with -Xint crashes for me in very few attempts. Thank you, Patricio! Will give it a try. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2654983513 From dholmes at openjdk.org Thu Feb 13 00:00:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Feb 2025 00:00:12 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 12:32:00 GMT, Johan Sj?len wrote: >> Also does this mean we are going to crash on the very first log_debug? You have two logging statements that will trigger the crash but only one of them can be reached with the way the testing is structured. > > You're right, we do crash on the very first log_debug we reach (when in debug mode) as this hits the `ShouldNotReachHere()`. Both can be reached, but when one has been reached the other one won't be reached. I think it's fine, we're simply trying to see whether the recursive logging case is handled correctly. > >> If we are going to crash we should add -XX:-CreateCoredumpOnCrash > > What's your thinking here? When a test knows it will crash we don't want to generate a coredump as we don't care about it. Dumping can take a significant time on some systems leading to timeouts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1953572561 From dholmes at openjdk.org Thu Feb 13 00:03:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Feb 2025 00:03:10 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 12:39:12 GMT, Johan Sj?len wrote: >> test/hotspot/jtreg/runtime/logging/AsyncDeathTestNonProduct.java line 39: >> >>> 37: import jdk.test.lib.process.OutputAnalyzer; >>> 38: >>> 39: public class AsyncDeathNonProduct { >> >> Did you mean to call this `AsyncDeathNonDebug` ?? >> >> You could just have one test file and two @test sections: one for debug and one for non-debug, then adapt the logic accordingly. But this non-debug version isn't verifying the correct execution of recursive logging in product mode, because there is no actual recursive logging being performed - this test isn't doing anything. You would need some product logging to actually verify that but then anything that did `-Xlog:all` would crash. So perhaps just delete this version of the test. > > I meant to call it `NonProduct`, and the rest of your message is confusing to me so I've probably misunderstood what my test does and what `NOT_PRODUCT` means :-). > > I've got: > > ```c++ > NOT_PRODUCT(log_debug(deathtest)("Induce a recursive log for testing");) > > > I thought `NON_PRODUCT` means that this is included regardless of `assert`s being enabled, but will not be shipped in a product build of the JDK. That's what I want to do, as that let's me test recursive logging without any asserts being triggered. > > I'll look into the test section suggestion. I've misunderstood your intention, but we only run tests on debug and product and your `@requires !vm.debug` means the test will run on product and it will do nothing because the log statements will not be there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1953574814 From cjplummer at openjdk.org Thu Feb 13 02:36:16 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Feb 2025 02:36:16 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero VM build src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118: > 116: } > 117: > 118: public static Class getClassFor(Address addr) { Did you consider using a lookup table here that is indexed using the kind value? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146: > 144: } > 145: } > 146: return null; Should this be an assert? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213: > 211: > 212: public boolean isUncommonTrapBlob() { > 213: if (!VM.getVM().isServerCompiler()) return false; Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95: > 93: } > 94: > 95: public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) { I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr". That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953665953 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953666268 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953667349 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953682557 From fyang at openjdk.org Thu Feb 13 03:14:10 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 13 Feb 2025 03:14:10 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 12 Feb 2025 20:24:05 GMT, Dean Long wrote: > > FYI: `test/hotspot/jtreg/compiler/jsr292/MHDeoptTest.java` and hs-tier1 test good on linux-riscv64 with fastdebug build. > > I good sanity check is to remove the fix in deoptimization.cpp and see if the new test triggers the new asserts. Yeah! The new test triggers if I revert the fix. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/ubuntu/jdk/src/hotspot/cpu/riscv/abstractInterpreter_riscv.cpp:145), pid=95195, tid=95217 # assert(locals >= interpreter_frame->sender_sp() + max_locals - 1) failed: bad placement # # JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-adhoc.ubuntu.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) # Problematic frame: # V [libjvm.so+0x2e1204] AbstractInterpreter::layout_activation(Method*, int, int, int, int, int, int, frame*, frame*, bool, bool)+0x3fa # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/ubuntu/jdk/build/linux-riscv64- server-fastdebug/test-support/jtreg_test_hotspot_jtreg_compiler_jsr292_MHDeoptTest_java/scratch/0/core.95195) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2655355838 From kvn at openjdk.org Thu Feb 13 03:43:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 03:43:17 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> Message-ID: <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com> On Thu, 13 Feb 2025 02:06:57 GMT, Chris Plummer wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero VM build > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118: > >> 116: } >> 117: >> 118: public static Class getClassFor(Address addr) { > > Did you consider using a lookup table here that is indexed using the kind value? Example please. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146: > >> 144: } >> 145: } >> 146: return null; > > Should this be an assert? I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213: > >> 211: >> 212: public boolean isUncommonTrapBlob() { >> 213: if (!VM.getVM().isServerCompiler()) return false; > > Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below? `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`. Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95: > >> 93: } >> 94: >> 95: public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) { > > I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr". That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);` `cbPc` with comment explaining that it could be inside code blob. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953732919 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953733212 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953738572 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953745389 From cjplummer at openjdk.org Thu Feb 13 05:22:14 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Feb 2025 05:22:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com> Message-ID: On Thu, 13 Feb 2025 03:26:19 GMT, Vladimir Kozlov wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118: >> >>> 116: } >>> 117: >>> 118: public static Class getClassFor(Address addr) { >> >> Did you consider using a lookup table here that is indexed using the kind value? > > Example please. static Class wrapperClasses = new Class[Number_Of_Kinds]; wrapperClasses[NMethodKind] = NMethodBlob.class; wrapperClasses[BufferKind] = BufferBopb.class; ...; wrapperClasses[SafepointKind] = SafepointBlob.class; CodeBlob cb = new CodeBlob(addr); return wrapperClasses[cb.getKind()]; >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146: >> >>> 144: } >>> 145: } >>> 146: return null; >> >> Should this be an assert? > > I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned. I guess my real question is whether or not it can be considered normal behavior to return null. It seems it should never happen, which is why I was suggesting an assert. >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213: >> >>> 211: >>> 212: public boolean isUncommonTrapBlob() { >>> 213: if (!VM.getVM().isServerCompiler()) return false; >> >> Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below? > > `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`. > Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect. Ok. Leaving UncommonTrapKind and ExceptionKind uninitialized seems a bit error prone. Perhaps they can be given some sort of INVALID value. >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95: >> >>> 93: } >>> 94: >>> 95: public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) { >> >> I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr". That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);` > > `cbPc` with comment explaining that it could be inside code blob. That sounds fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953818292 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953819796 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953821968 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953822595 From dholmes at openjdk.org Thu Feb 13 05:37:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Feb 2025 05:37:10 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms In-Reply-To: References: Message-ID: <_4JakTeBealYqZuf-mGmKFmY2ZjthbiYkOhTQaUph2E=.c9f6ade7-8757-4258-9751-cb304d42c5d0@github.com> On Wed, 12 Feb 2025 19:13:18 GMT, Aleksey Shipilev wrote: > See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: > 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. > 2. Avoid timed-wait on Monitor, when a sleep would suffice. > 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. > > I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: > > > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ > -cp JavacBenchApp.jar JavacBenchApp 1 1 > > # Before > Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] > Range (min ? max): 489.8 ms ? 502.6 ms 100 runs > > # After > Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] > Range (min ? max): 479.8 ms ? 494.3 ms 100 runs > > > Additional testing: > - [ ] Linux x86_64 server fastdebug, `tier1` > - [ ] Linux AArch64 server fastdebug, `all` Looks good and works in nicely with user thread changes. One suggested comment addition as I had to check the user-thread wait-time couldn't exceed the compiler thread wait-time. Thanks src/hotspot/share/runtime/vmOperations.cpp line 522: > 520: > 521: // Deadline for user threads in native code. > 522: // User-settable flag counts "attempts" in 10ms units. Suggestion: // User-settable flag counts "attempts" in 10ms units, to a maximum of 10s. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23593#pullrequestreview-2613889752 PR Review Comment: https://git.openjdk.org/jdk/pull/23593#discussion_r1953838705 From rrich at openjdk.org Thu Feb 13 06:52:10 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 13 Feb 2025 06:52:10 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 12 Feb 2025 21:11:36 GMT, Dean Long wrote: > I just pushed a fix for the s390 and ppc bounds check logic, but I'm still not sure if I am using the correct values for the end of the frame. Testing on ppc64 looks good so far. Will put the change through our CI testing. > The asserts should pass with the deoptimization.cpp fix. The 2nd assert should fail w/o the deoptimization.cpp fix when running the new test. The 2nd assert does not fail w/o the deoptimization.cpp fix. Might be due to alignement of caller->sp() in the interpreter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2655682065 From jrose at openjdk.org Thu Feb 13 07:44:19 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 13 Feb 2025 07:44:19 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero VM build I've read the code and it looks good. I find myself wishing for a few more comments to guide me, especially in knowing which methods to pay attention to, and which to ignore as "pure plumbing". The array of vptr-ptrs is the key element. It seems to work nicely. There are lots of regularizations here, which I enjoy. But the new code has (to me) distracting irregularities. Why define one Vptr as a struct and others as classes? Did we really regularize the names of all the print functions (they were irregular before)? I was glad to see lots of magic code deleted from SA. Although, having to look at SA at all is annoying! I noticed a lot of churn in "innocent bystander" client code that looks like this: p2i(_frame.pc()), decode_offset); - nm()->print_on(&ss); + nm()->print_on_v(&ss); nm()->method()->print_codes_on(&ss); What is the client maintainer (or any casual reader) supposed to get from the "_v" suffix? I know we have made the "v/nv" distinction before, but it is rather obscure, not documeted here. Is it described elsewhere in our code base? Our use of it here should be docuemented in codeBlob.hpp. Normally, we try to keep client APIs invariant while doing refactorings like this, so as to avoid touching all the client code. In this case, we have to use a new naming convention to distinguish all versions of (say) print_on: M. The implementation in each CB class K, which can be private if K::Vptr is a friend. P. The public API point, used outside of the CB classes, as well as inside. V. The name of the virtual function defined by each K::Vptr. I would expect I to have the "nice name" like print_on, not print_on_v, while while the private method M would be print_on_impl or print_on_nv, and never called except from Vptr or other methods of the same name. But any convention will work, as long as it is documented and held to consistently. I'm sympathetic to both Andrew's call for maacro-enforced regularity, and Vladimir's objection that macros make things hard to follow. If macros won't work for us here, let's define a documented pattern and stick to it closely, documenting our decisions as we go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2655760868 From shade at openjdk.org Thu Feb 13 08:28:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 13 Feb 2025 08:28:55 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms [v2] In-Reply-To: References: Message-ID: <-5ISvMWwjahG3KPjkFyDW27DFdlr8As3X2qZ6cV7N9Q=.6898a52b-7e82-4dbf-b082-7dcea380336d@github.com> > See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: > 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. > 2. Avoid timed-wait on Monitor, when a sleep would suffice. > 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. > > I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: > > > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ > -cp JavacBenchApp.jar JavacBenchApp 1 1 > > # Before > Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] > Range (min ? max): 489.8 ms ? 502.6 ms 100 runs > > # After > Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] > Range (min ? max): 479.8 ms ? 494.3 ms 100 runs > > > Additional testing: > - [x] Linux x86_64 server fastdebug, `tier1` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/vmOperations.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23593/files - new: https://git.openjdk.org/jdk/pull/23593/files/31696b1c..a656380a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23593&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23593&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23593/head:pull/23593 PR: https://git.openjdk.org/jdk/pull/23593 From shade at openjdk.org Thu Feb 13 08:28:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 13 Feb 2025 08:28:56 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms [v2] In-Reply-To: <_4JakTeBealYqZuf-mGmKFmY2ZjthbiYkOhTQaUph2E=.c9f6ade7-8757-4258-9751-cb304d42c5d0@github.com> References: <_4JakTeBealYqZuf-mGmKFmY2ZjthbiYkOhTQaUph2E=.c9f6ade7-8757-4258-9751-cb304d42c5d0@github.com> Message-ID: On Thu, 13 Feb 2025 05:32:57 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/runtime/vmOperations.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > src/hotspot/share/runtime/vmOperations.cpp line 522: > >> 520: >> 521: // Deadline for user threads in native code. >> 522: // User-settable flag counts "attempts" in 10ms units. > > Suggestion: > > // User-settable flag counts "attempts" in 10ms units, to a maximum of 10s. Accepted! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23593#discussion_r1954033614 From aboldtch at openjdk.org Thu Feb 13 08:32:21 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 13 Feb 2025 08:32:21 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix Zero VM build Similar to what @rose00 noted I think the `_v` and `_nv` suffixes are unfortunate in the public API. Maybe it we could add a protected `x_impl` containing the implementation, then dispatch to the correct one based on _kind, using the Vptr abstraction. And have the normal print_on method use this. We could let our leaf types to directly call the specific implementation, not that I think that our print functions require compile time devirtualisation. There are many solutions here with their pros and cons. src/hotspot/share/code/codeBlob.hpp line 140: > 138: instance->print_value_on_nv(st); > 139: } > 140: }; I wonder why the base class is not abstract. AFAICT `print_value_on` is unreachable and `print_on` is only used by `DeoptimizationBlob::Vptr` which also seems like a behavioural change, as before this patch calling `print_on` a `DeoptimizationBlob` object would dispatch to `SingletonBlob::print_on` not `CodeBlob::print_on`. Suggestion: struct Vptr { virtual void print_on(const CodeBlob* instance, outputStream* st) const = 0; virtual void print_value_on(const CodeBlob* instance, outputStream* st) const = 0; }; src/hotspot/share/code/codeBlob.hpp line 339: > 337: void print_value_on(outputStream* st) const; > 338: > 339: class Vptr : public CodeBlob::Vptr { I wonder if these should share the same type hierarchy as tier container class. This would also solve the issueI noted in my other comment about not calling the correct `print_on`. Suggestion: class Vptr : public RuntimeBlob::Vptr { src/hotspot/share/code/codeBlob.hpp line 427: > 425: void print_value_on(outputStream* st) const; > 426: > 427: class Vptr : public CodeBlob::Vptr { Suggestion: class Vptr : public RuntimeBlob::Vptr { src/hotspot/share/code/codeBlob.hpp line 467: > 465: void print_value_on(outputStream* st) const; > 466: > 467: class Vptr : public CodeBlob::Vptr { Suggestion: class Vptr : public RuntimeBlob::Vptr { src/hotspot/share/code/codeBlob.hpp line 553: > 551: void print_value_on(outputStream* st) const; > 552: > 553: class Vptr : public CodeBlob::Vptr { This one specifically Suggestion: class Vptr : public SingletonBlob::Vptr { src/hotspot/share/code/codeBlob.hpp line 679: > 677: void print_value_on(outputStream* st) const; > 678: > 679: class Vptr : public CodeBlob::Vptr { Suggestion: class Vptr : public RuntimeBlob::Vptr { ------------- PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2614177723 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954019308 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954024528 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954028620 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954028940 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954027733 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954029504 From mbaesken at openjdk.org Thu Feb 13 08:34:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Feb 2025 08:34:14 GMT Subject: RFR: 8346661: Add a register print helper method and unify register printing In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 16:47:24 GMT, Thomas Stuefe wrote: > > I think it is very difficult to handle the formatting alignment/indentation when using a per-register helper this way. But I also don't think it is worth the trouble of trying to write a print function that takes a set of registers and their descriptions and figures out maximum name lengths etc to get that layout correct. > > To be honest the bang-for-buck here seems too low to be worthwhile IMO. > > I agree. The intention is good, but the savings are not that large IMHO. Hi Thomas , I had planned to use this little refactoring to have a central method where it is easy to add coding at one central single place. E.g. for highlighting special 'interesting' values like mem corruption patterns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22894#issuecomment-2655866140 From azafari at openjdk.org Thu Feb 13 09:31:08 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 13 Feb 2025 09:31:08 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v4] In-Reply-To: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> Message-ID: > The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. > Some compilers do not mask the shift value to the base size and UBSAN catches the case. > In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: count member is removed. Axel's suggestion is implemented. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22807/files - new: https://git.openjdk.org/jdk/pull/22807/files/00239755..442818d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22807&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22807&range=02-03 Stats: 11 lines in 2 files changed: 1 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22807/head:pull/22807 PR: https://git.openjdk.org/jdk/pull/22807 From jsjolen at openjdk.org Thu Feb 13 09:45:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 09:45:10 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Wed, 12 Feb 2025 23:57:34 GMT, David Holmes wrote: >> You're right, we do crash on the very first log_debug we reach (when in debug mode) as this hits the `ShouldNotReachHere()`. Both can be reached, but when one has been reached the other one won't be reached. I think it's fine, we're simply trying to see whether the recursive logging case is handled correctly. >> >>> If we are going to crash we should add -XX:-CreateCoredumpOnCrash >> >> What's your thinking here? > > When a test knows it will crash we don't want to generate a coredump as we don't care about it. Dumping can take a significant time on some systems leading to timeouts. Thanks David, I missed the `-` and was under the pretension that we don't create coredumps by default :). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1954164233 From jsjolen at openjdk.org Thu Feb 13 09:45:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 09:45:10 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v7] In-Reply-To: References: <6TkF0YwEQ3Gd6_5bqSYPnDDaeelCkgRdTcxtsZTzkbk=.176dc78e-6dee-49ad-9ebb-a5fcf5bf8fe5@github.com> Message-ID: On Thu, 13 Feb 2025 00:00:54 GMT, David Holmes wrote: >> I meant to call it `NonProduct`, and the rest of your message is confusing to me so I've probably misunderstood what my test does and what `NOT_PRODUCT` means :-). >> >> I've got: >> >> ```c++ >> NOT_PRODUCT(log_debug(deathtest)("Induce a recursive log for testing");) >> >> >> I thought `NON_PRODUCT` means that this is included regardless of `assert`s being enabled, but will not be shipped in a product build of the JDK. That's what I want to do, as that let's me test recursive logging without any asserts being triggered. >> >> I'll look into the test section suggestion. > > I've misunderstood your intention, but we only run tests on debug and product and your `@requires !vm.debug` means the test will run on product and it will do nothing because the log statements will not be there. Aha, I see. Well, I think that I can re-work the code that let's us test it to accommodate for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1954163312 From stuefe at openjdk.org Thu Feb 13 10:03:11 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 13 Feb 2025 10:03:11 GMT Subject: RFR: 8346661: Add a register print helper method and unify register printing In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 08:31:10 GMT, Matthias Baesken wrote: > > > I think it is very difficult to handle the formatting alignment/indentation when using a per-register helper this way. But I also don't think it is worth the trouble of trying to write a print function that takes a set of registers and their descriptions and figures out maximum name lengths etc to get that layout correct. > > > To be honest the bang-for-buck here seems too low to be worthwhile IMO. > > > > > > I agree. The intention is good, but the savings are not that large IMHO. > > Hi Thomas , I had planned to use this little refactoring to have a central method where it is easy to add coding at one central single place. E.g. for highlighting special 'interesting' values like mem corruption patterns. Okay, good. Just send the PR when its done. Will that replace this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22894#issuecomment-2656083713 From jsjolen at openjdk.org Thu Feb 13 10:10:33 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 10:10:33 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v9] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/async-logging-thread-should-not-recur' into async-logging-thread-should-not-recur - Perform ugly hack in order to test both cases. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/8663ebcb..57ea3afa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=07-08 Stats: 73 lines in 6 files changed: 21 ins; 46 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Thu Feb 13 10:13:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 10:13:53 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v10] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: No longer necessary to have a Debug suffix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/57ea3afa..cbd809d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Thu Feb 13 10:18:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 10:18:50 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v11] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/cbd809d2..b9265a51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=09-10 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Thu Feb 13 10:22:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 10:22:52 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v12] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/b9265a51..8eb89123 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Thu Feb 13 10:26:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 10:26:52 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v13] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Wow :-) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/8eb89123..50b4c553 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From mbaesken at openjdk.org Thu Feb 13 12:57:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Feb 2025 12:57:15 GMT Subject: RFR: 8346661: Add a register print helper method and unify register printing In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 10:00:18 GMT, Thomas Stuefe wrote: > Okay, good. Just send the PR when its done. Will that replace this PR? My idea was to split it into this one, and later a follow up. Not sure how I proceed here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22894#issuecomment-2656514673 From jsjolen at openjdk.org Thu Feb 13 13:48:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 13:48:03 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v14] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - We ran pb again, and not pb2. - Only log the message in single-log messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/50b4c553..5a9d3de3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=12-13 Stats: 8 lines in 2 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Thu Feb 13 14:16:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 14:16:14 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v14] In-Reply-To: References: Message-ID: <5WTltYtjkfiQ6ZtKukCDHXctwUR4Uqsa9gkLQbu_CIs=.b826513b-8c31-445b-9274-e0e051a2c2a9@github.com> On Thu, 13 Feb 2025 13:48:03 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - We ran pb again, and not pb2. > - Only log the message in single-log messages Alright, So I fixed the tests. The way I implemented the testing is a bit of a hack, but at least it's a local-to-UL hack.The checking function needs to know whether to crash or not and instead handle the message. In order to inform the function of this, we set a static bool variable to `true` earlier in the call stack. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23513#issuecomment-2656722215 From azafari at openjdk.org Thu Feb 13 15:26:10 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 13 Feb 2025 15:26:10 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v23] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: flag/type -> tag chages are removed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/35c11b96..611a2d4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=21-22 Stats: 53 lines in 13 files changed: 0 ins; 0 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From kvn at openjdk.org Thu Feb 13 17:05:04 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:05:04 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v7] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <5LGcbNB2_MigrbHGKV3CY8e6z-1iioFUuiSvTU8-lNY=.af273d17-6ab5-4b12-ae41-e6900494b5ee@github.com> > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Update SA based on comments - Merge branch 'master' into 8349088 - Fix Zero VM build - Fix Minimal and Zero VM builds once more - Fix Minimal and Zero VM builds again - Add CodeBlob proxy vtable - Fix Zero and Minimal VM builds - 8349088: De-virtualize Codeblob and nmethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/b09ddce6..515495b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=05-06 Stats: 11482 lines in 618 files changed: 7914 ins; 1738 del; 1830 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From kvn at openjdk.org Thu Feb 13 17:05:05 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:05:05 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com> Message-ID: On Thu, 13 Feb 2025 05:14:59 GMT, Chris Plummer wrote: >> Example please. > > static Class wrapperClasses = new Class[Number_Of_Kinds]; > wrapperClasses[NMethodKind] = NMethodBlob.class; > wrapperClasses[BufferKind] = BufferBopb.class; > ...; > wrapperClasses[SafepointKind] = SafepointBlob.class; > > > > CodeBlob cb = new CodeBlob(addr); > return wrapperClasses[cb.getKind()]; Done. >> I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned. > > I guess my real question is whether or not it can be considered normal behavior to return null. It seems it should never happen, which is why I was suggesting an assert. With your suggested `wrapperClasses[]` we will get OOB exception. No need separate assert. >> `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`. >> Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect. > > Ok. Leaving UncommonTrapKind and ExceptionKind uninitialized seems a bit error prone. Perhaps they can be given some sort of INVALID value. Done. Initialized them to `Number_Of_Kinds + 1`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954886028 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954890522 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954891616 From kvn at openjdk.org Thu Feb 13 17:14:59 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:14:59 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: rename SA argument ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/515495b2..61fdee68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=06-07 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From kvn at openjdk.org Thu Feb 13 17:14:59 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:14:59 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com> <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com> Message-ID: On Thu, 13 Feb 2025 05:19:48 GMT, Chris Plummer wrote: >> `cbPc` with comment explaining that it could be inside code blob. > > That sounds fine. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954906986 From cjplummer at openjdk.org Thu Feb 13 17:14:59 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Feb 2025 17:14:59 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 10 Feb 2025 16:57:18 GMT, Vladimir Kozlov wrote: >>> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes. >> >> I don't need any more mapping from CodeBlob class to corresponding virtual table name which does not exist anymore. `CodeBlob::_kind` field's value is used to determine which class should be used. >> >> I think `hashMap` is overkill here. I can construct array `Class cbClasses[]` and use `cbClasses[CodeBlob::_kind]` instead of `if/else` in `getClassFor`. But I would still need to check for unknown value of `CodeBlob::_kind` somehow. > >> impact on things like the "findpc" functionality > > Do you mean `findpc()` function in VM which is used in debugger? Nothing should be changed for it. > It calls `os::print_location()` which calls `CodeBlob::dump_for_addr(addr, st, verbose);`: > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/os.cpp#L1278 Actually I was referring to the clhsdb findpc command, which uses PointerFinder, but actually that should be ok because it special cases the codecache and knows how to find CodeBlobs in it. It's the clhsdb "inspect" command that will no longer be able to identify the type for an address that points to the start of a CodeBlob. This is true of any address that points to the start of a hotspot C++ object that does not have a vtable, or is not declared in vmstructs. So it's not a new issue, but is just adding more types to the list that "inspect" won't figure out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954906641 From jrose at openjdk.org Thu Feb 13 17:25:13 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 13 Feb 2025 17:25:13 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument One related idea: The Vptr classes seem to be regular enough to be templated. That is, one class body, instantiated with a template argument for each code blob type (and probably another for the enum). That would remove some of the distracting per-class boilerplate. Something like: template class Vptr_Impl : public Vptr { override void print_on(const CodeBlob* instance, outputStream* st) const { assert(instance->kind() == Tkind, "sanity"); ((const CB_T*)instance)->print_on_impl(st); } ? override bool assert_sane(cosnt CodeBlob* instance) { assert(instance->kind() == Tkind, ""); return true; } }; class CodeBlob { public: final Vptr* vptr() const { Vptr* vptr = vptr_array[_kind]; assert(vptr->assert_sant(this), "correct array element"); return vptr; } final void print_on(outputStream* st) const { vptr()->print_on(this, st); } }; Then: const Vptr* array[] = { &Vptr_Impl(), ... &Vptr_Impl(), ... }; The array could be filled by a macro that tracks the enum members; I like that as a small job for macros (no code in it). Then: class UncommonTrapBlob : public OtherBlob { protected: // impl "M" method is not public void print_on_impl(outputStream* st) const { OtherBlob::print_on_impl(st); st->print("my field = %d", _my_field); } // Vptr needs to call impl method friend class Vptr_Impl; // this might break down, so make it all public in the end }; I don't see any reason the Vptr subclasses need to be related in any more detail as subs or supers. Well, C++ is a bag of surprises, so there are probably several reasons the above sketch is wrong. But something like it might add a little more readability and predictability to the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657274388 From kvn at openjdk.org Thu Feb 13 17:29:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:29:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:22:18 GMT, John R Rose wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> rename SA argument > > One related idea: The Vptr classes seem to be regular enough to be templated. That is, one class body, instantiated with a template argument for each code blob type (and probably another for the enum). That would remove some of the distracting per-class boilerplate. Something like: > > > template > class Vptr_Impl : public Vptr { > override void print_on(const CodeBlob* instance, outputStream* st) const { > assert(instance->kind() == Tkind, "sanity"); > ((const CB_T*)instance)->print_on_impl(st); > } > ? > override bool assert_sane(cosnt CodeBlob* instance) { > assert(instance->kind() == Tkind, ""); > return true; > } > }; > > class CodeBlob { > public: > final Vptr* vptr() const { > Vptr* vptr = vptr_array[_kind]; > assert(vptr->assert_sant(this), "correct array element"); > return vptr; > } > final void print_on(outputStream* st) const { > vptr()->print_on(this, st); > } > }; > > > Then: > > > const Vptr* array[] = { > &Vptr_Impl(), > ... > &Vptr_Impl(), > ... > }; > > > The array could be filled by a macro that tracks the enum members; I like that as a small job for macros (no code in it). > > Then: > > > class UncommonTrapBlob : public OtherBlob { > protected: // impl "M" method is not public > void print_on_impl(outputStream* st) const { > OtherBlob::print_on_impl(st); > st->print("my field = %d", _my_field); > } > // Vptr needs to call impl method > friend class Vptr_Impl; // this might break down, so make it all public in the end > }; > > > I don't see any reason the Vptr subclasses need to be related in any more detail as subs or supers. > > Well, C++ is a bag of surprises, so there are probably several reasons the above sketch is wrong. But something like it might add a little more readability and predictability to the code. Thank you, @rose00 and @xmas92, for review and suggestions. Let me say it first - printing code for code blobs and nmethod is big mess. It requires separate big change to clean it up. For example, I have to go through CodeBlob's virtual dispatch `print_value_on_v()` for nmethod because some sets of `nmethod::print*()` are defined only in debug VM: [nmethod.hpp#L919](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.hpp#L919) Then `nmethod` has other mess which requires C++ trickery because it does not follow print API in CodeBlob: void print(outputStream* st) const; // need to re-define this from CodeBlob else the overload hides it void print_on(outputStream* st) const override { CodeBlob::print_on(st); } void print_on(outputStream* st, const char* msg) const; ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657282969 From kvn at openjdk.org Thu Feb 13 17:37:19 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 17:37:19 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument Saying that, I agree that I need to add comments explaining printing API and how Vptr class will work. I will work on @xmas92 suggestions and look on using `_impl`. I will try to look on templates @rose00 suggested but I don't want to complicate code for just for few print methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657303967 From sspitsyn at openjdk.org Thu Feb 13 17:37:27 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Feb 2025 17:37:27 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: - removed obsolete fragment that was not removed in last update - review: re-fixed the issue as initial fix was wrong ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23490/files - new: https://git.openjdk.org/jdk/pull/23490/files/f8860b4b..c36f3188 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=00-01 Stats: 26 lines in 3 files changed: 4 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490 PR: https://git.openjdk.org/jdk/pull/23490 From sspitsyn at openjdk.org Thu Feb 13 17:41:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Feb 2025 17:41:12 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:37:27 GMT, Serguei Spitsyn wrote: >> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp endThread()` and others are returned. For instance, some `SingleStep` events can be posted. >> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. >> >> Testing: >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: > > - removed obsolete fragment that was not removed in last update > - review: re-fixed the issue as initial fix was wrong I've pushed updated which rolls back the initial fix and implements a right approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2657311343 From iklam at openjdk.org Thu Feb 13 17:50:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 13 Feb 2025 17:50:26 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" Message-ID: When running HotSpot jtreg tests in the "AOT mode", for example: make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. ** Changes in this PR ** This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, ------------- Commit messages: - 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" Changes: https://git.openjdk.org/jdk/pull/23620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349953 Stats: 97 lines in 3 files changed: 74 ins; 16 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From kvn at openjdk.org Thu Feb 13 18:04:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 18:04:17 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <3RrosS3Q-iEBqaD4hVGMfjY2hDGLqwWwSUqgT0Za1k4=.1e32f3f0-6677-4082-b100-ce9b4603ec80@github.com> On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument > AFAICT `print_value_on` is unreachable It is reachable in product VM when `print_value_on_v()` is called for `nmethod` which does not have `print_value_on()` in product VM. Which can be solved by adding simple `nmethod::print_value_on()` for product VM but it will change current behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657354310 From kvn at openjdk.org Thu Feb 13 18:21:13 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 13 Feb 2025 18:21:13 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms [v2] In-Reply-To: <-5ISvMWwjahG3KPjkFyDW27DFdlr8As3X2qZ6cV7N9Q=.6898a52b-7e82-4dbf-b082-7dcea380336d@github.com> References: <-5ISvMWwjahG3KPjkFyDW27DFdlr8As3X2qZ6cV7N9Q=.6898a52b-7e82-4dbf-b082-7dcea380336d@github.com> Message-ID: <09uAgXhQxbmRLO3sOPqIzVinz7DUxgrNqS9lYac2IbE=.b7b3dd59-7c27-44b6-bb28-70c73d288391@github.com> On Thu, 13 Feb 2025 08:28:55 GMT, Aleksey Shipilev wrote: >> See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: >> 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. >> 2. Avoid timed-wait on Monitor, when a sleep would suffice. >> 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. >> >> I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: >> >> >> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ >> -cp JavacBenchApp.jar JavacBenchApp 1 1 >> >> # Before >> Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] >> Range (min ? max): 489.8 ms ? 502.6 ms 100 runs >> >> # After >> Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] >> Range (min ? max): 479.8 ms ? 494.3 ms 100 runs >> >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `tier1` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/vmOperations.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23593#pullrequestreview-2615881608 From vlivanov at openjdk.org Thu Feb 13 19:01:21 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 13 Feb 2025 19:01:21 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 12 Feb 2025 21:09:31 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix bounds checks src/hotspot/share/runtime/deoptimization.cpp line 645: > 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); > 644: Bytecode_invoke cur = Bytecode_invoke_check(method, deopt_sender.interpreter_frame_bci()); > 645: if (cur.is_invokedynamic() || cur.is_invokehandle()) { Can you elaborate, please, why invokedynamic case is not needed anymore? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1955062378 From cjplummer at openjdk.org Thu Feb 13 19:31:15 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Feb 2025 19:31:15 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 97: > 95: // cbAddr - address of a code blob > 96: // cbPC - address inside of a code blob > 97: public CodeBlob createCodeBlobWrapper(Address cbAddr, Address cbPC) { Can you change findBlobUnsafe() above also? That's where the naming problem originated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955098013 From erikj at openjdk.org Thu Feb 13 19:44:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 13 Feb 2025 19:44:17 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:45:45 GMT, Ioi Lam wrote: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, make/RunTests.gmk line 734: > 732: $$(call MakeDir, $$($1_TEST_SUPPORT_DIR)/aot) > 733: > 734: $(info AOT: Create cache configuration) \ Please use logging framework for any messages. To get something to print by default `$(call LogWarn, ...). While here, please also clean up the left over debug $$(info ) left over further down in this file that we weren't able to point out in the original review. make/RunTests.gmk line 737: > 735: $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/aot, ( \ > 736: $(CD) $$($1_AOT_JDK_DIR); \ > 737: $(JDK_UNDER_TEST)/bin/javac -d . $(TOPDIR)/make/test/SetupAot.java; \ This is putting the compilation output in the current directory, which is the make directory in the workspace. That's not acceptable. Since this is a single class java program, would it be possible to just run it without compilation or would that interfere with the intended behavior? Otherwise it needs to be moved to somewhere else, under `$$($1_TEST_SUPPORT_DIR)`. I don't like that the compilation is run in the same recipe as the java command running the tool. At the very least those should be split into separate recipes, with separate ExecuteWithLog calls. A cleaner and preferred solution would be to build this tool as part of the test image so we avoid having to compile code during test setup. make/RunTests.gmk line 741: > 739: -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \ > 740: -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \ > 741: SetupAot \ Please use 4 spaces indent to follow the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html). Suggestion: $$(FIXPATH) $(JDK_UNDER_TEST)/bin/java $$($1_VM_OPTIONS) \ -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \ -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \ SetupAot \ make/RunTests.gmk line 744: > 742: )) > 743: > 744: $$(info AOT: Generate AOT cache $$($1_AOT_JDK_CACHE) with flags: $$($1_VM_OPTIONS)) Again, please use the logging framework. In this case I would recommend `$(call LogInfo, ...)` to reduce spam on the default level. I think one line is enough on warn level for indicating that AOT preparation is taking place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955089073 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955114393 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955094235 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955090525 From shade at openjdk.org Thu Feb 13 20:09:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 13 Feb 2025 20:09:17 GMT Subject: RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms [v2] In-Reply-To: <-5ISvMWwjahG3KPjkFyDW27DFdlr8As3X2qZ6cV7N9Q=.6898a52b-7e82-4dbf-b082-7dcea380336d@github.com> References: <-5ISvMWwjahG3KPjkFyDW27DFdlr8As3X2qZ6cV7N9Q=.6898a52b-7e82-4dbf-b082-7dcea380336d@github.com> Message-ID: <4NvKgpVWdBu88LJUt7TuA8w-cZj3CCA3dOCTjf-HO9A=.6f7c8381-f15f-4db3-b6fb-a9573ff6013c@github.com> On Thu, 13 Feb 2025 08:28:55 GMT, Aleksey Shipilev wrote: >> See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: >> 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. >> 2. Avoid timed-wait on Monitor, when a sleep would suffice. >> 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. >> >> I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: >> >> >> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ >> -cp JavacBenchApp.jar JavacBenchApp 1 1 >> >> # Before >> Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] >> Range (min ? max): 489.8 ms ? 502.6 ms 100 runs >> >> # After >> Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] >> Range (min ? max): 479.8 ms ? 494.3 ms 100 runs >> >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `tier1` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/vmOperations.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Thanks! Testing looks fine here, so I am integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23593#issuecomment-2657602580 From shade at openjdk.org Thu Feb 13 20:09:18 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 13 Feb 2025 20:09:18 GMT Subject: Integrated: 8349927: Waiting for compiler termination delays shutdown for 10+ ms In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:13:18 GMT, Aleksey Shipilev wrote: > See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: > 1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier. > 2. Avoid timed-wait on Monitor, when a sleep would suffice. > 3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy. > > I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time: > > > Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \ > -cp JavacBenchApp.jar JavacBenchApp 1 1 > > # Before > Time (mean ? ?): 495.4 ms ? 2.4 ms [User: 1321.2 ms, System: 110.4 ms] > Range (min ? max): 489.8 ms ? 502.6 ms 100 runs > > # After > Time (mean ? ?): 485.4 ms ? 2.7 ms [User: 1318.9 ms, System: 110.3 ms] > Range (min ? max): 479.8 ms ? 494.3 ms 100 runs > > > Additional testing: > - [x] Linux x86_64 server fastdebug, `tier1` > - [x] Linux AArch64 server fastdebug, `all` This pull request has now been integrated. Changeset: d8fcd43a Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/d8fcd43a24a989b71ed30945fda78541c1e42b60 Stats: 31 lines in 1 file changed: 15 ins; 4 del; 12 mod 8349927: Waiting for compiler termination delays shutdown for 10+ ms Reviewed-by: kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23593 From jsjolen at openjdk.org Thu Feb 13 20:33:33 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 13 Feb 2025 20:33:33 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v15] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Change name as per Axel's request ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/5a9d3de3..a7431d22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=13-14 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From dholmes at openjdk.org Thu Feb 13 21:00:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Feb 2025 21:00:13 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' In-Reply-To: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> Message-ID: On Mon, 10 Feb 2025 10:20:08 GMT, Afshin Zafari wrote: > The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. Changes requested by dholmes (Reviewer). src/hotspot/share/classfile/verifier.cpp line 2042: > 2040: unsigned int tag = cp->tag_at(index).value(); > 2041: // Resolution errors start with JVM_CONSTANT_InternalMin = 100, which is not valid for shift op > 2042: if (tag >= JVM_CONSTANT_InternalMin || (types & (1 << tag)) == 0) { Suggestion: if (tag > JVM_CONSTANT_ExternalMax || (types & (1 << tag)) == 0) { This excludes the possibility of having a corrupt/bad tag > 32 but < 100 ------------- PR Review: https://git.openjdk.org/jdk/pull/23539#pullrequestreview-2616203829 PR Review Comment: https://git.openjdk.org/jdk/pull/23539#discussion_r1955203130 From dlong at openjdk.org Thu Feb 13 21:23:15 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 13 Feb 2025 21:23:15 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: <7xJgm0ScXMp4iRaH7Sf5QfsrTv2jOV4078kPqn3aoCs=.63303086-b4bd-47c5-9bd5-e69e28f75f4c@github.com> On Thu, 13 Feb 2025 18:57:24 GMT, Vladimir Ivanov wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> fix bounds checks > > src/hotspot/share/runtime/deoptimization.cpp line 645: > >> 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); >> 644: Bytecode_invoke cur = Bytecode_invoke_check(method, deopt_sender.interpreter_frame_bci()); >> 645: if (cur.is_invokedynamic() || cur.is_invokehandle()) { > > Can you elaborate, please, why invokedynamic case is not needed anymore? As far as I can tell, it was never needed. If an invokedynamic or invokehandle adds an appendix, then it will show up in the callee, and will be reflected in the caller args size, so there is no mismatch. As far as the JVM is concerned, an invokedynamic/invokehandle looks like a call to a JVM-generated adapter. The only way for invokedynamic/invokehandle to cause an argument mismatch is if the JVM resolved the call-site to an adapter that was actually a MethodHandle linker. That is the exception I describe in the comment below. If we ever allowed the JVM to do that, then several other checks would also need to be fixed. For the record, this code used to call cur.is_method_handle_invoke(), which was also wrong, but at least it had a name closer to what we would want. Ideally, something like is_method_handle_linker_invoke() that checks for linkToVirtual, linkToStatic, linkToSpecial, and linkToInterface would have been better. The old comment about "arbitrary chains of calls" seems to be left over from an early JSR292 feature known as Ricochet Frames. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1955228726 From dlong at openjdk.org Thu Feb 13 21:26:12 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 13 Feb 2025 21:26:12 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: <7xJgm0ScXMp4iRaH7Sf5QfsrTv2jOV4078kPqn3aoCs=.63303086-b4bd-47c5-9bd5-e69e28f75f4c@github.com> References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> <7xJgm0ScXMp4iRaH7Sf5QfsrTv2jOV4078kPqn3aoCs=.63303086-b4bd-47c5-9bd5-e69e28f75f4c@github.com> Message-ID: On Thu, 13 Feb 2025 21:20:33 GMT, Dean Long wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 645: >> >>> 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); >>> 644: Bytecode_invoke cur = Bytecode_invoke_check(method, deopt_sender.interpreter_frame_bci()); >>> 645: if (cur.is_invokedynamic() || cur.is_invokehandle()) { >> >> Can you elaborate, please, why invokedynamic case is not needed anymore? > > As far as I can tell, it was never needed. If an invokedynamic or invokehandle adds an appendix, then it will show up in the callee, and will be reflected in the caller args size, so there is no mismatch. As far as the JVM is concerned, an invokedynamic/invokehandle looks like a call to a JVM-generated adapter. The only way for invokedynamic/invokehandle to cause an argument mismatch is if the JVM resolved the call-site to an adapter that was actually a MethodHandle linker. That is the exception I describe in the comment below. If we ever allowed the JVM to do that, then several other checks would also need to be fixed. > For the record, this code used to call cur.is_method_handle_invoke(), which was also wrong, but at least it had a name closer to what we would want. Ideally, something like is_method_handle_linker_invoke() that checks for linkToVirtual, linkToStatic, linkToSpecial, and linkToInterface would have been better. > The old comment about "arbitrary chains of calls" seems to be left over from an early JSR292 feature known as Ricochet Frames. For the curious, it is still possible create an arbitrarily long chain of linkTo calls, but only trusted code would be able to do that, so I'm not addressing this issue in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1955232327 From dlong at openjdk.org Thu Feb 13 21:35:12 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 13 Feb 2025 21:35:12 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: <_jQq0sGaZijMT6Cr3rUdrQLlvVWNuJ8uILHg1qkCxoM=.271ce257-9e72-4d61-87fa-588ce4dbe107@github.com> On Thu, 13 Feb 2025 06:49:50 GMT, Richard Reingruber wrote: > The 2nd assert does not fail w/o the deoptimization.cpp fix. Might be due to alignement of caller->sp() in the interpreter. Aarch64 also does alignment, and that's why the test uses two different methods, one with an extra local, to hopefully handle both cases of even/odd 2-word (16 byte) alignment. But ppc might be different enough that this isn't enough to trigger the bug. Or maybe the end of frame bound is slightly off? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2657755434 From dlong at openjdk.org Thu Feb 13 22:50:17 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 13 Feb 2025 22:50:17 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/c1/Runtime1.java line 65: > 63: public CodeBlob blobFor(int id) { > 64: Address blobAddr = blobsField.getStaticFieldAddress().getAddressAt(id * VM.getVM().getAddressSize()); > 65: return VM.getVM().getCodeCache().createCodeBlobWrapper(blobAddr); We don't need to change all the callers if we keep a 1-arg version of createCodeBlobWrapper(): public CodeBlob createCodeBlobWrapper(Address codeBlobAddr) { return createCodeBlobWrapper(codeBlobAddr, codeBlobAddr); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955316582 From pchilanomate at openjdk.org Thu Feb 13 22:59:13 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 13 Feb 2025 22:59:13 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:37:27 GMT, Serguei Spitsyn wrote: >> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp endThread()` and others are returned. For instance, some `SingleStep` events can be posted. >> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. >> >> Testing: >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: > > - removed obsolete fragment that was not removed in last update > - review: re-fixed the issue as initial fix was wrong Right, this is the fix I was thinking about initially. We can always create a test where a suspended target posts an event though, because the target can be seen as handshake-safe after switching to native in `JvmtiJavaThreadEventTransition`. So this fix would prevent posting events enabled after suspension (like this test is doing) but not before. This latter case would not be easy to fix since a callback is executed in native and we allow suspending in such state. Now, I thought suspend only implied the target cannot execute new Java bytecodes (can?t find the precise definition in the JVMTI specs). If that?s the case, why is this a bug in the VM and not a test issue? Or is this a case of still following the specs but trying to do the saner thing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2657881427 From dlong at openjdk.org Thu Feb 13 23:04:17 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 13 Feb 2025 23:04:17 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument src/hotspot/share/compiler/oopMap.cpp line 567: > 565: fr->print_on(tty); > 566: tty->print(" "); > 567: cb->print_value_on(tty); tty->cr(); We could minimize the number of files changed if we keep print_value_on() for compatibility: void print_value_on(outputStream* st) const { print_value_on_v(st); } src/hotspot/share/runtime/vframe.inline.hpp line 178: > 176: INTPTR_FORMAT " not found or invalid at %d", > 177: p2i(_frame.pc()), decode_offset); > 178: nm()->print_on_v(&ss); I suggest removing _v suffix to reduce changes and match existing naming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955325657 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955327438 From dlong at openjdk.org Fri Feb 14 00:11:16 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 14 Feb 2025 00:11:16 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument src/hotspot/share/code/codeBlob.hpp line 669: > 667: > 668: jobject receiver() { return _receiver; } > 669: ByteSize frame_data_offset() { return _frame_data_offset; } `frame_data_offset()` seems to be unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955373697 From dlong at openjdk.org Fri Feb 14 00:17:14 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 14 Feb 2025 00:17:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument HotSpot C++ changes look good. I skipped SA changes. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2616477660 From dholmes at openjdk.org Fri Feb 14 04:59:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Feb 2025 04:59:11 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:37:27 GMT, Serguei Spitsyn wrote: >> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp endThread()` and others are returned. For instance, some `SingleStep` events can be posted. >> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. >> >> Testing: >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: > > - removed obsolete fragment that was not removed in last update > - review: re-fixed the issue as initial fix was wrong I can't say that I understand the fix at all. Why would we suspend a platform thread in the middle of `post_single_step`? And what has this to do with the original proposal that only affected virtual threads??? If we don't want a suspended thread to be able to post events we should have probably detected that at a higher-level where it makes sense for the thread to actually suspend. ------------- PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2616761143 From iklam at openjdk.org Fri Feb 14 05:27:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Feb 2025 05:27:09 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v2] In-Reply-To: References: Message-ID: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Comments from @erikj79 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/0a645b69..c1aaf635 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=00-01 Stats: 224 lines in 5 files changed: 142 ins; 62 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From iklam at openjdk.org Fri Feb 14 05:27:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Feb 2025 05:27:10 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 19:20:05 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments from @erikj79 > > make/RunTests.gmk line 734: > >> 732: $$(call MakeDir, $$($1_TEST_SUPPORT_DIR)/aot) >> 733: >> 734: $(info AOT: Create cache configuration) \ > > Please use logging framework for any messages. To get something to print by default `$(call LogWarn, ...). While here, please also clean up the left over debug $$(info ) left over further down in this file that we weren't able to point out in the original review. Fixed. I also fixed the other `$(info)` used by AOT testing. > make/RunTests.gmk line 737: > >> 735: $$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/aot, ( \ >> 736: $(CD) $$($1_AOT_JDK_DIR); \ >> 737: $(JDK_UNDER_TEST)/bin/javac -d . $(TOPDIR)/make/test/SetupAot.java; \ > > This is putting the compilation output in the current directory, which is the make directory in the workspace. That's not acceptable. Since this is a single class java program, would it be possible to just run it without compilation or would that interfere with the intended behavior? Otherwise it needs to be moved to somewhere else, under `$$($1_TEST_SUPPORT_DIR)`. > > I don't like that the compilation is run in the same recipe as the java command running the tool. At the very least those should be split into separate recipes, with separate ExecuteWithLog calls. A cleaner and preferred solution would be to build this tool as part of the test image so we avoid having to compile code during test setup. I added the class file to the test image. > make/RunTests.gmk line 741: > >> 739: -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \ >> 740: -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \ >> 741: SetupAot \ > > Please use 4 spaces indent to follow the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html). > > Suggestion: > > $$(FIXPATH) $(JDK_UNDER_TEST)/bin/java $$($1_VM_OPTIONS) \ > -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \ > -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \ > SetupAot \ Fixed. > make/RunTests.gmk line 744: > >> 742: )) >> 743: >> 744: $$(info AOT: Generate AOT cache $$($1_AOT_JDK_CACHE) with flags: $$($1_VM_OPTIONS)) > > Again, please use the logging framework. In this case I would recommend `$(call LogInfo, ...)` to reduce spam on the default level. I think one line is enough on warn level for indicating that AOT preparation is taking place. I changed the `$(info)` to `$(call LogWarn)`. Since AOT testing is still a new feature and all the test tasks we use "make test JTREG_AOT_JDK=true" for are for the purpose of testing AOT, it's better to print out the messages related to the AOT cache by default to help with diagnosing test failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955574061 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573695 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573715 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573910 From iklam at openjdk.org Fri Feb 14 05:59:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Feb 2025 05:59:52 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v3] In-Reply-To: References: Message-ID: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, 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 8349953-avoid-edit-aot-config-with-jtreg-aot-jdk - Comments from @erikj79 - 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/c1aaf635..ed727488 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=01-02 Stats: 1992 lines in 34 files changed: 1757 ins; 122 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From dholmes at openjdk.org Fri Feb 14 06:12:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Feb 2025 06:12:20 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v15] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 20:33:33 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Change name as per Axel's request This seems okay to me. The testing "hack" is not too awful - and better than what I had envisaged. :) src/hotspot/share/logging/logAsyncWriter.cpp line 47: > 45: > 46: ~AsyncLogLocker() { > 47: assert(_holder == nullptr || _holder == Thread::current_or_null(), "must be"); The first clause is still redundant ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2616837311 PR Review Comment: https://git.openjdk.org/jdk/pull/23513#discussion_r1955602554 From aboldtch at openjdk.org Fri Feb 14 10:11:13 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 14 Feb 2025 10:11:13 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v15] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 20:33:33 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Change name as per Axel's request Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2617320213 From jsjolen at openjdk.org Fri Feb 14 11:03:55 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 14 Feb 2025 11:03:55 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v16] In-Reply-To: References: Message-ID: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix! ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23513/files - new: https://git.openjdk.org/jdk/pull/23513/files/a7431d22..3f0246e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23513&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23513/head:pull/23513 PR: https://git.openjdk.org/jdk/pull/23513 From aboldtch at openjdk.org Fri Feb 14 11:03:55 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 14 Feb 2025 11:03:55 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v16] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 11:00:06 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix! Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2617447838 From rrich at openjdk.org Fri Feb 14 14:25:12 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 14 Feb 2025 14:25:12 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: <_jQq0sGaZijMT6Cr3rUdrQLlvVWNuJ8uILHg1qkCxoM=.271ce257-9e72-4d61-87fa-588ce4dbe107@github.com> References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> <_jQq0sGaZijMT6Cr3rUdrQLlvVWNuJ8uILHg1qkCxoM=.271ce257-9e72-4d61-87fa-588ce4dbe107@github.com> Message-ID: On Thu, 13 Feb 2025 21:32:54 GMT, Dean Long wrote: > > The 2nd assert does not fail w/o the deoptimization.cpp fix. Might be due to alignement of caller->sp() in the interpreter. > > Aarch64 also does alignment, and that's why the test uses two different methods, one with an extra local, to hopefully handle both cases of even/odd 2-word (16 byte) alignment. But ppc might be different enough that this isn't enough to trigger the bug. Or maybe the end of frame bound is slightly off? I think you can make the assertion a little stricter like this https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0. The test still doesn't fail on ppc64 w/o the fix. This is because the deoptee's caller is alwys enlarged [here](https://github.com/openjdk/jdk/blob/57f4c30fb6be1da57c8fcc742b5c36d842eef397/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2840) although it's only necessary if it is the entry frame or compiled. (Reasoning for the stricter assertion: interpreter frames on top of stack have a `frame::top_ijava_frame_abi` just above sp needed for VM calls. When a call is received by the interpreter, it trimms the abi of the caller back to `frame::parent_ijava_frame_abi`. An i2c adapter does not do this.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2659465735 From matsaave at openjdk.org Fri Feb 14 18:45:40 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Feb 2025 18:45:40 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader Message-ID: This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile. Verified with tier 1-5 tests ------------- Commit messages: - Refactor StackMapTable constructor and StackMapReader Changes: https://git.openjdk.org/jdk/pull/23645/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23645&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349923 Stats: 158 lines in 3 files changed: 65 ins; 15 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/23645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23645/head:pull/23645 PR: https://git.openjdk.org/jdk/pull/23645 From vlivanov at openjdk.org Fri Feb 14 19:30:17 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 14 Feb 2025 19:30:17 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 12 Feb 2025 21:09:31 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix bounds checks Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2618641095 From vlivanov at openjdk.org Fri Feb 14 19:30:18 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 14 Feb 2025 19:30:18 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> <7xJgm0ScXMp4iRaH7Sf5QfsrTv2jOV4078kPqn3aoCs=.63303086-b4bd-47c5-9bd5-e69e28f75f4c@github.com> Message-ID: On Thu, 13 Feb 2025 21:23:55 GMT, Dean Long wrote: >> As far as I can tell, it was never needed. If an invokedynamic or invokehandle adds an appendix, then it will show up in the callee, and will be reflected in the caller args size, so there is no mismatch. As far as the JVM is concerned, an invokedynamic/invokehandle looks like a call to a JVM-generated adapter. The only way for invokedynamic/invokehandle to cause an argument mismatch is if the JVM resolved the call-site to an adapter that was actually a MethodHandle linker. That is the exception I describe in the comment below. If we ever allowed the JVM to do that, then several other checks would also need to be fixed. >> For the record, this code used to call cur.is_method_handle_invoke(), which was also wrong, but at least it had a name closer to what we would want. Ideally, something like is_method_handle_linker_invoke() that checks for linkToVirtual, linkToStatic, linkToSpecial, and linkToInterface would have been better. >> The old comment about "arbitrary chains of calls" seems to be left over from an early JSR292 feature known as Ricochet Frames. > > For the curious, it is still possible create an arbitrarily long chain of linkTo calls, but only trusted code would be able to do that, so I'm not addressing this issue in this PR. Thanks for the clarifications! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1956626058 From coleenp at openjdk.org Fri Feb 14 19:35:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 14 Feb 2025 19:35:12 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader In-Reply-To: References: Message-ID: <6M0Xvs-wLmhaTOaW8CnSM9pBSkAHWlzkMpsJbb1wsF0=.e6056ea7-4fcd-477b-a861-55d725d6deaa@github.com> On Fri, 14 Feb 2025 18:28:51 GMT, Matias Saavedra Silva wrote: > This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile. Verified with tier 1-5 tests This refactoring makes a lot of sense but I haven't fully reviewed and understand how the number of frames can be different. But these are some initial comments from the first reading. Never mind, I do know why frame_count might change with your upcoming changes. src/hotspot/share/classfile/stackMapTable.cpp line 37: > 35: if (_frame_count > 0) { > 36: GrowableArray* tmp_frame_array = new GrowableArray(); > 37: while(!reader->at_end()) { Need space between while and (. src/hotspot/share/classfile/stackMapTable.cpp line 48: > 46: _frame_array = NEW_RESOURCE_ARRAY_IN_THREAD(THREAD, StackMapFrame*, _frame_count); > 47: for (int i = 0; i < tmp_frame_array->length(); i++) { > 48: _frame_array[i] = tmp_frame_array->at(i); This leaks the GrowableArray for the rest of the Method verification or until a ResourceMark end scope (where also this StackMapFrame array is also recovered). Can you just change the type of _frame_array to GrowableArray? It's the same storage and GrowableArray->length() is the correct count that you can use after this. src/hotspot/share/classfile/stackMapTable.cpp line 144: > 142: StackMapFrame* init_frame, > 143: u2 max_locals, u2 max_stack, TRAPS) : > 144: _verifier(v), _stream(stream), _code_data(code_data), Could you indent these out 4 so they don't look like another 4 lines of parameters? src/hotspot/share/classfile/stackMapTable.cpp line 371: > 369: VerificationType* pre_locals = _pre_frame->locals(); > 370: int i; > 371: for (i=0; i<_pre_frame->locals_size(); i++) { This needs spaces too since you touched it. Can "int i" be in scope of the for loop too? src/hotspot/share/classfile/stackMapTable.hpp line 124: > 122: > 123: // Previous and current frame buffers > 124: StackMapFrame* _pre_frame; If you've touched all of the instances of pre_frame, can you rename it prev_frame ? frame_buf could also be current_frame if you've changed lines that it appears on. src/hotspot/share/classfile/stackMapTable.hpp line 178: > 176: ErrorContext::bad_stackmap(0, frame), > 177: "StackMapTable error: bad offset"); > 178: } Rather than have this inlined in the header file, can you put the definition right before where it's used? I think I only found one place. I believe this is in only one place. next_helper should be declared private. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23645#pullrequestreview-2618623415 PR Comment: https://git.openjdk.org/jdk/pull/23645#issuecomment-2660115070 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956616362 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956622314 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956622975 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956624243 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956625449 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956626899 From matsaave at openjdk.org Fri Feb 14 19:41:14 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Feb 2025 19:41:14 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader In-Reply-To: <6M0Xvs-wLmhaTOaW8CnSM9pBSkAHWlzkMpsJbb1wsF0=.e6056ea7-4fcd-477b-a861-55d725d6deaa@github.com> References: <6M0Xvs-wLmhaTOaW8CnSM9pBSkAHWlzkMpsJbb1wsF0=.e6056ea7-4fcd-477b-a861-55d725d6deaa@github.com> Message-ID: On Fri, 14 Feb 2025 19:27:06 GMT, Coleen Phillimore wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile. Verified with tier 1-5 tests > > src/hotspot/share/classfile/stackMapTable.hpp line 124: > >> 122: >> 123: // Previous and current frame buffers >> 124: StackMapFrame* _pre_frame; > > If you've touched all of the instances of pre_frame, can you rename it prev_frame ? frame_buf could also be current_frame if you've changed lines that it appears on. I noticed that frame_buf is unused and as far as I can tell it isn't needed. "prev_frame" is definitely clearer so I'll switch to that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1956636206 From matsaave at openjdk.org Fri Feb 14 20:13:48 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Feb 2025 20:13:48 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v2] In-Reply-To: References: Message-ID: > This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile. Verified with tier 1-5 tests Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Coleen comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23645/files - new: https://git.openjdk.org/jdk/pull/23645/files/ef8c9786..9a78ba6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23645&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23645&range=00-01 Stats: 105 lines in 2 files changed: 21 ins; 27 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/23645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23645/head:pull/23645 PR: https://git.openjdk.org/jdk/pull/23645 From sspitsyn at openjdk.org Fri Feb 14 20:57:15 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Feb 2025 20:57:15 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 04:56:11 GMT, David Holmes wrote: > Why would we suspend a platform thread in the middle of post_single_step? And what has this to do with the original proposal that only affected virtual threads??? We have not observed this issue for platform threads yet. It is why I did not want this fix to impact the platform threads behavior. Patricio shared his opinion (and I agree with that) that this issue is common for platform and virtual threads. It is possible to take one of two paths: - make this fix for virtual threads only - make this fix common for platform and virtual threads; I can try to update the failing test to prove we have the same issue for platform threads too; will correct the PR description then > If we don't want a suspended thread to be able to post events we should have probably detected that at a higher-level where it makes sense for the thread to actually suspend. Not sure what do you mean by "detected at a higher level". Do you mean: detect it in the `InterpreterRuntime::at_safepoint()` function? Otherwise, there are no other levels where it can be detected as it is triggered by execution of a Java bytecode in the interpreter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2660239780 From sspitsyn at openjdk.org Fri Feb 14 21:32:10 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Feb 2025 21:32:10 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 22:57:01 GMT, Patricio Chilano Mateo wrote: > We can always create a test where a suspended target posts an event though, because the target can be seen as handshake-safe after switching to native in JvmtiJavaThreadEventTransition. So this fix would prevent posting events enabled after suspension (like this test is doing) but not before. Right. It is important to prevent posting events enabled after suspension. > This latter case would not be easy to fix since a callback is executed in native and we allow suspending in such state. My understanding is that the event posting is intentionally racy. We can treat it as a thread suspension request has been processed in the middle of an event callback execution. We do not need to fix this as it is a part of the design. > Now, I thought suspend only implied the target cannot execute new Java bytecodes (can?t find the precise definition in the JVMTI specs). Yes, the target should not execute new Java bytecodes after suspension. > If that?s the case, why is this a bug in the VM and not a test issue? Or is this a case of still following the specs but trying to do the saner thing? I treat it as VM/JVMTI bug as it looks silly when events are posted event though they were enabled after suspension. Yes, it is an attempt to do he saner thing. Thank you for good questions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2660306484 From dlong at openjdk.org Fri Feb 14 22:41:13 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 14 Feb 2025 22:41:13 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 12 Feb 2025 21:09:31 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix bounds checks > I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. Thanks for the review, Vladimir. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2660395298 PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2660398727 From kvn at openjdk.org Fri Feb 14 23:14:18 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 14 Feb 2025 23:14:18 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > rename SA argument I addressed most @xmas92 and @dean-long comments and working on avoid `_v` suffix Thank you, Dean, for review. ------------- PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2618707275 PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2660443983 From kvn at openjdk.org Fri Feb 14 23:14:20 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 14 Feb 2025 23:14:20 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 08:15:16 GMT, Axel Boldt-Christmas wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Zero VM build > > src/hotspot/share/code/codeBlob.hpp line 140: > >> 138: instance->print_value_on_nv(st); >> 139: } >> 140: }; > > I wonder why the base class is not abstract. AFAICT `print_value_on` is unreachable and `print_on` is only used by `DeoptimizationBlob::Vptr` which also seems like a behavioural change, as before this patch calling `print_on` a `DeoptimizationBlob` object would dispatch to `SingletonBlob::print_on` not `CodeBlob::print_on`. > > Suggestion: > > struct Vptr { > virtual void print_on(const CodeBlob* instance, outputStream* st) const = 0; > virtual void print_value_on(const CodeBlob* instance, outputStream* st) const = 0; > }; done > src/hotspot/share/code/codeBlob.hpp line 339: > >> 337: void print_value_on(outputStream* st) const; >> 338: >> 339: class Vptr : public CodeBlob::Vptr { > > I wonder if these should share the same type hierarchy as tier container class. This would also solve the issueI noted in my other comment about not calling the correct `print_on`. > Suggestion: > > class Vptr : public RuntimeBlob::Vptr { Fixed > src/hotspot/share/code/codeBlob.hpp line 427: > >> 425: void print_value_on(outputStream* st) const; >> 426: >> 427: class Vptr : public CodeBlob::Vptr { > > Suggestion: > > class Vptr : public RuntimeBlob::Vptr { Fixed > src/hotspot/share/code/codeBlob.hpp line 467: > >> 465: void print_value_on(outputStream* st) const; >> 466: >> 467: class Vptr : public CodeBlob::Vptr { > > Suggestion: > > class Vptr : public RuntimeBlob::Vptr { Fixed > src/hotspot/share/code/codeBlob.hpp line 553: > >> 551: void print_value_on(outputStream* st) const; >> 552: >> 553: class Vptr : public CodeBlob::Vptr { > > This one specifically > Suggestion: > > class Vptr : public SingletonBlob::Vptr { fixed > src/hotspot/share/code/codeBlob.hpp line 679: > >> 677: void print_value_on(outputStream* st) const; >> 678: >> 679: class Vptr : public CodeBlob::Vptr { > > Suggestion: > > class Vptr : public RuntimeBlob::Vptr { fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956799673 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956801833 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956801994 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956802109 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956803039 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956827486 From kvn at openjdk.org Fri Feb 14 23:14:22 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 14 Feb 2025 23:14:22 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <_9qiqpCFRxCMY4nADw0lqrNuOZYIKUpeY_7FYyoQWC8=.78588553-bede-45b1-bf2d-5ad306b81e29@github.com> On Fri, 14 Feb 2025 00:08:35 GMT, Dean Long wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> rename SA argument > > src/hotspot/share/code/codeBlob.hpp line 669: > >> 667: >> 668: jobject receiver() { return _receiver; } >> 669: ByteSize frame_data_offset() { return _frame_data_offset; } > > `frame_data_offset()` seems to be unused. removed > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/c1/Runtime1.java line 65: > >> 63: public CodeBlob blobFor(int id) { >> 64: Address blobAddr = blobsField.getStaticFieldAddress().getAddressAt(id * VM.getVM().getAddressSize()); >> 65: return VM.getVM().getCodeCache().createCodeBlobWrapper(blobAddr); > > We don't need to change all the callers if we keep a 1-arg version of createCodeBlobWrapper(): > > public CodeBlob createCodeBlobWrapper(Address codeBlobAddr) { > return createCodeBlobWrapper(codeBlobAddr, codeBlobAddr); > } This is the only one place where arguments are the same. In other two arguments are different. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956672379 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956667806 From kvn at openjdk.org Fri Feb 14 23:14:23 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 14 Feb 2025 23:14:23 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <07aI9gwcVtc89Bte9DRQ6VwmCfhcBJJQlrXhxkRRgX0=.97d4a1cc-92a2-43dc-8516-2433eca67263@github.com> On Thu, 13 Feb 2025 19:27:19 GMT, Chris Plummer wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> rename SA argument > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 97: > >> 95: // cbAddr - address of a code blob >> 96: // cbPC - address inside of a code blob >> 97: public CodeBlob createCodeBlobWrapper(Address cbAddr, Address cbPC) { > > Can you change findBlobUnsafe() above also? That's where the naming problem originated. After some thoughts I think `PC` is not usually used by us. I renamed `cbAddr` to `cbStart` and `cbPC`/`start` to `addr` in this whole file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956664966 From kvn at openjdk.org Sat Feb 15 02:08:20 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 15 Feb 2025 02:08:20 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Thu, 13 Feb 2025 23:01:24 GMT, Dean Long wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> rename SA argument > > src/hotspot/share/runtime/vframe.inline.hpp line 178: > >> 176: INTPTR_FORMAT " not found or invalid at %d", >> 177: p2i(_frame.pc()), decode_offset); >> 178: nm()->print_on_v(&ss); > > I suggest removing _v suffix to reduce changes and match existing naming. Done. Testing now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956985708 From iklam at openjdk.org Sat Feb 15 04:46:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 15 Feb 2025 04:46:56 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v4] In-Reply-To: References: Message-ID: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Moved the AOT setup function into SetupAOT.gmk so it can be included by other internal makefiles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/ed727488..81944a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=02-03 Stats: 137 lines in 3 files changed: 84 ins; 51 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From kvn at openjdk.org Sat Feb 15 06:13:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 15 Feb 2025 06:13:57 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v9] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/61fdee68..89a383e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=07-08 Stats: 115 lines in 12 files changed: 7 ins; 7 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From kvn at openjdk.org Sat Feb 15 06:29:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 15 Feb 2025 06:29:14 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v9] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: <2aYXBHyZE83suQFtY_POyft2gbRwwF_Xf_qajA62Pgw=.1fe1143c-33c5-4e78-b691-3f85f176c598@github.com> On Sat, 15 Feb 2025 06:13:57 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments I removed `_v` from `CodeBlob::print*_on(st)` methods to reduce scope of VM changes. But I have to add `_impl` suffix to these methods in CodeBlob subclasses. I renamed `nmethod::print_on(st, msg);` to `print_on_with_msg(at, msg) to avoid naming conflict C++ complains about. It cased change in `dependencyContext.cpp`. I made `CodeBlob::Vptr` class abstract as suggested. I added empty `Vptr` class to `RuntimeBlob` because it is referenced in subclasses and corrected extensions in sublcasses to avoid mistakes @xmas92 pointed. I also did some arguments renaming in SA in `CodeCache.java` as requested. Tier1-5 testing passed. Ready for new round of reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2660770028 From kvn at openjdk.org Sat Feb 15 06:34:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 15 Feb 2025 06:34:56 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10] In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove commented lines left by mistake ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23533/files - new: https://git.openjdk.org/jdk/pull/23533/files/89a383e5..3fdf1c81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533 PR: https://git.openjdk.org/jdk/pull/23533 From sroy at openjdk.org Sat Feb 15 15:43:48 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Sat, 15 Feb 2025 15:43:48 GMT Subject: RFR: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 Message-ID: AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) ------------- Commit messages: - Support for power 11 - Support for power 11 - Support for power 11 - Support for power 11 - Support for power 11 Changes: https://git.openjdk.org/jdk/pull/23556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349780 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23556/head:pull/23556 PR: https://git.openjdk.org/jdk/pull/23556 From sroy at openjdk.org Sat Feb 15 16:42:08 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Sat, 15 Feb 2025 16:42:08 GMT Subject: RFR: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 07:56:21 GMT, Suchismith Roy wrote: > AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. > > JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) Test run bash-5.2# java -XX:ErrorHandlerTest=1 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/hotspot/openjdk/suchijdk17/jdk/src/hotspot/share/utilities/vmError.cpp:2090), pid=8978868, tid=258 # assert(how == 0) failed: test assert # # JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-adhoc.hotspot.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.hotspot.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, aix-ppc64) # Core dump will be written. Default location: /home/suchismith/jdk/bin/core or core.8978868 (max size 1048575 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/suchismith/jdk/bin/hs_err_pid8978868.log **PV_11_Compat** # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # IOT/Abort trap (core dumped) ' ------------- PR Comment: https://git.openjdk.org/jdk/pull/23556#issuecomment-2660995804 From iklam at openjdk.org Sun Feb 16 05:21:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 16 Feb 2025 05:21:00 GMT Subject: RFR: 8350148: Native stack overflow when writing Java heap objects into AOT cache Message-ID: Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. The fix is to do the recursion using a side table, without making any recursive calls. Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline. ------------- Commit messages: - 8350148: Native stack overflow when writing Java heap objects into AOT cache Changes: https://git.openjdk.org/jdk/pull/23654/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23654&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350148 Stats: 104 lines in 2 files changed: 69 ins; 17 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/23654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23654/head:pull/23654 PR: https://git.openjdk.org/jdk/pull/23654 From stuefe at openjdk.org Sun Feb 16 05:53:13 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 16 Feb 2025 05:53:13 GMT Subject: RFR: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 In-Reply-To: References: Message-ID: <17qkMp1lKjBBQGjKz6C0l0UPk-YPhsS4H1Z6icQFJg8=.da2541f9-c884-4a1c-99cd-25a998b059c1@github.com> On Tue, 11 Feb 2025 07:56:21 GMT, Suchismith Roy wrote: > AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. > > JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) Good. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23556#pullrequestreview-2619544780 From liach at openjdk.org Sun Feb 16 15:23:09 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 16 Feb 2025 15:23:09 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 20:13:48 GMT, Matias Saavedra Silva wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen comments > the `_frame_count` may not be equal to the value reported by the classfile Context for other reviewers: This may happen with the new StackMapTable entries introduced by Value Objects JEP. https://cr.openjdk.org/~dlsmith/jep401/jep401-20241108/specs/value-objects-jvms.html#jvms-4.7.4 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23645#issuecomment-2661478846 From aboldtch at openjdk.org Mon Feb 17 06:41:18 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 17 Feb 2025 06:41:18 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented lines left by mistake Not looked at the SA changes. lgtm. src/hotspot/share/code/codeBlob.hpp line 308: > 306: > 307: class Vptr : public CodeBlob::Vptr { > 308: }; Was this needed for some compiler? Or is it to be more explicit about the type hierarchy? ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2620128040 PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1957678232 From dholmes at openjdk.org Mon Feb 17 07:58:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 17 Feb 2025 07:58:11 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v16] In-Reply-To: References: Message-ID: <93et7HVwy8MI8Pe6EAxwFQLV8NObg8cQl38tBY5W17k=.35fe8fb6-0438-40ff-b4a5-bbfc164fe2d4@github.com> On Fri, 14 Feb 2025 11:03:55 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix! Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23513#pullrequestreview-2620274969 From jsjolen at openjdk.org Mon Feb 17 09:26:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 17 Feb 2025 09:26:26 GMT Subject: Integrated: 8349755: Fix corner case issues in async UL In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 10:21:37 GMT, Johan Sj?len wrote: > Hi, > > There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. > > 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. > 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur > > We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. > > Note, this fix introduces a third case: > > 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also > > In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. > > As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. > > Testing: GHA only, so far. > > All the best, > Johan This pull request has now been integrated. Changeset: f1258f9e Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/f1258f9e16b063c0fdbdd614ae2dc76c67607654 Stats: 154 lines in 7 files changed: 130 ins; 9 del; 15 mod 8349755: Fix corner case issues in async UL Reviewed-by: dholmes, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/23513 From jsjolen at openjdk.org Mon Feb 17 09:26:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 17 Feb 2025 09:26:24 GMT Subject: RFR: 8349755: Fix corner case issues in async UL [v16] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 11:03:55 GMT, Johan Sj?len wrote: >> Hi, >> >> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR. >> >> 1. If the `AsyncLogWriter` produces a log message, then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`. >> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur >> >> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging. >> >> Note, this fix introduces a third case: >> >> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also >> >> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing. >> >> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging. >> >> Testing: GHA only, so far. >> >> All the best, >> Johan > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix! Thank you for your patience with this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23513#issuecomment-2662513118 From rrich at openjdk.org Mon Feb 17 11:30:13 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 17 Feb 2025 11:30:13 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Fri, 14 Feb 2025 22:38:23 GMT, Dean Long wrote: > > I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). > > Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. Correct, the top frame has a frame::top_ijava_frame_abi but the assertion is about the abi section in the current frame's caller and the the bottom frame's caller also has a top_ijava_frame_abi because i2c doesn't modify it. Continue reading if you're interested in more details... As said the i2c adapter does *not* trimm the caller frame as the interpreter would, replacing its large `top_ijava_frame_abi` with a smaller `parent_ijava_frame_abi`. Example: compiled frame DEOPTEE is replaced with 3 interpreted frames Stack before deoptimization | | | Interpreted CALLER | | of DEOPTEE frame | | | +------------------------+ | | | top_ijava_frame_abi | | | +========================+ | | | Compiled | | DEOPTEE | | | +------------------------+ | java_abi | +========================+ Stack when assertion is checked (i.e. after DEOPTEE was replaced by corresponding inter. frames) | | | Interpreted CALLER | | of DEOPTEE frame | | | +------------------------+ | | | top_ijava_frame_abi | <- i2c keeps large abi | | +========================+ | | <- bottom frame | Interpreted Frame 0 | | corresp. to DEOPTEE | | | +------------------------+ | parent_ijava_frame_abi | +========================+ | | | Interpreted Frame 1 | | (inlined by DEOPTEE) | | | +------------------------+ | parent_ijava_frame_abi | +========================+ | | <- top frame | Interpreted Frame 2 | | (inlined by DEOPTEE) | | | +------------------------+ | | | top_ijava_frame_abi | | | +========================+ Notes: (refering to the frame sections rather than the C++ types) - top_ijava_frame_abi complies to the native abi (modelled by frame::native_abi_reg_args). This is needed for VM calls. - parent_ijava_frame_abi is equal to frame::java_abi. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2662835374 From amitkumar at openjdk.org Mon Feb 17 13:27:10 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 17 Feb 2025 13:27:10 GMT Subject: RFR: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 07:56:21 GMT, Suchismith Roy wrote: > AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. > > JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) Marked as reviewed by amitkumar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23556#pullrequestreview-2621066800 From duke at openjdk.org Mon Feb 17 13:27:10 2025 From: duke at openjdk.org (duke) Date: Mon, 17 Feb 2025 13:27:10 GMT Subject: RFR: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 07:56:21 GMT, Suchismith Roy wrote: > AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. > > JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) @suchismith1993 Your change (at version 25908102817b2f3ffcce6dc8155b3909597b4312) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23556#issuecomment-2663131820 From sroy at openjdk.org Mon Feb 17 13:31:16 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Mon, 17 Feb 2025 13:31:16 GMT Subject: Integrated: JDK-8349780 : AIX os::get_summary_cpu_info support Power 11 In-Reply-To: References: Message-ID: <1TDEpmPXzYNDFj550Y7LORzz8A781rRGzffH0EdBtaA=.14cd6ac8-0e0a-40df-9457-3865ac8a7a67@github.com> On Tue, 11 Feb 2025 07:56:21 GMT, Suchismith Roy wrote: > AIX os::get_summary_cpu_info function still misses support for Power 11, this should be changed. > > JBS-Issue: [JDK-8349780](https://bugs.openjdk.org/browse/JDK-8349780l) This pull request has now been integrated. Changeset: 8b2aa51b Author: Suchismith Roy Committer: Amit Kumar URL: https://git.openjdk.org/jdk/commit/8b2aa51b0c36a993e46fea7a4b61788dd101d606 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod 8349780: AIX os::get_summary_cpu_info support Power 11 Reviewed-by: stuefe, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/23556 From sgehwolf at openjdk.org Mon Feb 17 14:06:25 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 17 Feb 2025 14:06:25 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > added details in the log message `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening. Testing: >>And after the patch this would become this, right? >>``` >>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >>/sys/fs/cgroup/cpu,cpuacct/ >>``` > >It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be > >``` >/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c >/sys/fs/cgroup/cpu,cpuacct/bad >/sys/fs/cgroup/cpu,cpuacct/ >``` The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 75: > 73: break; > 74: } > 75: suffix = strchr(suffix+1, '/'); Style: Suggestion: suffix = strchr(suffix + 1, '/'); src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 63: > 61: Path cgp = Path.of(cgroupPath); > 62: int nameCount = cgp.getNameCount(); > 63: for (int i=0; i 71: break; > 72: } > 73: cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of(""); Suggestion: cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of(""); test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60: > 58: > 59: Common.prepareWhiteBox(); > 60: DockerTestUtils.buildJdkContainerImage(imageName); This can be moved out of the condition. It's there in both cases. test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85: > 83: } else { > 84: System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now."); > 85: } Suggestion: throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider()); test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98: > 96: opts.addDockerOpts("--privileged") > 97: .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) > 98: .addDockerOpts("--memory", "1g"); Please extract this "larger" memory limit out of this function. The expectation is to have: Container memory limit => X Some lower limit in a moved path => Y Expect that the lower limit of Y is being detected. For example: testMemoryLimitSubgroupV1("1g", "100m", "104857600", false); test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118: > 116: opts.addDockerOpts("--privileged") > 117: .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) > 118: .addDockerOpts("--memory", "1g"); Same here with the `1g` container memory limit. Move it to a parameter. test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72: > 70: } else { > 71: System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now."); > 72: } Please `throw` here. ------------- Changes requested by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2620718790 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958032435 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958043532 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958048577 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958073462 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958075672 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958059439 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958061783 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958077572 From mbaesken at openjdk.org Mon Feb 17 15:21:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 17 Feb 2025 15:21:21 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info Message-ID: When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 typedef struct { unsigned long long int __ctx(fault_address); unsigned long long int __ctx(regs)[31]; .... } mcontext_t; and according to the arm developer documentation https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." ------------- Commit messages: - JDK-8350201 Changes: https://git.openjdk.org/jdk/pull/23667/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23667&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350201 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23667/head:pull/23667 PR: https://git.openjdk.org/jdk/pull/23667 From mbaesken at openjdk.org Mon Feb 17 15:21:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 17 Feb 2025 15:21:21 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > .... > } mcontext_t; > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." while looking into other register printing coding I noticed the comments for ppc64 were wrong. https://www.ibm.com/docs/en/aix/7.2?topic=overview-register-usage-conventions https://math-atlas.sourceforge.net/devel/atlas_contrib/node96.html there we have registers 0 to 31 (and not 0 to 32) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2663420844 From mbaesken at openjdk.org Mon Feb 17 15:51:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 17 Feb 2025 15:51:14 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > added details in the log message src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2: > 1: /* > 2: * Copyright (c) 2020, 2024, Red Hat Inc. You did not touch the test but change the COPYRIGHT year, why ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958449655 From azafari at openjdk.org Mon Feb 17 15:56:46 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 17 Feb 2025 15:56:46 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> Message-ID: <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> > The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: comopared wit External Max instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23539/files - new: https://git.openjdk.org/jdk/pull/23539/files/dbb1ef7a..4fc8fe81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23539&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23539&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23539/head:pull/23539 PR: https://git.openjdk.org/jdk/pull/23539 From kvn at openjdk.org Mon Feb 17 18:43:23 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 17 Feb 2025 18:43:23 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Mon, 17 Feb 2025 06:24:35 GMT, Axel Boldt-Christmas wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove commented lines left by mistake > > src/hotspot/share/code/codeBlob.hpp line 308: > >> 306: >> 307: class Vptr : public CodeBlob::Vptr { >> 308: }; > > Was this needed for some compiler? Or is it to be more explicit about the type hierarchy? Thank you, @xmas92, for review and suggestions. It is second (explicit type hierarchy). I think it should be explicitly declared (even empty) because it is referenced in subclasses to avoid confusion. And it could be useful in a future if we need other virtual methods. Local build with `gcc` on Linux passed without it but I did not try to build on other platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1958673128 From dholmes at openjdk.org Tue Feb 18 00:39:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 18 Feb 2025 00:39:13 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> Message-ID: <_MWl79GF5Ruj8g899kcU687QXXDk4696djc-Ybl8ZU0=.e5702a21-7a69-4e0e-8ce7-6502a20e1932@github.com> On Mon, 17 Feb 2025 15:56:46 GMT, Afshin Zafari wrote: >> The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > comopared wit External Max instead. LGTM! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23539#pullrequestreview-2622127031 From cjplummer at openjdk.org Tue Feb 18 03:05:16 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 18 Feb 2025 03:05:16 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented lines left by mistake SA changes look good. Thanks for taking care of this. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2622331256 From dholmes at openjdk.org Tue Feb 18 04:57:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 18 Feb 2025 04:57:19 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > .... > } mcontext_t; > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." Looks good. I've updated the bug report with the history. Interesting BSD and Windows use completely different register sets on Aarch64 compared to linux. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23667#pullrequestreview-2622433259 From kbarrett at openjdk.org Tue Feb 18 06:52:08 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Feb 2025 06:52:08 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > .... > } mcontext_t; > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." aarch64.ad has a comment that probably ought to be fixed: https://github.com/openjdk/jdk/blame/8df804005ed772936fd77a4c0335a5620f909570/src/hotspot/cpu/aarch64/aarch64.ad#L71 It also has SP as R31, but I guess that's okay. Over in register_aarch64.hpp we have `number_of_registers = 32`, including r31_sp. And `zr` and `sp` are 32 and 33, respectively. So that all seems a little bit confusing. But it all seems to work... I mostly bring that up because I would have thought print_register_info could get the number of registers from some common definition rather than using a hard-coded value. Oh well... ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23667#pullrequestreview-2622593038 From mbaesken at openjdk.org Tue Feb 18 08:38:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Feb 2025 08:38:11 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 04:54:40 GMT, David Holmes wrote: > Looks good. I've updated the bug report with the history. Interesting BSD and Windows use completely different register sets on Aarch64 compared to linux. > > Thanks The arm docu says that "X30 is typically used as the link register (LR)" and X29 might (depending on compile options) also have some special meaning. Maybe that's why they are omitted on Windows/BSD/macOS . On the other hand it seems not to hurt to output them too. Maybe some arm/aarch64 experts want to comment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2664939757 From mbaesken at openjdk.org Tue Feb 18 08:42:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Feb 2025 08:42:12 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 06:49:31 GMT, Kim Barrett wrote: > aarch64.ad has a comment that probably ought to be fixed: https://github.com/openjdk/jdk/blame/8df804005ed772936fd77a4c0335a5620f909570/src/hotspot/cpu/aarch64/aarch64.ad#L71 > > It also has SP as R31, but I guess that's okay. > Should I change the comment from 'r27-r32 system (no save, no allocate)' to 'r27-r31 system (no save, no allocate)' ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2664947609 From aph at openjdk.org Tue Feb 18 08:58:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 18 Feb 2025 08:58:09 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 06:49:31 GMT, Kim Barrett wrote: > aarch64.ad has a comment that probably ought to be fixed: https://github.com/openjdk/jdk/blame/8df804005ed772936fd77a4c0335a5620f909570/src/hotspot/cpu/aarch64/aarch64.ad#L71 > > It also has SP as R31, but I guess that's okay. > > Over in register_aarch64.hpp we have `number_of_registers = 32`, including r31_sp. And `zr` and `sp` are 32 and 33, respectively. So that all seems a little bit confusing. But it all seems to work... It is confusing, but that's how it works. Some instructions treat r31 as ZR, some as SP. ZR (obviously?) does not need saving or printing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2664984341 From azafari at openjdk.org Tue Feb 18 09:37:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 18 Feb 2025 09:37:13 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: <_MWl79GF5Ruj8g899kcU687QXXDk4696djc-Ybl8ZU0=.e5702a21-7a69-4e0e-8ce7-6502a20e1932@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> <_MWl79GF5Ruj8g899kcU687QXXDk4696djc-Ybl8ZU0=.e5702a21-7a69-4e0e-8ce7-6502a20e1932@github.com> Message-ID: On Tue, 18 Feb 2025 00:36:16 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> comopared wit External Max instead. > > LGTM! Thanks Thank you @dholmes-ora for your review. Can I take this PR as trivial? Or look for a second reviewer? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23539#issuecomment-2665078162 From aturbanov at openjdk.org Tue Feb 18 09:48:13 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 18 Feb 2025 09:48:13 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v4] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 04:46:56 GMT, Ioi Lam wrote: >> When running HotSpot jtreg tests in the "AOT mode", for example: >> >> >> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable >> >> >> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: >> >> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 >> >> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. >> >> ** Changes in this PR ** >> >> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Moved the AOT setup function into SetupAOT.gmk so it can be included by other internal makefiles test/jtreg_setup_aot/ExerciseJDKClasses.java line 54: > 52: // E.g., use javac to compile a program. > 53: for (String tool : tools) { > 54: ToolProvider t = ToolProvider.findFirst(tool) Suggestion: ToolProvider t = ToolProvider.findFirst(tool) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1959398001 From jsjolen at openjdk.org Tue Feb 18 09:53:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 18 Feb 2025 09:53:14 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> Message-ID: On Mon, 17 Feb 2025 15:56:46 GMT, Afshin Zafari wrote: >> The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > comopared wit External Max instead. LGTM :) ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23539#pullrequestreview-2622995197 From azafari at openjdk.org Tue Feb 18 09:59:23 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 18 Feb 2025 09:59:23 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> Message-ID: On Mon, 17 Feb 2025 15:56:46 GMT, Afshin Zafari wrote: >> The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > comopared wit External Max instead. Ok, already got approval from Johan. Thank you @jdksjolen and @dholmes-ora for you reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23539#issuecomment-2665131665 From azafari at openjdk.org Tue Feb 18 09:59:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 18 Feb 2025 09:59:29 GMT Subject: Integrated: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' In-Reply-To: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> Message-ID: On Mon, 10 Feb 2025 10:20:08 GMT, Afshin Zafari wrote: > The value 100 for shift comes from a test which shuffles the bytecode contents and tries to verify the resulting bytecode. So, the solution is first check if there is no error in verification then use left-shift to find the type of the class being verified. This pull request has now been integrated. Changeset: 160db5f0 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/160db5f0f000f8471f71e0725da862d57db28c8a Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/23539 From jsjolen at openjdk.org Tue Feb 18 13:18:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 18 Feb 2025 13:18:02 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 Message-ID: Hi, [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. ------------- Commit messages: - Weird semi-colons - Update copyright - Explicitly disable deathtest and deathtest2 if using wildcards Changes: https://git.openjdk.org/jdk/pull/23675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23675&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350214 Stats: 50 lines in 4 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23675/head:pull/23675 PR: https://git.openjdk.org/jdk/pull/23675 From coleenp at openjdk.org Tue Feb 18 18:55:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 18 Feb 2025 18:55:40 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 20:13:48 GMT, Matias Saavedra Silva wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen comments This looks really good. I have one small comment. src/hotspot/share/classfile/stackMapTable.cpp line 36: > 34: _frame_count = reader->get_frame_count(); > 35: if (_frame_count > 0) { > 36: _frame_array = new GrowableArray(); I think if you give GrowableArray() an initial capacity of _frame_count, that should be the right count unless you have assert_unset_field stackmap modifiers, in which case you'll use less but only a little bit less. The default size is 2 of GrowableArray. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23645#pullrequestreview-2624579757 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960310952 From kvn at openjdk.org Tue Feb 18 19:24:22 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 18 Feb 2025 19:24:22 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Wed, 12 Feb 2025 03:03:34 GMT, Chris Plummer wrote: >> Before I forgot to answer you, @plummercj >> I completely agree with your comment about cleaning up wrapper subclasses which do nothing. >> >> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there? >> >> An other purpose could be a place holder for additional information in a future which never come. >> >> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM. >> >> So yes, feel free to clean this up. I will help with review. > >> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there? > > Possibly getName() didn't exist when PStack was first written. It would be good if PStack not only included the type name as it does now, but also the actual name of the blob, which getName() would return. > >> An other purpose could be a place holder for additional information in a future which never come. > > Yes, and you also see that with the Observer registration and the `Type type = db.lookupType()` code, which are only needed if you are going to lookup fields of the subtypes, which most don't ever do, yet they all have this code. > >> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM. > > Yeah, that's not working right for CodeBlob subtypes that are not RuntimeStubs. Easy to fix though. > >> So yes, feel free to clean this up. I will help with review. > > Ok. Let me see where things are at after you are done with the PR. Thank you, @plummercj , for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2666228333 From kvn at openjdk.org Tue Feb 18 19:24:34 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 18 Feb 2025 19:24:34 GMT Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10] In-Reply-To: References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov wrote: >> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. >> >> Added C++ static asserts to make sure no virtual methods are added in a future. >> >> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. >> >> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented lines left by mistake Thank you all for reviews and suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2666253220 From iklam at openjdk.org Tue Feb 18 19:27:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Feb 2025 19:27:58 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v5] In-Reply-To: References: Message-ID: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/81944a2e..f78354c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=03-04 Stats: 137 lines in 2 files changed: 52 ins; 84 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From kvn at openjdk.org Tue Feb 18 20:11:04 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 18 Feb 2025 20:11:04 GMT Subject: Integrated: 8349088: De-virtualize Codeblob and nmethod In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com> Message-ID: On Sun, 9 Feb 2025 17:45:30 GMT, Vladimir Kozlov wrote: > Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table. > > Added C++ static asserts to make sure no virtual methods are added in a future. > > Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob. > > Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp This pull request has now been integrated. Changeset: 46d4a601 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/46d4a601e04f90b11d4ccc97a49f4e7010b4fd83 Stats: 529 lines in 23 files changed: 262 ins; 152 del; 115 mod 8349088: De-virtualize Codeblob and nmethod Co-authored-by: Stefan Karlsson Co-authored-by: Chris Plummer Reviewed-by: cjplummer, aboldtch, dlong ------------- PR: https://git.openjdk.org/jdk/pull/23533 From erikj at openjdk.org Tue Feb 18 20:56:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Feb 2025 20:56:56 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true" [v5] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 19:27:58 GMT, Ioi Lam wrote: >> When running HotSpot jtreg tests in the "AOT mode", for example: >> >> >> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable >> >> >> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: >> >> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 >> >> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. >> >> ** Changes in this PR ** >> >> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file Thank you for helping cleaning this up and moving the compilation of the tool to build time and the test image. Added some more comments. make/Main.gmk line 757: > 755: > 756: $(eval $(call SetupTarget, build-test-setup-aot, \ > 757: MAKEFILE := test/BuildJtregSetupAOT, \ Maybe name the file to match the target (i.e. BuildTestSetupAot)? I don't think there is anything actually jtreg specific about this AOT tool we are building, is there? make/Main.gmk line 758: > 756: $(eval $(call SetupTarget, build-test-setup-aot, \ > 757: MAKEFILE := test/BuildJtregSetupAOT, \ > 758: DEPS := interim-langtools exploded-image build-test-lib, \ I don't think `build-test-lib` is needed. make/PreInitSupport.gmk line 46: > 44: # All known make control variables; these are handled in other makefiles > 45: MAKE_CONTROL_VARIABLES += JDK_FILTER SPEC_FILTER \ > 46: TEST TEST_JOBS JTREG JTREG_AOT_JDK GTEST MICRO TEST_OPTS TEST_VM_OPTS TEST_DEPS This isn't how this filter is meant to be used. `JTREG_AOT_JDK` is the internal representation of setting `JTREG=AOT_JDK=...` on the make command line. While it is technically possible to directly set the internal variable, the intended way of setting this is through the `JTREG` control variable. This gives us the ability to validate the input to reduce the chance of typos messing up a test run. So `JTREG_AOT_JDK` should not be added here as we want to be warned when someone uses the internal form. make/test/BuildJtregSetupAOT.gmk line 29: > 27: > 28: include $(SPEC) > 29: include MakeBase.gmk This should be replaced with just `include MakeFileStart.gmk` since [JDK-8349515](https://bugs.openjdk.org/browse/JDK-8349515), and the file should end with `include MakeFileEnd.gmk`. This will declare `all` as the default target and declare `all: $(TARGETS)` at the bottom. You will need to retain the `images` target and the `.PHONY` declaration for `images`. make/test/BuildJtregSetupAOT.gmk line 41: > 39: SETUP_AOT_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/jtreg_setup_aot > 40: SETUP_AOT_JAR := $(SETUP_AOT_SUPPORT)/jtregSetupAOT.jar > 41: SETUP_AOT_CLASS := $(SETUP_AOT_SUPPORT)/classes/ExerciseJDKClasses.class We do not encourage aligning assignments like this in the makefiles. https://openjdk.org/groups/build/doc/code-conventions.html make/test/BuildJtregSetupAOT.gmk line 47: > 45: SRC := $(SETUP_AOT_BASEDIR), \ > 46: BIN := $(SETUP_AOT_SUPPORT)/classes, \ > 47: JAR := $(SETUP_AOT_JAR), \ If we aren't using the jar, no need to build it. ------------- PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2624978833 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960561460 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960572020 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960558691 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960566324 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960567801 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960569143 From dholmes at openjdk.org Tue Feb 18 21:09:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 18 Feb 2025 21:09:59 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 20:13:48 GMT, Matias Saavedra Silva wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen comments Looks good. A few minor comments/suggestions. Thanks src/hotspot/share/classfile/stackMapTable.cpp line 49: > 47: } > 48: > 49: void StackMapReader::check_offset(StackMapFrame* frame, TRAPS) { TRAPS is unused src/hotspot/share/classfile/stackMapTable.cpp line 54: > 52: _verifier->verify_error( > 53: ErrorContext::bad_stackmap(0, frame), > 54: "StackMapTable error: bad offset"); Suggestion: _verifier->verify_error(ErrorContext::bad_stackmap(0, frame), "StackMapTable error: bad offset"); src/hotspot/share/classfile/stackMapTable.cpp line 60: > 58: void StackMapReader::check_size(TRAPS) { > 59: if (_frame_count < _parsed_frame_count) { > 60: StackMapStream::stackmap_format_error("wrong attribute size", CHECK); Suggestion: StackMapStream::stackmap_format_error("wrong attribute size", THREAD); The method will return no matter what. src/hotspot/share/classfile/stackMapTable.cpp line 67: > 65: assert(_stream->at_end(), "must be"); > 66: if (_frame_count != _parsed_frame_count) { > 67: StackMapStream::stackmap_format_error("wrong attribute size", CHECK); Suggestion: StackMapStream::stackmap_format_error("wrong attribute size", THREAD); The method will return no matter what. src/hotspot/share/classfile/stackMapTable.cpp line 110: > 108: } > 109: > 110: StackMapFrame *stackmap_frame = _frame_array->at(frame_index); Suggestion: StackMapFrame* stackmap_frame = _frame_array->at(frame_index); Pre-existing src/hotspot/share/classfile/stackMapTable.hpp line 167: > 165: inline char* code_data() const { return _code_data; } > 166: inline int32_t code_length() const { return _code_length; } > 167: inline bool at_end() { return _stream->at_end(); } Suggestion: inline int32_t get_frame_count() const { return _frame_count; } inline StackMapFrame* prev_frame() const { return _prev_frame; } inline char* code_data() const { return _code_data; } inline int32_t code_length() const { return _code_length; } inline bool at_end() const { return _stream->at_end(); } ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23645#pullrequestreview-2625014395 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960580404 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960582418 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960585457 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960585849 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960586368 PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1960590243 From ccheung at openjdk.org Tue Feb 18 23:30:03 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 18 Feb 2025 23:30:03 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled Message-ID: This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. Passed tiers 1 - 3 testing. ------------- Commit messages: - @iklam comments - Ioi's suggestions - 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled Changes: https://git.openjdk.org/jdk/pull/23546/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23546&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348322 Stats: 58 lines in 18 files changed: 25 ins; 10 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/23546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23546/head:pull/23546 PR: https://git.openjdk.org/jdk/pull/23546 From iklam at openjdk.org Tue Feb 18 23:30:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Feb 2025 23:30:04 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 00:25:39 GMT, Calvin Cheung wrote: > This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. > Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: > > > [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: > [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST > > Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. > > Passed tiers 1 - 3 testing. src/hotspot/share/cds/aotArtifactFinder.cpp line 213: > 211: if (ik->is_hidden() && CDSConfig::is_initing_classes_at_dump_time()) { > 212: bool succeed = AOTClassLinker::try_add_candidate(ik); > 213: if (CDSConfig::is_dumping_method_handles()) { This should be `assert(CDSConfig::is_dumping_method_handles(), "sanity")`. src/hotspot/share/cds/aotClassLinker.cpp line 146: > 144: assert(ik->shared_class_loader_type() != ClassLoader::OTHER, "must have been set"); > 145: if (!CDSConfig::is_dumping_invokedynamic()) { > 146: return true; I think this should be if (!CDSConfig::is_dumping_methodhandles()) { return false; } Because `is_dumping_methodhandles()` can generate hidden classes that are not lambda proxies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1956965075 PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1956964843 From ccheung at openjdk.org Tue Feb 18 23:30:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 18 Feb 2025 23:30:04 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 01:09:08 GMT, Ioi Lam wrote: >> This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. >> Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: >> >> >> [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: >> [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST >> >> Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. >> >> Passed tiers 1 - 3 testing. > > src/hotspot/share/cds/aotArtifactFinder.cpp line 213: > >> 211: if (ik->is_hidden() && CDSConfig::is_initing_classes_at_dump_time()) { >> 212: bool succeed = AOTClassLinker::try_add_candidate(ik); >> 213: if (CDSConfig::is_dumping_method_handles()) { > > This should be `assert(CDSConfig::is_dumping_method_handles(), "sanity")`. Fixed. > src/hotspot/share/cds/aotClassLinker.cpp line 146: > >> 144: assert(ik->shared_class_loader_type() != ClassLoader::OTHER, "must have been set"); >> 145: if (!CDSConfig::is_dumping_invokedynamic()) { >> 146: return true; > > I think this should be > > if (!CDSConfig::is_dumping_methodhandles()) { > return false; > } > > > Because `is_dumping_methodhandles()` can generate hidden classes that are not lambda proxies. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1960730315 PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1960730231 From iklam at openjdk.org Wed Feb 19 00:27:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 19 Feb 2025 00:27:17 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v6] In-Reply-To: References: Message-ID: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Review comments from @erikj79 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/f78354c1..b5ccc05d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=04-05 Stats: 157 lines in 6 files changed: 70 ins; 68 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From iklam at openjdk.org Wed Feb 19 00:32:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 19 Feb 2025 00:32:55 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v5] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 20:40:12 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file > > make/Main.gmk line 757: > >> 755: >> 756: $(eval $(call SetupTarget, build-test-setup-aot, \ >> 757: MAKEFILE := test/BuildJtregSetupAOT, \ > > Maybe name the file to match the target (i.e. BuildTestSetupAot)? I don't think there is anything actually jtreg specific about this AOT tool we are building, is there? I renamed the file to `BuildTestSetupAOT.gmk`. I also changed the `SetupAot` function to `SetupAOT` (the convention we have been following for the rest of the code has been to use either `AOT` or `aot`, but not `Aot`.). > make/Main.gmk line 758: > >> 756: $(eval $(call SetupTarget, build-test-setup-aot, \ >> 757: MAKEFILE := test/BuildJtregSetupAOT, \ >> 758: DEPS := interim-langtools exploded-image build-test-lib, \ > > I don't think `build-test-lib` is needed. Removed. > make/PreInitSupport.gmk line 46: > >> 44: # All known make control variables; these are handled in other makefiles >> 45: MAKE_CONTROL_VARIABLES += JDK_FILTER SPEC_FILTER \ >> 46: TEST TEST_JOBS JTREG JTREG_AOT_JDK GTEST MICRO TEST_OPTS TEST_VM_OPTS TEST_DEPS > > This isn't how this filter is meant to be used. `JTREG_AOT_JDK` is the internal representation of setting `JTREG=AOT_JDK=...` on the make command line. While it is technically possible to directly set the internal variable, the intended way of setting this is through the `JTREG` control variable. This gives us the ability to validate the input to reduce the chance of typos messing up a test run. So `JTREG_AOT_JDK` should not be added here as we want to be warned when someone uses the internal form. Fixed. > make/test/BuildJtregSetupAOT.gmk line 29: > >> 27: >> 28: include $(SPEC) >> 29: include MakeBase.gmk > > This should be replaced with just `include MakeFileStart.gmk` since [JDK-8349515](https://bugs.openjdk.org/browse/JDK-8349515), and the file should end with `include MakeFileEnd.gmk`. This will declare `all` as the default target and declare `all: $(TARGETS)` at the bottom. You will need to retain the `images` target and the `.PHONY` declaration for `images`. I updated the file using the same format as the existing BuildJtregTestThreadFactory.gmk file. Could you check if I missed anything? > make/test/BuildJtregSetupAOT.gmk line 41: > >> 39: SETUP_AOT_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/jtreg_setup_aot >> 40: SETUP_AOT_JAR := $(SETUP_AOT_SUPPORT)/jtregSetupAOT.jar >> 41: SETUP_AOT_CLASS := $(SETUP_AOT_SUPPORT)/classes/ExerciseJDKClasses.class > > We do not encourage aligning assignments like this in the makefiles. > https://openjdk.org/groups/build/doc/code-conventions.html Fixed. I also fixed other places where we had such alignments. > make/test/BuildJtregSetupAOT.gmk line 47: > >> 45: SRC := $(SETUP_AOT_BASEDIR), \ >> 46: BIN := $(SETUP_AOT_SUPPORT)/classes, \ >> 47: JAR := $(SETUP_AOT_JAR), \ > > If we aren't using the jar, no need to build it. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776675 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776539 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776731 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776643 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776608 PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776564 From dlong at openjdk.org Wed Feb 19 00:37:14 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 19 Feb 2025 00:37:14 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: > When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. > > In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. > > Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. Dean Long has updated the pull request incrementally with one additional commit since the last revision: Stricter assertion on ppc64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23557/files - new: https://git.openjdk.org/jdk/pull/23557/files/a7a0ed7a..ebf10dae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23557&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23557&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23557/head:pull/23557 PR: https://git.openjdk.org/jdk/pull/23557 From dlong at openjdk.org Wed Feb 19 00:39:54 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 19 Feb 2025 00:39:54 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Mon, 17 Feb 2025 11:27:17 GMT, Richard Reingruber wrote: >>> I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). >> >> Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. > >> > I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). >> >> Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. > > Correct, the top frame has a frame::top_ijava_frame_abi but the assertion is about the abi section in the current frame's caller and the the bottom frame's caller also has a top_ijava_frame_abi because i2c doesn't modify it. > > Continue reading if you're interested in more details... > > As said the i2c adapter does *not* trimm the caller frame as the interpreter would, > replacing its large `top_ijava_frame_abi` with a smaller > `parent_ijava_frame_abi`. > > > > Example: compiled frame DEOPTEE is replaced with 3 interpreted frames > > Stack before deoptimization > > | | > | Interpreted CALLER | > | of DEOPTEE frame | > | | > +------------------------+ > | | > | top_ijava_frame_abi | > | | > +========================+ > | | > | Compiled | > | DEOPTEE | > | | > +------------------------+ > | java_abi | > +========================+ > > > Stack when assertion is checked > (i.e. after DEOPTEE was replaced by corresponding inter. frames) > > | | > | Interpreted CALLER | > | of DEOPTEE frame | > | | > +------------------------+ > | | > | top_ijava_frame_abi | <- i2c keeps large abi > | | > +========================+ > | | <- bottom frame > | Interpreted Frame 0 | > | corresp. to DEOPTEE | > | | > +------------------------+ > | parent_ijava_frame_abi | > +========================+ > | | > | Interpreted Frame 1 | > | (inlined by DEOPTEE) | > | | > +------------------------+ > | parent_ijava_frame_abi | > +========================+ > | | <- top frame > | Interpreted Frame 2 | > | (inlined by DEOPTEE) | > | | > +------------------------+ > | | > | top_ijava_frame_abi | > | | > +========================+ > > Notes: > (refering to the frame sections rather than the C++ types) > > - top_ijava_frame_abi comp... @reinrich OK, got it! I pushed your change. Could you also comment on if we could use the value of sender_sp here instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2667234850 From dholmes at openjdk.org Wed Feb 19 04:34:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Feb 2025 04:34:59 GMT Subject: RFR: 8340110: Ubsan: verifier.cpp:2043:19: runtime error: shift exponent 100 is too large for 32-bit type 'int' [v2] In-Reply-To: References: <4FrziyD0O-ABGO-1syUg5EvoouUvOtmvfOddNqYVZJs=.747088e1-4868-45df-a609-a43043a8e360@github.com> <2ldSQdALsYODaQsss6KeUncB8vNs96mwblfnEB_cdXw=.7a447719-3dbe-4906-8a75-70445e7d3eb4@github.com> <_MWl79GF5Ruj8g899kcU687QXXDk4696djc-Ybl8ZU0=.e5702a21-7a69-4e0e-8ce7-6502a20e1932@github.com> Message-ID: <4nelsWunuEuJsV_y5txBKSpe2iF1nUlzxQjnSscBkqg=.03592c6f-8f3b-4ebf-9644-42ab9fee8f7d@github.com> On Tue, 18 Feb 2025 09:34:42 GMT, Afshin Zafari wrote: > Can I take this PR as trivial? Just for future reference, no. Although the code change ends up being simple, the actual change and the underlying issue is not trivial. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23539#issuecomment-2667484381 From dholmes at openjdk.org Wed Feb 19 05:27:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Feb 2025 05:27:52 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 12:56:14 GMT, Johan Sj?len wrote: > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. > > In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. I need to mull on this. It seems like an awful lot of extra code to support a testing scenario. src/hotspot/share/logging/logConfiguration.cpp line 723: > 721: > 722: > 723: #ifdef assert That should be ASSERT ------------- PR Review: https://git.openjdk.org/jdk/pull/23675#pullrequestreview-2625661434 PR Review Comment: https://git.openjdk.org/jdk/pull/23675#discussion_r1960972628 From rrich at openjdk.org Wed Feb 19 09:25:55 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 19 Feb 2025 09:25:55 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v2] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Mon, 17 Feb 2025 11:27:17 GMT, Richard Reingruber wrote: >>> I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). >> >> Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. > >> > I think you can make the assertion a little stricter like this [reinrich at 9c3c8a3](https://github.com/reinrich/jdk/commit/9c3c8a33a29b9ae6c4c703992b306dc0cbbcd2f0). >> >> Regarding this stricter version, why are you using is_bottom_frame instead of is_top_frame? The deoptimization code seems to name the most recent leaf frame "top". That sounds like what frame::top_ijava_frame_abi_size is for too. > > Correct, the top frame has a frame::top_ijava_frame_abi but the assertion is about the abi section in the current frame's caller and the the bottom frame's caller also has a top_ijava_frame_abi because i2c doesn't modify it. > > Continue reading if you're interested in more details... > > As said the i2c adapter does *not* trimm the caller frame as the interpreter would, > replacing its large `top_ijava_frame_abi` with a smaller > `parent_ijava_frame_abi`. > > > > Example: compiled frame DEOPTEE is replaced with 3 interpreted frames > > Stack before deoptimization > > | | > | Interpreted CALLER | > | of DEOPTEE frame | > | | > +------------------------+ > | | > | top_ijava_frame_abi | > | | > +========================+ > | | > | Compiled | > | DEOPTEE | > | | > +------------------------+ > | java_abi | > +========================+ > > > Stack when assertion is checked > (i.e. after DEOPTEE was replaced by corresponding inter. frames) > > | | > | Interpreted CALLER | > | of DEOPTEE frame | > | | > +------------------------+ > | | > | top_ijava_frame_abi | <- i2c keeps large abi > | | > +========================+ > | | <- bottom frame > | Interpreted Frame 0 | > | corresp. to DEOPTEE | > | | > +------------------------+ > | parent_ijava_frame_abi | > +========================+ > | | > | Interpreted Frame 1 | > | (inlined by DEOPTEE) | > | | > +------------------------+ > | parent_ijava_frame_abi | > +========================+ > | | <- top frame > | Interpreted Frame 2 | > | (inlined by DEOPTEE) | > | | > +------------------------+ > | | > | top_ijava_frame_abi | > | | > +========================+ > > Notes: > (refering to the frame sections rather than the C++ types) > > - top_ijava_frame_abi comp... > @reinrich OK, got it! I pushed your change. Thanks. > Could you also comment on if we could use the value of sender_sp here instead? You mean for the calculation of `l2` at L135? sender_sp has room for `Method::max_stack()`. Using it would be less strict. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2668028520 From duke at openjdk.org Wed Feb 19 09:34:26 2025 From: duke at openjdk.org (Nicole Xu) Date: Wed, 19 Feb 2025 09:34:26 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe Message-ID: The UnsafeOps JMH benchmark fails with the following error: java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. ------------- Commit messages: - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe Changes: https://git.openjdk.org/jdk/pull/23686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349944 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23686/head:pull/23686 PR: https://git.openjdk.org/jdk/pull/23686 From jsjolen at openjdk.org Wed Feb 19 09:35:31 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 09:35:31 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: References: Message-ID: <6lnLuKAN6UGuybV18J4ZhseBjMl6w0vgtwJAR9TDKuY=.089b2824-153f-4974-b664-75c1f7e3914d@github.com> > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. > > In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: ASSERT not assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23675/files - new: https://git.openjdk.org/jdk/pull/23675/files/8fb5aba3..d2cfe22f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23675&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23675&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23675/head:pull/23675 PR: https://git.openjdk.org/jdk/pull/23675 From jsjolen at openjdk.org Wed Feb 19 09:35:32 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 09:35:32 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 05:25:09 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> ASSERT not assert > > src/hotspot/share/logging/logConfiguration.cpp line 723: > >> 721: >> 722: >> 723: #ifdef assert > > That should be ASSERT Oops, I forgot to push that change yesterday. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23675#discussion_r1961299554 From mdoerr at openjdk.org Wed Feb 19 09:37:52 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 19 Feb 2025 09:37:52 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > unsigned long long int __ctx(sp); > unsigned long long int __ctx(pc); > unsigned long long int __ctx(pstate); > /* This field contains extension records for additional processor > state such as the FP/SIMD state. It has to match the definition > of the corresponding field in the sigcontext struct, see the > arch/arm64/include/uapi/asm/sigcontext.h linux header for details. */ > unsigned char __reserved[4096] __attribute__ ((__aligned__ (16))); > } mcontext_t; > > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23667#pullrequestreview-2626182671 From duke at openjdk.org Wed Feb 19 10:06:51 2025 From: duke at openjdk.org (Nicole Xu) Date: Wed, 19 Feb 2025 10:06:51 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu wrote: > The UnsafeOps JMH benchmark fails with the following error: > > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > > To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. Hi @AlanBateman. Here is a bug fix for the micro benchmark of class Unsafe. Could you please review the changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2668146656 From alanb at openjdk.org Wed Feb 19 10:32:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Feb 2025 10:32:53 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu wrote: > The UnsafeOps JMH benchmark fails with the following error: > > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > > To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. This micro was created for sun.misc.Unsafe, not jdk.internal.misc.Unsafe. The change for JDK-8332744 should not have changed this test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2668214764 From jsjolen at openjdk.org Wed Feb 19 10:36:54 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 10:36:54 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: <6lnLuKAN6UGuybV18J4ZhseBjMl6w0vgtwJAR9TDKuY=.089b2824-153f-4974-b664-75c1f7e3914d@github.com> References: <6lnLuKAN6UGuybV18J4ZhseBjMl6w0vgtwJAR9TDKuY=.089b2824-153f-4974-b664-75c1f7e3914d@github.com> Message-ID: On Wed, 19 Feb 2025 09:35:31 GMT, Johan Sj?len wrote: >> Hi, >> >> [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. >> >> In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > ASSERT not assert OK, I want to get builds going again ASAP. I'm going in with a trivial fix (Removing `ShouldNotReachHere` and removing the death test) to then re-enable it in a future PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23675#issuecomment-2668225317 From mbaesken at openjdk.org Wed Feb 19 12:16:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Feb 2025 12:16:56 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > unsigned long long int __ctx(sp); > unsigned long long int __ctx(pc); > unsigned long long int __ctx(pstate); > /* This field contains extension records for additional processor > state such as the FP/SIMD state. It has to match the definition > of the corresponding field in the sigcontext struct, see the > arch/arm64/include/uapi/asm/sigcontext.h linux header for details. */ > unsigned char __reserved[4096] __attribute__ ((__aligned__ (16))); > } mcontext_t; > > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2668478810 From mbaesken at openjdk.org Wed Feb 19 12:16:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Feb 2025 12:16:57 GMT Subject: Integrated: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:16:22 GMT, Matthias Baesken wrote: > When running jtreg test VendorInfoPluginsTest we noticed the following issue (ubsanized binaries were used) > > > jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:369:46: runtime error: index 31 out of bounds for type 'long long unsigned int [31]' > #0 0xffff84380470 in os::print_register_info(outputStream*, void const*, int&) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x4d80470) > #1 0xffff84bf566c in VMError::report(outputStream*, bool) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f566c) > #2 0xffff84bf812c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f812c) > #3 0xffff84bf90b4 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*, char const*, ...) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f90b4) > #4 0xffff84bf9138 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x55f9138) > #5 0xffff8489ede8 in JVM_handle_linux_signal (/jtreg_jdk_tier2_work/JTwork/scratch/10/images/vendorinfo.image/lib/server/libjvm.so+0x529ede8) > > > Looks like we have registers 0 - 30 according to sys/ucontext.h on Linux aarch64 > > > typedef struct > { > unsigned long long int __ctx(fault_address); > unsigned long long int __ctx(regs)[31]; > unsigned long long int __ctx(sp); > unsigned long long int __ctx(pc); > unsigned long long int __ctx(pstate); > /* This field contains extension records for additional processor > state such as the FP/SIMD state. It has to match the definition > of the corresponding field in the sigcontext struct, see the > arch/arm64/include/uapi/asm/sigcontext.h linux header for details. */ > unsigned char __reserved[4096] __attribute__ ((__aligned__ (16))); > } mcontext_t; > > > > and according to the arm developer documentation > > https://developer.arm.com/documentation/100069/0606/Overview-of-AArch64-state/Registers-in-AArch64-state#:~:text=In%20AArch64%20state%2C%20the%20following,are%20accessible%20as%20W0%2DW30. > > "Thirty-one 64-bit general-purpose registers X0-X30, the bottom halves of which are accessible as W0-W30." This pull request has now been integrated. Changeset: 59810ad7 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/59810ad745b28f50d287fa8db650c3f1924791d9 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8350201: Out of bounds access on Linux aarch64 in os::print_register_info Reviewed-by: dholmes, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/23667 From jsjolen at openjdk.org Wed Feb 19 13:26:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 13:26:59 GMT Subject: Withdrawn: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 12:56:14 GMT, Johan Sj?len wrote: > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. > > In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23675 From jsjolen at openjdk.org Wed Feb 19 13:33:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 13:33:02 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: <6lnLuKAN6UGuybV18J4ZhseBjMl6w0vgtwJAR9TDKuY=.089b2824-153f-4974-b664-75c1f7e3914d@github.com> References: <6lnLuKAN6UGuybV18J4ZhseBjMl6w0vgtwJAR9TDKuY=.089b2824-153f-4974-b664-75c1f7e3914d@github.com> Message-ID: <5ZoCFGQieWYW9DjBrQpB4PRsdKRkhsJNgxXkm3gggiA=.e2a0e793-f3c6-4579-9ed9-1dd0e524dd8b@github.com> On Wed, 19 Feb 2025 09:35:31 GMT, Johan Sj?len wrote: >> Hi, >> >> [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with `-Xlog:async -Xlog:all=debug`. Specifically, this will cause UL to select for `deathtest` and `deathtest2`, which should only be selected when explicitly asked for. >> >> In order to fix this, I've added a small debug-only snippet which ensures that any wildcard selector does not select `deathtest` or `deathtest2`. I've also added a testcase in order to catch this regression. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > ASSERT not assert Please see https://github.com/openjdk/jdk/pull/23695 for a greatly simplified solution to this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23675#issuecomment-2668661942 From jsjolen at openjdk.org Wed Feb 19 14:10:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 19 Feb 2025 14:10:30 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 Message-ID: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Hi, [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. Let's go through the cases: -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes ------------- Commit messages: - Simplify again - Simplify the testing strategy for async logging Changes: https://git.openjdk.org/jdk/pull/23695/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23695&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350214 Stats: 35 lines in 6 files changed: 18 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23695/head:pull/23695 PR: https://git.openjdk.org/jdk/pull/23695 From erikj at openjdk.org Wed Feb 19 14:26:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Feb 2025 14:26:56 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v6] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 00:27:17 GMT, Ioi Lam wrote: >> When running HotSpot jtreg tests in the "AOT mode", for example: >> >> >> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable >> >> >> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: >> >> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 >> >> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. >> >> ** Changes in this PR ** >> >> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @erikj79 make/test/BuildTestSetupAOT.gmk line 63: > 61: IMAGES_TARGETS += $(COPY_SETUP_AOT) > 62: > 63: build: $(TARGETS) The target `build` is no longer the default target in this makefile, so this line is dead code unless you change the call in Main.gmk by setting `TARGET := build`. You can also just remove this line as the default target `all` gets setup to depend on `$(TARGETS)` anyway in MakeFileEnd.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1961773716 From aboldtch at openjdk.org Wed Feb 19 14:48:59 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 19 Feb 2025 14:48:59 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Wed, 19 Feb 2025 13:29:39 GMT, Johan Sj?len wrote: > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. > > In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. > > Let's go through the cases: > > > -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) > -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken > -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes Changes requested by aboldtch (Reviewer). src/hotspot/share/runtime/globals.hpp line 487: > 485: "Recursive logging death test") \ > 486: develop(bool, TestingAsyncLoggingDeathTestNoCrash, falseInDebug, \ > 487: "Recursive logging death test (no crash)") \ `falseInDebug` means `true` when `ASSERT` is not defined. Think these should just be `false`. ------------- PR Review: https://git.openjdk.org/jdk/pull/23695#pullrequestreview-2627046294 PR Review Comment: https://git.openjdk.org/jdk/pull/23695#discussion_r1961815990 From matsaave at openjdk.org Wed Feb 19 14:54:31 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 19 Feb 2025 14:54:31 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v3] In-Reply-To: References: Message-ID: <1Gs2qaUsotd3MxU8EoMuyG62LbzF0FfrFDoK3suYFzY=.bddcc091-4953-4a6c-80ac-29e1077cdfcf@github.com> > This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: David suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23645/files - new: https://git.openjdk.org/jdk/pull/23645/files/9a78ba6d..ca0b0254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23645&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23645&range=01-02 Stats: 14 lines in 2 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23645/head:pull/23645 PR: https://git.openjdk.org/jdk/pull/23645 From aboldtch at openjdk.org Wed Feb 19 14:55:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 19 Feb 2025 14:55:53 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Wed, 19 Feb 2025 14:44:51 GMT, Axel Boldt-Christmas wrote: >> Hi, >> >> [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. >> >> In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. >> >> Let's go through the cases: >> >> >> -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) >> -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken >> -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes > > src/hotspot/share/runtime/globals.hpp line 487: > >> 485: "Recursive logging death test") \ >> 486: develop(bool, TestingAsyncLoggingDeathTestNoCrash, falseInDebug, \ >> 487: "Recursive logging death test (no crash)") \ > > `falseInDebug` means `true` when `ASSERT` is not defined. Think these should just be `false`. Even if it does not matter because we guard the use of the flags by `ASSERT`, it looks strange that the values end up being `true`/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23695#discussion_r1961831467 From liach at openjdk.org Wed Feb 19 15:59:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 19 Feb 2025 15:59:52 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu wrote: > The UnsafeOps JMH benchmark fails with the following error: > > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > > To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. Yeah, a better fix for this would be to change the import of jdk.internal.misc back to sun.misc, as before JDK-8332744. Unfortunately we will have to accept the "proprietary API" warning, but they are necessary as such APIs are bound for removal for the integrity of the platform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2669069824 From coleenp at openjdk.org Wed Feb 19 17:15:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 19 Feb 2025 17:15:03 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v3] In-Reply-To: <1Gs2qaUsotd3MxU8EoMuyG62LbzF0FfrFDoK3suYFzY=.bddcc091-4953-4a6c-80ac-29e1077cdfcf@github.com> References: <1Gs2qaUsotd3MxU8EoMuyG62LbzF0FfrFDoK3suYFzY=.bddcc091-4953-4a6c-80ac-29e1077cdfcf@github.com> Message-ID: On Wed, 19 Feb 2025 14:54:31 GMT, Matias Saavedra Silva wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > David suggestions This looks good. David had good suggestions. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23645#pullrequestreview-2627476232 From matsaave at openjdk.org Wed Feb 19 17:28:56 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 19 Feb 2025 17:28:56 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader In-Reply-To: <6M0Xvs-wLmhaTOaW8CnSM9pBSkAHWlzkMpsJbb1wsF0=.e6056ea7-4fcd-477b-a861-55d725d6deaa@github.com> References: <6M0Xvs-wLmhaTOaW8CnSM9pBSkAHWlzkMpsJbb1wsF0=.e6056ea7-4fcd-477b-a861-55d725d6deaa@github.com> Message-ID: On Fri, 14 Feb 2025 19:32:28 GMT, Coleen Phillimore wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests > > Never mind, I do know why frame_count might change with your upcoming changes. Thanks for the reviews and suggestions @coleenp and @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23645#issuecomment-2669298522 From matsaave at openjdk.org Wed Feb 19 17:28:57 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 19 Feb 2025 17:28:57 GMT Subject: Integrated: 8349923: Refactor StackMapTable constructor and StackMapReader In-Reply-To: References: Message-ID: <_MCbaOjCsnoztT8FdUN4S7SsQVYkeuZhyHMb38yCsWg=.14450911-c681-437d-bdb3-ffdf51c8a35c@github.com> On Fri, 14 Feb 2025 18:28:51 GMT, Matias Saavedra Silva wrote: > This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests This pull request has now been integrated. Changeset: 76319845 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/76319845255d5f71acb2f88e684ba788bdadfa93 Stats: 170 lines in 3 files changed: 61 ins; 18 del; 91 mod 8349923: Refactor StackMapTable constructor and StackMapReader Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23645 From iklam at openjdk.org Wed Feb 19 19:20:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 19 Feb 2025 19:20:13 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v7] In-Reply-To: References: Message-ID: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Review comments from @erikj79 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23620/files - new: https://git.openjdk.org/jdk/pull/23620/files/b5ccc05d..3d25d75a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23620&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620 PR: https://git.openjdk.org/jdk/pull/23620 From iklam at openjdk.org Wed Feb 19 19:20:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 19 Feb 2025 19:20:13 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v6] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 14:21:40 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from @erikj79 > > make/test/BuildTestSetupAOT.gmk line 63: > >> 61: IMAGES_TARGETS += $(COPY_SETUP_AOT) >> 62: >> 63: build: $(TARGETS) > > The target `build` is no longer the default target in this makefile, so this line is dead code unless you change the call in Main.gmk by setting `TARGET := build`. You can also just remove this line as the default target `all` gets setup to depend on `$(TARGETS)` anyway in MakeFileEnd.gmk. I removed this line and verified TestSetupAOT.class is still created inside the test image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1962240880 From pchilanomate at openjdk.org Wed Feb 19 19:21:54 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 19 Feb 2025 19:21:54 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:37:27 GMT, Serguei Spitsyn wrote: >> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp endThread()` and others are returned. For instance, some `SingleStep` events can be posted. >> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. >> >> Testing: >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: > > - removed obsolete fragment that was not removed in last update > - review: re-fixed the issue as initial fix was wrong Thanks Serguei, some comments below. > I treat it as VM/JVMTI bug as it looks silly when events are posted event though they were enabled after suspension. Yes, it is an attempt to do he saner thing. > Ok, makes sense. > make this fix common for platform and virtual threads; I can try to update the failing test to prove we have the same issue for platform threads too; will correct the PR description then > For this particular event I don?t think the crash can happen with platform threads because get_jvmti_thread_state() will only block for virtual threads. And I don?t see any other blocking points in InterpreterRuntime::at_safepoint() other than that one. But for other events it can happen since the thread might have been blocked and suspended at some point before (looking at post_class_prepare/post_class_load for example). This leads to another question, should we add this suspend check for all JvmtiExport::post_xxx methods? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2669550122 From erikj at openjdk.org Wed Feb 19 21:03:54 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Feb 2025 21:03:54 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v7] In-Reply-To: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> References: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> Message-ID: On Wed, 19 Feb 2025 19:20:13 GMT, Ioi Lam wrote: >> When running HotSpot jtreg tests in the "AOT mode", for example: >> >> >> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable >> >> >> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: >> >> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 >> >> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. >> >> ** Changes in this PR ** >> >> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @erikj79 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2627971059 From ccheung at openjdk.org Wed Feb 19 23:45:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 19 Feb 2025 23:45:54 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v7] In-Reply-To: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> References: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> Message-ID: On Wed, 19 Feb 2025 19:20:13 GMT, Ioi Lam wrote: >> When running HotSpot jtreg tests in the "AOT mode", for example: >> >> >> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable >> >> >> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: >> >> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 >> >> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. >> >> ** Changes in this PR ** >> >> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @erikj79 Hotspot changes look good. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2628228204 From dholmes at openjdk.org Thu Feb 20 01:05:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Feb 2025 01:05:56 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Wed, 19 Feb 2025 14:53:09 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/globals.hpp line 487: >> >>> 485: "Recursive logging death test") \ >>> 486: develop(bool, TestingAsyncLoggingDeathTestNoCrash, falseInDebug, \ >>> 487: "Recursive logging death test (no crash)") \ >> >> `falseInDebug` means `true` when `ASSERT` is not defined. Think these should just be `false`. > > Even if it does not matter because we guard the use of the flags by `ASSERT`, it looks strange that the values end up being `true`/ Agreed - these flags default to "false" always ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23695#discussion_r1962601439 From dholmes at openjdk.org Thu Feb 20 01:09:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Feb 2025 01:09:56 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 In-Reply-To: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Wed, 19 Feb 2025 13:29:39 GMT, Johan Sj?len wrote: > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. > > In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. > > Let's go through the cases: > > > -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) > -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken > -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes This approach to testing works better for me. Looks good modulo the one change Axel requested. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23695#pullrequestreview-2628341146 From iklam at openjdk.org Thu Feb 20 02:16:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 20 Feb 2025 02:16:00 GMT Subject: RFR: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" [v7] In-Reply-To: References: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com> Message-ID: On Wed, 19 Feb 2025 21:01:06 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from @erikj79 > > Marked as reviewed by erikj (Reviewer). Thanks @erikj79 @calvinccheung for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23620#issuecomment-2670294223 From iklam at openjdk.org Thu Feb 20 02:16:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 20 Feb 2025 02:16:02 GMT Subject: Integrated: 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 17:45:45 GMT, Ioi Lam wrote: > When running HotSpot jtreg tests in the "AOT mode", for example: > > > make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable > > > Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq: > > https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744 > > After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation. > > ** Changes in this PR ** > > This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory, This pull request has now been integrated. Changeset: 0131c1bf Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/0131c1bfd8ccfdf4f3d73cddfc2a87e2a6e99581 Stats: 194 lines in 5 files changed: 158 ins; 18 del; 18 mod 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true" Reviewed-by: erikj, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/23620 From dholmes at openjdk.org Thu Feb 20 03:00:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Feb 2025 03:00:57 GMT Subject: RFR: 8349923: Refactor StackMapTable constructor and StackMapReader [v3] In-Reply-To: <1Gs2qaUsotd3MxU8EoMuyG62LbzF0FfrFDoK3suYFzY=.bddcc091-4953-4a6c-80ac-29e1077cdfcf@github.com> References: <1Gs2qaUsotd3MxU8EoMuyG62LbzF0FfrFDoK3suYFzY=.bddcc091-4953-4a6c-80ac-29e1077cdfcf@github.com> Message-ID: <_beSO1RCJ41T6lWuA2ovySz5t5djkmK9CIFo2mD4ojg=.fac25303-731d-4058-9b6d-e85415a5dc7a@github.com> On Wed, 19 Feb 2025 14:54:31 GMT, Matias Saavedra Silva wrote: >> This patch refactors the `StackMapReader` to clean up the `StackMapTable` constructor. The `StackMapReader` class is extended to hold more fields used for verification purposes and allows for a simpler StackMapTable constructor. Additionally, in preparation for further changes to verification, the `_frame_count` may not be equal to the value reported by the classfile, so a new structure is used to generate the `_frame_array`. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > David suggestions src/hotspot/share/classfile/stackMapTable.cpp line 233: > 231: StackMapFrame* frame = next_helper(CHECK_VERIFY_(_verifier, nullptr)); > 232: if (frame != nullptr) { > 233: check_offset(frame); `check_offset` can install a verifier error, so I think you need to check for that! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23645#discussion_r1962787222 From kbarrett at openjdk.org Thu Feb 20 08:49:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 20 Feb 2025 08:49:56 GMT Subject: RFR: 8350201: Out of bounds access on Linux aarch64 in os::print_register_info In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 08:39:21 GMT, Matthias Baesken wrote: > > aarch64.ad has a comment that probably ought to be fixed: https://github.com/openjdk/jdk/blame/8df804005ed772936fd77a4c0335a5620f909570/src/hotspot/cpu/aarch64/aarch64.ad#L71 > > It also has SP as R31, but I guess that's okay. > > Should I change the comment from 'r27-r32 system (no save, no allocate)' to 'r27-r31 system (no save, no allocate)' ? Sorry, I didn't notice this question earlier, and now this PR has been integrated. Yes, I think s/r32/r31/. There doesn't seem to be an r32 at all (that would be a 33rd register with 0-based numbering). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23667#issuecomment-2670825864 From jsjolen at openjdk.org Thu Feb 20 09:20:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 20 Feb 2025 09:20:07 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: > Hi, > > [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. > > In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. > > Let's go through the cases: > > > -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) > -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken > -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23695/files - new: https://git.openjdk.org/jdk/pull/23695/files/1ac6540b..891d048a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23695&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23695&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23695/head:pull/23695 PR: https://git.openjdk.org/jdk/pull/23695 From aboldtch at openjdk.org Thu Feb 20 09:24:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Feb 2025 09:24:53 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Thu, 20 Feb 2025 09:20:07 GMT, Johan Sj?len wrote: >> Hi, >> >> [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. >> >> In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. >> >> Let's go through the cases: >> >> >> -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) >> -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken >> -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23695#pullrequestreview-2629196242 From jsjolen at openjdk.org Thu Feb 20 09:36:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 20 Feb 2025 09:36:44 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v3] In-Reply-To: References: Message-ID: > Today NMT has two canaries: A header and a footer canary. These enable mainly two things: > > 1. For NMT to aid in describing a pointer > 2. A basic form of out-of-bounds protection > > With the introduction of UBSan and Asan into OpenJDK we have gained stronger tools for this sort of analysis, without requiring NMT to be activated. Therefore, I believe that point 2 is no longer something that NMT needs to support. For point number one, we will unfortunately be losing this ability. > > I want to delete these canaries to open up a few free bytes. These can allow us to have "practically unlimited" (4 bytes) of memory tags. > > tier1-tier2 tests succeeded. > > I am awaiting discussion on the Hotspot-dev mailing list, but keeping this PR open for review. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge remote-tracking branch 'openjdk/master' into delete-canaries - Comment - Rename flags to tags - Remove canaries ------------- Changes: https://git.openjdk.org/jdk/pull/21560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21560&range=02 Stats: 366 lines in 8 files changed: 0 ins; 353 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/21560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21560/head:pull/21560 PR: https://git.openjdk.org/jdk/pull/21560 From dholmes at openjdk.org Thu Feb 20 12:17:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Feb 2025 12:17:57 GMT Subject: RFR: 8350214: Test gtest/AsyncLogGtest.java fails after JDK-8349755 [v2] In-Reply-To: References: <976lKZ8ywDNX97Z7cDG-sZ85BlpjANE_sxL-7vbQvdg=.df85189b-df0b-42d7-9804-0b77e8b1e365@github.com> Message-ID: On Thu, 20 Feb 2025 09:20:07 GMT, Johan Sj?len wrote: >> Hi, >> >> [8349755](https://bugs.openjdk.org/browse/JDK-8349755) introduced a bug in debug builds when running with -Xlog:async -Xlog:all=debug. Specifically, this will cause UL to select for deathtest and deathtest2, which should only be selected when explicitly asked for. >> >> In order to fix this, I've added some develop-only globals. We now only log if either of the testing globals are set, and we only crash on recursive logging if `TestingAsyncLoggingDeathTestNoCrash` is set to `false`. >> >> Let's go through the cases: >> >> >> -Xlog:all=debug => deathtest isn't logged because the globals aren't set => Only non-deathtest recursive logs crash (as it should be) >> -Xlog:all=debug + TestingAsyncLoggingDeathTestNoCrash => deathtest is logged, but TestingAsyncLoggingDeathTestNoCrash is true so the ShouldNotReachHere branch isn't taken >> -Xlog:all=debug + TestingAsyncLoggingDeathTest => deathtest is logged, and it crashes > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23695#pullrequestreview-2629672321 From schernyshev at openjdk.org Thu Feb 20 17:16:56 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 20 Feb 2025 17:16:56 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 15:48:51 GMT, Matthias Baesken wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> added details in the log message > > src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, 2024, Red Hat Inc. > > You did not touch the test but change the COPYRIGHT year, why ? Hi Matthias, thanks for spotting this. This is the leftover from the previous version of the patch. I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964037810 From schernyshev at openjdk.org Thu Feb 20 17:29:37 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 20 Feb 2025 17:29:37 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v12] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Severin Gehwolf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/a3002a92..39f44e92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Thu Feb 20 17:32:32 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 20 Feb 2025 17:32:32 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v13] In-Reply-To: References: Message-ID: <_60M7CyqmgwYG1XOgkI-IGVqFCv9ZKW3oHFnwLiKUGA=.53db28b3-5c41-45f8-a198-f93bd03d8e85@github.com> > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: revert header change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/39f44e92..8e8ab869 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Thu Feb 20 17:36:04 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 20 Feb 2025 17:36:04 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:09:12 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> added details in the log message > > src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73: > >> 71: break; >> 72: } >> 73: cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of(""); > > Suggestion: > > cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of(""); Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964064662 From matsaave at openjdk.org Thu Feb 20 20:05:06 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 20 Feb 2025 20:05:06 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() Message-ID: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests ------------- Commit messages: - 8350444: Check for verifer error in StackMapReader::check_offset() Changes: https://git.openjdk.org/jdk/pull/23717/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23717&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350444 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23717.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23717/head:pull/23717 PR: https://git.openjdk.org/jdk/pull/23717 From coleenp at openjdk.org Thu Feb 20 21:31:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Feb 2025 21:31:54 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() In-Reply-To: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> Message-ID: On Thu, 20 Feb 2025 19:19:02 GMT, Matias Saavedra Silva wrote: > This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23717#pullrequestreview-2631200245 From sspitsyn at openjdk.org Thu Feb 20 21:48:28 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Feb 2025 21:48:28 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v3] In-Reply-To: References: Message-ID: <8T2Vr37z4kRLQswdQTcxnkkq7H5QPl4D3esYBPk3JKw=.49792865-074c-417f-82db-be5a486b8482@github.com> > The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Suspe ndThread()` and others are returned. For instance, some `SingleStep` events can be posted. > The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same. > > Testing: > - Ran 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 four additional commits since the last revision: - Merge - removed obsolete fragment that was not removed in last update - review: re-fixed the issue as initial fix was wrong - 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23490/files - new: https://git.openjdk.org/jdk/pull/23490/files/c36f3188..d2b76873 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=01-02 Stats: 24357 lines in 1136 files changed: 15711 ins; 4551 del; 4095 mod Patch: https://git.openjdk.org/jdk/pull/23490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490 PR: https://git.openjdk.org/jdk/pull/23490 From sspitsyn at openjdk.org Thu Feb 20 22:03:52 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Feb 2025 22:03:52 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 19:19:25 GMT, Patricio Chilano Mateo wrote: > For this particular event I don?t think the crash can happen with platform threads because get_jvmti_thread_state() will only block for virtual threads. And I don?t see any other blocking points in InterpreterRuntime::at_safepoint() other than that one. Thank you for the comment. I agree, the `get_jvmti_thread_state()` will only block for virtual threads. > But for other events it can happen since the thread might have been blocked and suspended at some point before (looking at post_class_prepare/post_class_load for example). This leads to another question, should we add this suspend check for all JvmtiExport::post_xxx methods? Right. I wanted to address this separately as you mentioned before that the same issue should exist for other event types. However, I'll move this check to the `get_jvmti_thread_state()` function. It should work for all events then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2672786201 From matsaave at openjdk.org Thu Feb 20 23:02:09 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 20 Feb 2025 23:02:09 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> Message-ID: <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> > This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Check for exception without TRAPS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23717/files - new: https://git.openjdk.org/jdk/pull/23717/files/532c6ecc..0d56c012 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23717&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23717&range=00-01 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23717.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23717/head:pull/23717 PR: https://git.openjdk.org/jdk/pull/23717 From sspitsyn at openjdk.org Fri Feb 21 01:31:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Feb 2025 01:31:42 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: Message-ID: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> > The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`. It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function. > > Testing: > - Ran mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: move suspend point from post_single_step() to get_jvmti_thread_state() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23490/files - new: https://git.openjdk.org/jdk/pull/23490/files/d2b76873..2e099aad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490 PR: https://git.openjdk.org/jdk/pull/23490 From dholmes at openjdk.org Fri Feb 21 02:02:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Feb 2025 02:02:20 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> Message-ID: On Thu, 20 Feb 2025 23:02:09 GMT, Matias Saavedra Silva wrote: >> This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Check for exception without TRAPS Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23717#pullrequestreview-2631641711 From iklam at openjdk.org Fri Feb 21 03:12:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 21 Feb 2025 03:12:52 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 00:25:39 GMT, Calvin Cheung wrote: > This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. > Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: > > > [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: > [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST > > Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. > > Passed tiers 1 - 3 testing. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23546#pullrequestreview-2631763844 From dholmes at openjdk.org Fri Feb 21 03:19:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Feb 2025 03:19:53 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> Message-ID: On Fri, 21 Feb 2025 01:31:42 GMT, Serguei Spitsyn wrote: >> The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`. It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function. >> >> Testing: >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: move suspend point from post_single_step() to get_jvmti_thread_state() src/hotspot/share/prims/jvmtiExport.cpp line 428: > 426: // suspend here if there is a suspend request > 427: ThreadBlockInVM tbivm(thread, true /* allow suspend */); > 428: } This positioning seems better than the previous one, but it still causes me concern as a get function should not really have a side-effect of blocking due to suspension, in my view. What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1964731467 From dholmes at openjdk.org Fri Feb 21 03:33:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Feb 2025 03:33:52 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> Message-ID: On Thu, 20 Feb 2025 23:02:09 GMT, Matias Saavedra Silva wrote: >> This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Check for exception without TRAPS BTW the fact this got through testing unnoticed indicates we have a gap in test coverage. We should see if we can fill that gap. Though it may be that any verification error caused by check_offset would be quickly found by a following check and so we still fail as expected, just a little later in the verification process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23717#issuecomment-2673299543 From dholmes at openjdk.org Fri Feb 21 05:30:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Feb 2025 05:30:33 GMT Subject: RFR: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range Message-ID: See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max Testing: - tiers 1-3 sanity testing Thanks ------------- Commit messages: - 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range Changes: https://git.openjdk.org/jdk/pull/23722/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350464 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/23722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23722/head:pull/23722 PR: https://git.openjdk.org/jdk/pull/23722 From duke at openjdk.org Fri Feb 21 07:01:42 2025 From: duke at openjdk.org (Nicole Xu) Date: Fri, 21 Feb 2025 07:01:42 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: > The UnsafeOps JMH benchmark fails with the following error: > > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > > To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe The UnsafeOps JMH benchmark fails with the following error: ``` java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 ``` Since this micro-benchmark is created for `sun.misc.Unsafe` rather than `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform. Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23686/files - new: https://git.openjdk.org/jdk/pull/23686/files/ebc32ae2..b2bbc24e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23686/head:pull/23686 PR: https://git.openjdk.org/jdk/pull/23686 From alanb at openjdk.org Fri Feb 21 07:12:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Feb 2025 07:12:53 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> >> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. > > Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2673759459 From duke at openjdk.org Fri Feb 21 07:22:52 2025 From: duke at openjdk.org (Nicole Xu) Date: Fri, 21 Feb 2025 07:22:52 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman wrote: > Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage. Yeah. I have updated and only changed `Unsafe` back as you and @liach suggested, so that the runtime error here could be fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2673776382 From syan at openjdk.org Fri Feb 21 07:46:53 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 21 Feb 2025 07:46:53 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: <-gbSFDB_bxqvokrSy_oPuuPbvo6ti3Gha_81z-Qguh0=.41a80af2-ab83-4022-a2b7-c2163ae794eb@github.com> On Fri, 24 Jan 2025 06:36:34 GMT, SendaoYan wrote: > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. On the other hand, I think it's better check macro `LOG_PLEASE` has been defined or not before define it. > Change has been verified locally, test-fix only, risk is low. Hi, can anyone take look this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2673816035 From stuefe at openjdk.org Fri Feb 21 07:54:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 21 Feb 2025 07:54:52 GMT Subject: RFR: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 05:25:44 GMT, David Holmes wrote: > See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max > > Testing: > - tiers 1-3 sanity testing > > Thanks Wow, good catch. How was this never detected until now? We should have a regression case for this (e.g. scanning the nice value in /proc/pid/stat). I guess the CAP_SYS_NICE requirement makes a regression test more complex. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23722#pullrequestreview-2632276771 From shade at openjdk.org Fri Feb 21 08:46:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 21 Feb 2025 08:46:52 GMT Subject: RFR: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 05:25:44 GMT, David Holmes wrote: > See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max > > Testing: > - tiers 1-3 sanity testing > > Thanks Looks fine, thanks. It is a bit sad `-1` remains a special value, but solving that opens another can of worms. At least this allows us to set `VMPriorityThread=-20` on Linux. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23722#pullrequestreview-2632389167 From stuefe at openjdk.org Fri Feb 21 09:04:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 21 Feb 2025 09:04:52 GMT Subject: RFR: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 05:25:44 GMT, David Holmes wrote: > See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max > > Testing: > - tiers 1-3 sanity testing > > Thanks A release note may be useful here. There are a lot of blog articles out there about this topic. I guess this is not a backward compatibility problem, since values lower than -1 have never been accepted by the JVM, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23722#issuecomment-2673974853 From azafari at openjdk.org Fri Feb 21 10:21:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 10:21:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> Message-ID: On Mon, 10 Feb 2025 14:05:37 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/nmt/mallocTracker.hpp line 163: > >> 161: } >> 162: >> 163: inline const MallocMemory* by_tag(MemTag mem_tag) const { > > Move out into mainline PR Done > src/hotspot/share/nmt/mallocTracker.hpp line 241: > >> 239: >> 240: static inline void record_arena_size_change(ssize_t size, MemTag mem_tag) { >> 241: as_snapshot()->by_tag(mem_tag)->record_arena_size_change(size); > > Move out into mainline PR Done. > src/hotspot/share/nmt/mallocTracker.inline.hpp line 55: > >> 53: l = MallocLimitHandler::category_limit(mem_tag); >> 54: if (l->sz > 0) { >> 55: const MallocMemory* mm = as_snapshot()->by_tag(mem_tag); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memBaseline.cpp line 64: > >> 62: >> 63: // Sort into allocation site addresses and memory tag order for baseline comparison >> 64: int compare_malloc_site_and_tag(const MallocSite& s1, const MallocSite& s2) { > > Move out into mainline PR Done > src/hotspot/share/nmt/memBaseline.cpp line 235: > >> 233: break; >> 234: case by_site_and_tag: >> 235: malloc_sites_to_allocation_site_and_tag_order(); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memBaseline.cpp line 275: > >> 273: >> 274: void MemBaseline::malloc_sites_to_allocation_site_order() { >> 275: if (_malloc_sites_order != by_site && _malloc_sites_order != by_site_and_tag) { > > Move out into mainline PR Done. > src/hotspot/share/nmt/memBaseline.cpp line 292: > >> 290: _malloc_sites.set_head(tmp.head()); >> 291: tmp.set_head(nullptr); >> 292: _malloc_sites_order = by_site_and_tag; > > Move out into mainline PR Done > src/hotspot/share/nmt/memBaseline.hpp line 56: > >> 54: by_size, // by memory size >> 55: by_site, // by call site where the memory is allocated from >> 56: by_site_and_tag // by call site and memory tag > > Move out into mainline PR (and indentation of comment seems wrong) Done. > src/hotspot/share/nmt/memBaseline.hpp line 154: > >> 152: VirtualMemory* virtual_memory(MemTag mem_tag) { >> 153: assert(baseline_type() != Not_baselined, "Not yet baselined"); >> 154: return _virtual_memory_snapshot.by_tag(mem_tag); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memBaseline.hpp line 207: > >> 205: void malloc_sites_to_allocation_site_order(); >> 206: // Sort allocation sites in call site address and memory tag order >> 207: void malloc_sites_to_allocation_site_and_tag_order(); > > Move out into mainline PR Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965223803 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965222796 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965224620 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965225380 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965226658 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965227704 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965228209 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965229789 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965229277 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965228847 From azafari at openjdk.org Fri Feb 21 10:30:18 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 10:30:18 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> Message-ID: On Mon, 10 Feb 2025 14:03:21 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/nmt/memReporter.cpp line 201: > >> 199: if (mem_tag == mtThread) { >> 200: const VirtualMemory* thread_stack_usage = >> 201: (const VirtualMemory*)_vm_snapshot->by_tag(mtThreadStack); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memReporter.cpp line 243: > >> 241: } else if (mem_tag == mtThread) { >> 242: const VirtualMemory* thread_stack_usage = >> 243: _vm_snapshot->by_tag(mtThreadStack); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memReporter.cpp line 810: > >> 808: void MemDetailDiffReporter::diff_malloc_sites() const { >> 809: MallocSiteIterator early_itr = _early_baseline.malloc_sites(MemBaseline::by_site_and_tag); >> 810: MallocSiteIterator current_itr = _current_baseline.malloc_sites(MemBaseline::by_site_and_tag); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memoryFileTracker.cpp line 47: > >> 45: VMATree::SummaryDiff diff = file->_tree.commit_mapping(offset, size, regiondata); >> 46: for (int i = 0; i < mt_number_of_tags; i++) { >> 47: VirtualMemory* summary = file->_summary.by_tag(NMTUtil::index_to_tag(i)); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memoryFileTracker.cpp line 56: > >> 54: VMATree::SummaryDiff diff = file->_tree.release_mapping(offset, size); >> 55: for (int i = 0; i < mt_number_of_tags; i++) { >> 56: VirtualMemory* summary = file->_summary.by_tag(NMTUtil::index_to_tag(i)); > > Move out into mainline PR Done. > src/hotspot/share/nmt/memoryFileTracker.cpp line 187: > >> 185: snap->commit_memory(current->committed()); >> 186: } >> 187: } > > Revert this change Done. > src/hotspot/share/nmt/memoryFileTracker.hpp line 81: > >> 79: const MemoryFile* file = _files.at(d); >> 80: for (int i = 0; i < mt_number_of_tags; i++) { >> 81: f(NMTUtil::index_to_tag(i), file->_summary.by_tag(NMTUtil::index_to_tag(i))); > > Move out into mainline PR Done. > src/hotspot/share/nmt/nmtCommon.cpp line 33: > >> 31: >> 32: #define MEMORY_TAG_DECLARE_NAME(tag, human_readable) \ >> 33: { #tag, human_readable }, > > Move out into mainline PR Done. > src/hotspot/share/nmt/nmtCommon.hpp line 91: > >> 89: // Map memory tag to index >> 90: static inline int tag_to_index(MemTag mem_tag) { >> 91: assert(tag_is_valid(mem_tag), "Invalid tag (%u)", (unsigned)mem_tag); > > Move out into mainline PR Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965234821 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965236095 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965237891 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965238649 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965239439 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965240691 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965241348 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965242071 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965242582 From jsjolen at openjdk.org Fri Feb 21 10:39:04 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 21 Feb 2025 10:39:04 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: On Fri, 7 Feb 2025 10:31:36 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/opto/stringopts.cpp line 173: > >> 171: } >> 172: void add_control(Node* ctrl) { >> 173: assert(!_control.contains(ctrl), "only push once"); > > Remove the changes in this file. @afshin-zafari , here's one of the unhandled comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965257792 From azafari at openjdk.org Fri Feb 21 11:09:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 11:09:48 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v24] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: missed flag/tag -> type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/611a2d4f..7640108d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=22-23 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Fri Feb 21 11:09:50 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 11:09:50 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <6uq32Tm6oCiyWlXYvmquDd3wcCdruX1TGH6XWMrvgVM=.5add9458-0746-42c8-8b2b-4a0aaf8f5ee6@github.com> Message-ID: On Mon, 10 Feb 2025 14:03:30 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/nmt/memReporter.cpp line 192: > >> 190: } >> 191: >> 192: void MemSummaryReporter::report_summary_of_tag(MemTag mem_tag, > > Move out into mainline PR Fixed in commit "missed flag/tag -> type" (7640108). > src/hotspot/share/nmt/memReporter.cpp line 538: > >> 536: // thread stack is reported as part of thread category >> 537: if (mem_tag == mtThreadStack) continue; >> 538: diff_summary_of_tag(mem_tag, > > Move out into mainline PR Fixed in commit "missed flag/tag -> type" (7640108). > src/hotspot/share/nmt/memReporter.cpp line 608: > >> 606: >> 607: >> 608: void MemSummaryDiffReporter::diff_summary_of_tag(MemTag mem_tag, > > Move out into mainline PR Fixed in commit "missed flag/tag -> type" (7640108). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965299486 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965299728 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965299979 From coleenp at openjdk.org Fri Feb 21 13:23:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 21 Feb 2025 13:23:12 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> Message-ID: On Thu, 20 Feb 2025 23:02:09 GMT, Matias Saavedra Silva wrote: >> This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Check for exception without TRAPS I assume that the callers to next() check that the frame has an error, the only effect of not having a CHECK_VERIFY(return) is that _prev_frame is set and frame is returned but the error is checked by the caller and not the return value. So I don't think there was an observable bug. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23717#pullrequestreview-2633024475 From azafari at openjdk.org Fri Feb 21 15:08:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 15:08:48 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v25] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits: - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - missed flag/tag -> type - flag/type -> tag chages are removed. - removed vmtCommon.hpp - fixed merge problems - fix in shendoahCardTable - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - merge with the new lock mechanism for NMT - merge with master - one small fix for SSIZE_FORMAT - ... and 60 more: https://git.openjdk.org/jdk/compare/dfcd0df6...92f2bfdd ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=24 Stats: 2172 lines in 40 files changed: 762 ins; 1152 del; 258 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Fri Feb 21 15:29:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 15:29:45 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v26] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <1c6Byr-6ht6vBjJnMPon588Sq5QBH2dbdsYDDVXbwEA=.489a7e1b-185b-4e78-8ac3-03af005f800b@github.com> > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: undo stringopts.cpp changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/92f2bfdd..18ec1db5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=24-25 Stats: 143 lines in 1 file changed: 44 ins; 78 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Fri Feb 21 15:29:47 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 21 Feb 2025 15:29:47 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: On Fri, 21 Feb 2025 10:36:23 GMT, Johan Sj?len wrote: >> src/hotspot/share/opto/stringopts.cpp line 173: >> >>> 171: } >>> 172: void add_control(Node* ctrl) { >>> 173: assert(!_control.contains(ctrl), "only push once"); >> >> Remove the changes in this file. > > @afshin-zafari , here's one of the unhandled comments. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1965680516 From matsaave at openjdk.org Fri Feb 21 16:19:58 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 21 Feb 2025 16:19:58 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> Message-ID: On Thu, 20 Feb 2025 23:02:09 GMT, Matias Saavedra Silva wrote: >> This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Check for exception without TRAPS I think Coleen's analysis is correct, the error is caught by the callers and explains why this made it through testing. Test already exist that check for the exact error message reported by check_offset() and given that they passed, there was no gap in testing that I know of. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23717#issuecomment-2674977969 From matsaave at openjdk.org Fri Feb 21 16:19:59 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 21 Feb 2025 16:19:59 GMT Subject: RFR: 8350444: Check for verifer error in StackMapReader::check_offset() [v2] In-Reply-To: References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> <-k14I0uyXt4kSo3mLqEDZs5ztIfwEqXYDS_qvpvl_-4=.da9f09e5-c882-4732-bdb0-a594e0be5a02@github.com> Message-ID: On Fri, 21 Feb 2025 13:20:18 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for exception without TRAPS > > I assume that the callers to next() check that the frame has an error, the only effect of not having a CHECK_VERIFY(return) is that _prev_frame is set and frame is returned but the error is checked by the caller and not the return value. So I don't think there was an observable bug. Thanks for the discussion and reviews @coleenp and @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23717#issuecomment-2674979773 From matsaave at openjdk.org Fri Feb 21 16:19:59 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 21 Feb 2025 16:19:59 GMT Subject: Integrated: 8350444: Check for verifer error in StackMapReader::check_offset() In-Reply-To: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> References: <5ggBdBoidVuTj0j7F9WEB0CMUEg5ehy6jzeZt9AyHUU=.6c96d21e-e847-4aa6-99ca-696409952160@github.com> Message-ID: <0_kSSTYb6E299vew1El6fHSjBFL5KUI7rzdWc9gYfXE=.68d51384-cf36-40e9-819e-73caa1e811c7@github.com> On Thu, 20 Feb 2025 19:19:02 GMT, Matias Saavedra Silva wrote: > This small patch adds error propagation in the newly added `check_offset()` method. Verified with tier 1-5 tests This pull request has now been integrated. Changeset: 24b55736 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/24b557361a481d7f38f8016506573623b91bd8c8 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8350444: Check for verifer error in StackMapReader::check_offset() Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23717 From pchilanomate at openjdk.org Fri Feb 21 16:52:55 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 21 Feb 2025 16:52:55 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> Message-ID: On Fri, 21 Feb 2025 03:17:25 GMT, David Holmes wrote: >This positioning seems better than the previous one, but it still causes me concern as a get function should not really have a side-effect of blocking due to suspension, in my view. > Maybe we should?just add a side function to check this and call it from all `JvmtiExport::post_xxx` methods. >What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack. > In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors (JDK-8270085). This suspend check aims to address these cases where the thread was suspended sometime before while in a blocked state but it didn?t suspend when transitioning back to vm. So I don?t think there is an obvious better place to have it. Now of course we should check that we are not holding VM monitors in here, otherwise we are still in the same boat, but I see we already have a `!thread->owns_locks()` assert as part of `JvmtiJavaThreadEventTransition` due to `ThreadToNativeFromVM`. Some events use `JvmtiThreadEventTransition` though which does manual transitions and we don?t have a check there. We should move this `!thread->owns_locks()` check to `ThreadStateTransition` to cover all transitions to/from java and native but I?ll investigate that as a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1965868714 From aoqi at openjdk.org Fri Feb 21 17:40:04 2025 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 21 Feb 2025 17:40:04 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds Message-ID: minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' collect2: error: ld returned 1 exit status gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. ------------- Commit messages: - 8350499: Minimal build fails with slowdebug builds Changes: https://git.openjdk.org/jdk/pull/23729/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23729&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350499 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23729/head:pull/23729 PR: https://git.openjdk.org/jdk/pull/23729 From schernyshev at openjdk.org Fri Feb 21 19:56:16 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 21 Feb 2025 19:56:16 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v14] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: fix the tests to address the review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/8e8ab869..28122ff9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12-13 Stats: 27 lines in 2 files changed: 5 ins; 6 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Fri Feb 21 19:56:17 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 21 Feb 2025 19:56:17 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> added details in the log message > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60: > >> 58: >> 59: Common.prepareWhiteBox(); >> 60: DockerTestUtils.buildJdkContainerImage(imageName); > > This can be moved out of the condition. It's there in both cases. Done > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85: > >> 83: } else { >> 84: System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now."); >> 85: } > > Suggestion: > > throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider()); I made it with `jtreg.SkippedException` > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98: > >> 96: opts.addDockerOpts("--privileged") >> 97: .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) >> 98: .addDockerOpts("--memory", "1g"); > > Please extract this "larger" memory limit out of this function. The expectation is to have: > > > Container memory limit => X > Some lower limit in a moved path => Y > > Expect that the lower limit of Y is being detected. > > > For example: > > > testMemoryLimitSubgroupV1("1g", "100m", "104857600", false); done. > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118: > >> 116: opts.addDockerOpts("--privileged") >> 117: .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) >> 118: .addDockerOpts("--memory", "1g"); > > Same here with the `1g` container memory limit. Move it to a parameter. done. extracted the parameter. > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72: > >> 70: } else { >> 71: System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now."); >> 72: } > > Please `throw` here. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094564 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094301 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966093295 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092984 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092288 From schernyshev at openjdk.org Fri Feb 21 20:07:58 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 21 Feb 2025 20:07:58 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev wrote: >> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73: >> >>> 71: break; >>> 72: } >>> 73: cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of(""); >> >> Suggestion: >> >> cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of(""); > > Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take. How about this? int currentNameCount = cgp.getNameCount(); cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of(""); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966107031 From kbarrett at openjdk.org Sat Feb 22 03:52:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 22 Feb 2025 03:52:52 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 16:51:35 GMT, Ao Qi wrote: > minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): > > > Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': > /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' > collect2: error: ld returned 1 exit status > gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 > gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 > > ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) > > > It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. Changes requested by kbarrett (Reviewer). src/hotspot/share/classfile/verifier.cpp line 34: > 32: #include "classfile/symbolTable.hpp" > 33: #include "classfile/systemDictionary.hpp" > 34: #if INCLUDE_CDS Conditional includes go after the unconditional includes. See HotSpot Style Guide. ------------- PR Review: https://git.openjdk.org/jdk/pull/23729#pullrequestreview-2634678084 PR Review Comment: https://git.openjdk.org/jdk/pull/23729#discussion_r1966423807 From aoqi at openjdk.org Sat Feb 22 07:42:37 2025 From: aoqi at openjdk.org (Ao Qi) Date: Sat, 22 Feb 2025 07:42:37 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: > minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): > > > Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': > /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' > collect2: error: ld returned 1 exit status > gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 > gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 > > ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) > > > It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. Ao Qi has updated the pull request incrementally with one additional commit since the last revision: include list order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23729/files - new: https://git.openjdk.org/jdk/pull/23729/files/b5e8fce8..56004f64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23729&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23729&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23729/head:pull/23729 PR: https://git.openjdk.org/jdk/pull/23729 From aoqi at openjdk.org Sat Feb 22 07:44:52 2025 From: aoqi at openjdk.org (Ao Qi) Date: Sat, 22 Feb 2025 07:44:52 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: <0afnN0jl9-ps4DnZY7u477icQCS-l-06hYq8wqHqnzU=.44ea45c0-9ffe-47ee-9315-60ee97ebc5a9@github.com> On Sat, 22 Feb 2025 03:50:25 GMT, Kim Barrett wrote: >> Ao Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> include list order > > src/hotspot/share/classfile/verifier.cpp line 34: > >> 32: #include "classfile/symbolTable.hpp" >> 33: #include "classfile/systemDictionary.hpp" >> 34: #if INCLUDE_CDS > > Conditional includes go after the unconditional includes. See HotSpot Style Guide. Done. Thanks for the reminder. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23729#discussion_r1966465930 From kbarrett at openjdk.org Sun Feb 23 00:07:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 23 Feb 2025 00:07:54 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 07:42:37 GMT, Ao Qi wrote: >> minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): >> >> >> Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': >> /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' >> collect2: error: ld returned 1 exit status >> gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 >> gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) >> >> >> It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > include list order Marked as reviewed by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23729#pullrequestreview-2635357934 From azafari at openjdk.org Sun Feb 23 16:41:49 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 16:41:49 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v27] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: removed the size par from set_..._tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/18ec1db5..a89a013e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=25-26 Stats: 26 lines in 15 files changed: 0 ins; 1 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Sun Feb 23 16:48:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 16:48:02 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: <-NDyafiT1K5D4E2f2TD6vNiw7qhB27wb_LHmJB3PFHA=.cee7eb67-907c-42b8-a15b-f03b55d80be6@github.com> On Fri, 7 Feb 2025 10:32:20 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/nmt/vmatree.hpp line 215: > >> 213: tty->print_cr("Flag %s R: " INT64_FORMAT " C: " INT64_FORMAT, NMTUtil::tag_to_enum_name((MemTag)i), tag[i].reserve, tag[i].commit); >> 214: } >> 215: } > > This can be removed Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1966832096 From azafari at openjdk.org Sun Feb 23 16:59:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 16:59:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: On Fri, 7 Feb 2025 10:32:06 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/nmt/vmatree.hpp line 267: > >> 265: }); >> 266: tty->cr(); >> 267: } > > This can be removed, I'm rather sure(?) Only print_self is removed. The other two methods are used in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1966834727 From azafari at openjdk.org Sun Feb 23 17:05:01 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 17:05:01 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: On Fri, 7 Feb 2025 10:29:42 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > test/hotspot/gtest/nmt/test_nmt_treap.cpp line 238: > >> 236: EXPECT_LE(unexpected_count, REPEATS / 2) << "SSL Avg: " << sll_sum / REPEATS << " Treap Avg: " << treap_sum / REPEATS; >> 237: } >> 238: > > These can be removed. We shouldn't have performance benchmarks running on tier1, as they'll use unnecessary CPU and time. We're also removing the treap in favour of the RB-tree soon :-). Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1966835927 From azafari at openjdk.org Sun Feb 23 17:08:10 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 17:08:10 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20] In-Reply-To: <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <0I2mUN4F0QBOYVFxIX7UE1aYwJIEUNAOucOjCuxmS58=.091c86ae-399c-4786-b2e9-20593a4e4425@github.com> Message-ID: On Tue, 4 Feb 2025 13:44:15 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in shendoahCardTable > > test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 325: > >> 323: output.shouldMatch("\\[0x[0]*" + Long.toHexString(addr) + " - 0x[0]*" >> 324: + Long.toHexString(addr + size) >> 325: + "\\] committed " + sizeString); > > Not sure why this is changed. Removed the changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1966836547 From azafari at openjdk.org Sun Feb 23 17:17:44 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 17:17:44 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v28] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <5y2z_GCBI58DmRzIKuiKl7UGvXJP23dAPwNN-I6VEtA=.73aafeee-00ce-4f9d-803a-8259d49dda9d@github.com> > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: removed remaining of the unrelated changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/a89a013e..39f7482a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=26-27 Stats: 160 lines in 5 files changed: 4 ins; 147 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Sun Feb 23 17:17:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 17:17:45 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v21] In-Reply-To: <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1AtAN_70cbiU2-KRyPK90QnwMedZxIsZ22KgBwioyOc=.e415931f-34cd-4157-9cc6-08b95d89efa2@github.com> Message-ID: <0kzl8sjS_8Q8liswSu12f6cBG5p_gp8DrnYxwe3HXb4=.2c75546a-df64-43e6-bcfb-b8d5f6fcf3dc@github.com> On Fri, 7 Feb 2025 10:31:18 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed merge problems > > src/hotspot/share/opto/stringopts.hpp line 1: > >> 1: /* > > Remove the changes in this file. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1966838079 From azafari at openjdk.org Sun Feb 23 21:50:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 23 Feb 2025 21:50:42 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v29] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: once more. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/39f7482a..0a61fec3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=27-28 Stats: 6 lines in 3 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From dholmes at openjdk.org Mon Feb 24 00:56:07 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 00:56:07 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 07:42:37 GMT, Ao Qi wrote: >> minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): >> >> >> Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': >> /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' >> collect2: error: ld returned 1 exit status >> gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 >> gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) >> >> >> It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > include list order Looks good. Thanks for fixing this. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23729#pullrequestreview-2635857943 From aoqi at openjdk.org Mon Feb 24 01:15:04 2025 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 24 Feb 2025 01:15:04 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: <98-fVGIywpS3XQf8C1UgkJhWKIPgphFKxnVSqDU6a8k=.02975501-d9c8-4645-a209-f0a83e1d5396@github.com> On Sat, 22 Feb 2025 07:42:37 GMT, Ao Qi wrote: >> minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): >> >> >> Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': >> /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' >> collect2: error: ld returned 1 exit status >> gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 >> gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) >> >> >> It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > include list order Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23729#issuecomment-2677247927 From duke at openjdk.org Mon Feb 24 01:15:04 2025 From: duke at openjdk.org (duke) Date: Mon, 24 Feb 2025 01:15:04 GMT Subject: RFR: 8350499: Minimal build fails with slowdebug builds [v2] In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 07:42:37 GMT, Ao Qi wrote: >> minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): >> >> >> Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': >> /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' >> /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' >> collect2: error: ld returned 1 exit status >> gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 >> gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) >> >> >> It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > include list order @theaoqi Your change (at version 56004f641a8435bb700dcf3137cc40c9612b45a6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23729#issuecomment-2677248572 From dholmes at openjdk.org Mon Feb 24 02:09:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 02:09:06 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> Message-ID: On Fri, 21 Feb 2025 16:49:47 GMT, Patricio Chilano Mateo wrote: > In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors That sounds reasonable but we must also not post any events if we are suspended, which means we have to have checks that there are no locks held if are going to do this deferred suspension. But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state? I'm still missing the complete big picture here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1966979396 From dholmes at openjdk.org Mon Feb 24 02:16:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 02:16:00 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> Message-ID: <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> On Mon, 24 Feb 2025 02:06:08 GMT, David Holmes wrote: >>>This positioning seems better than the previous one, but it still causes me concern as a get function should not really have a side-effect of blocking due to suspension, in my view. >>> >> Maybe we should?just add a side function to check this and call it from all `JvmtiExport::post_xxx` methods. >> >>>What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack. >>> >> In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors (JDK-8270085). This suspend check aims to address these cases where the thread was suspended sometime before while in a blocked state but it didn?t suspend when transitioning back to vm. So I don?t think there is an obvious better place to have it. Now of course we should check that we are not holding VM monitors in here, otherwise we are still in the same boat, but I see we already have a `!thread->owns_locks()` assert as part of `JvmtiJavaThreadEventTransition` due to `ThreadToNativeFromVM`. Some events use `JvmtiThreadEventTransition` though which does manual transitions and we don?t have a check there. We should move this `!thread->owns_locks()` check to `ThreadStateTransition` to cover all transitions to/from java and native but I?ll investigate that as a separate PR. > >> In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors > > That sounds reasonable but we must also not post any events if we are suspended, which means we have to have checks that there are no locks held if are going to do this deferred suspension. But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state? I'm still missing the complete big picture here. Or should we simply be passing `allow_suspend=true` into more `ThreadBlockInVM` transitions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1966980872 From dholmes at openjdk.org Mon Feb 24 02:16:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 02:16:00 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> Message-ID: On Mon, 24 Feb 2025 02:11:11 GMT, David Holmes wrote: >>> In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors >> >> That sounds reasonable but we must also not post any events if we are suspended, which means we have to have checks that there are no locks held if are going to do this deferred suspension. But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state? I'm still missing the complete big picture here. > > Or should we simply be passing `allow_suspend=true` into more `ThreadBlockInVM` transitions? And again what is the call stack for this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1966981552 From dholmes at openjdk.org Mon Feb 24 02:44:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 02:44:52 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Fri, 24 Jan 2025 06:36:34 GMT, SendaoYan wrote: > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. On the other hand, I think it's better check macro `LOG_PLEASE` has been defined or not before define it. > Change has been verified locally, test-fix only, risk is low. Lots of gtests attempt to use SIZE_FORMAT. Isn't this just a missing include of globalDefinitions ?? ------------- PR Review: https://git.openjdk.org/jdk/pull/23290#pullrequestreview-2635931972 From syan at openjdk.org Mon Feb 24 02:58:54 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 02:58:54 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 02:42:23 GMT, David Holmes wrote: > Lots of gtests attempt to use SIZE_FORMAT. Isn't this just a missing include of globalDefinitions ?? Most of the use of `SIZE_FORMAT` has been removed by https://github.com/openjdk/jdk/pull/23180 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2677334853 From dholmes at openjdk.org Mon Feb 24 03:10:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 03:10:54 GMT Subject: RFR: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 09:01:51 GMT, Thomas Stuefe wrote: >> See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max >> >> Testing: >> - tiers 1-3 sanity testing >> >> Thanks > > A release note may be useful here. There are a lot of blog articles out there about this topic. I guess this is not a backward compatibility problem, since values lower than -1 have never been accepted by the JVM, right? Thanks for the reviews @tstuefe and @shipilev . The -1 quirk is a problem for another day - though hard to imagine it is a practical limitation. Testing is too hard in general due to the CAP_SYS_NICE problem and the lack of a good way to validate that the change in niceness actually took place. I'm reluctant to write a Release Note for this simple relaxation of a constraint, as I do not wnat to shine a spotlight (more than already done) on this very murky corner of the runtime. Thread priorities are just a total mess and these flags are very kuch "caveat emptor". ------------- PR Comment: https://git.openjdk.org/jdk/pull/23722#issuecomment-2677345859 From dholmes at openjdk.org Mon Feb 24 03:18:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 03:18:06 GMT Subject: Integrated: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range In-Reply-To: References: Message-ID: <3OcA_CiXDmkBbOkO4RL4r_ZHqix0gXljV5hQLmfOGL8=.0936cd69-099f-401b-8ce5-2d22f9e71198@github.com> On Fri, 21 Feb 2025 05:25:44 GMT, David Holmes wrote: > See JBS for background details, but basically -1 -> 127 is inappropriate and the priority range should be the full int_min - int_max > > Testing: > - tiers 1-3 sanity testing > > Thanks This pull request has now been integrated. Changeset: 0795d11b Author: David Holmes URL: https://git.openjdk.org/jdk/commit/0795d11bfc0c6640ed7e9f05a17eb2a733d88bc0 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range Reviewed-by: stuefe, shade ------------- PR: https://git.openjdk.org/jdk/pull/23722 From aoqi at openjdk.org Mon Feb 24 03:21:14 2025 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 24 Feb 2025 03:21:14 GMT Subject: Integrated: 8350499: Minimal build fails with slowdebug builds In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 16:51:35 GMT, Ao Qi wrote: > minimal build fails with slowdebug builds after [8311208](https://github.com/openjdk/jdk/commit/498a58244d79) (permissions required): > > > Building target 'images' in configuration 'linux-x86_64-minimal-slowdebug' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/hotspot/variant-minimal/libjvm/objs/verifier.o: in function `Verifier::verify(InstanceKlass*, bool, JavaThread*)': > /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:239: undefined reference to `SystemDictionaryShared::warn_excluded(InstanceKlass*, char const*)' > /usr/bin/ld: /home/aoqi/work/theaoqi/jdk/src/hotspot/share/classfile/verifier.cpp:240: undefined reference to `SystemDictionaryShared::set_excluded(InstanceKlass*)' > collect2: error: ld returned 1 exit status > gmake[3]: *** [lib/CompileJvm.gmk:174: /home/aoqi/work/theaoqi/jdk/build/linux-x86_64-minimal-slowdebug/support/modules_libs/java.base/minimal/libjvm.so] Error 1 > gmake[2]: *** [make/Main.gmk:236: hotspot-minimal-libs] Error 2 > > ERROR: Build failed for target 'images' in configuration 'linux-x86_64-minimal-slowdebug' (exit code 2) > > > It may be because the systemDictionaryShared.cpp file is [excluded](https://github.com/openjdk/jdk/blob/bd8ad309b59bceb3073a8d6411cca74e73508885/make/hotspot/lib/JvmFeatures.gmk#L130) when using slowdebug and minimal builds. This pull request has now been integrated. Changeset: 302bed05 Author: Ao Qi Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/302bed055c3b4881f97c584d5953273b9dbc2969 Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod 8350499: Minimal build fails with slowdebug builds Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23729 From dholmes at openjdk.org Mon Feb 24 03:25:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Feb 2025 03:25:52 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Fri, 24 Jan 2025 06:36:34 GMT, SendaoYan wrote: > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. On the other hand, I think it's better check macro `LOG_PLEASE` has been defined or not before define it. > Change has been verified locally, test-fix only, risk is low. Okay. I am still seeing a number of other uses in the gtests so I guess @coleenp missed a few others. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23290#pullrequestreview-2635954986 From iklam at openjdk.org Mon Feb 24 04:32:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 24 Feb 2025 04:32:44 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC Message-ID: During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. ------------- Commit messages: - 8349888: AOTMode=create crashes with EpsilonGC Changes: https://git.openjdk.org/jdk/pull/23741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349888 Stats: 110 lines in 2 files changed: 110 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23741/head:pull/23741 PR: https://git.openjdk.org/jdk/pull/23741 From jsjolen at openjdk.org Mon Feb 24 08:30:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 24 Feb 2025 08:30:11 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v29] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Sun, 23 Feb 2025 21:50:42 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > once more. Hi, You should take out these bug fixes and add them as separate PRs instead. They need separate reviewing so that we can discuss them outside of the context of this port. src/hotspot/share/nmt/memoryFileTracker.cpp line 183: > 181: // Only account the committed memory. > 182: snap->commit_memory(current->committed()); > 183: });} Style: Restore to what it was before. src/hotspot/share/nmt/virtualMemoryTracker.hpp line 404: > 402: friend class VirtualMemoryTrackerTest; > 403: friend class CommittedVirtualMemoryTest; > 404: These two classes doesn't exist anymore. src/hotspot/share/nmt/vmatree.cpp line 80: > 78: MemTag tag = leqA_n->val().out.mem_tag(); > 79: stA.out.set_tag(tag); > 80: LEQ_A.state.out.set_tag(tag); This also seems like a bug fix that must be separated out into a separate PR along with test cases. src/hotspot/share/nmt/vmatree.cpp line 211: > 209: // Finally, we can register the new region [A, B)'s summary data. > 210: MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag; > 211: SingleDiff& rescom = diff.tag[NMTUtil::tag_to_index(tag_to_change)]; This seems to be a bug fix to 8335091. You should open a separate mainline PR with this fix and add a testcase for it. Your fix should be integrated before this PR is. test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 1: > 1: /* Why are these tests removed? Can they be adapted to the new implementation? ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2636234435 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1967189701 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1967186209 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1967184884 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1967183983 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1967173959 From shade at openjdk.org Mon Feb 24 09:20:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Feb 2025 09:20:09 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 04:26:09 GMT, Ioi Lam wrote: > During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. > > When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. > > This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. Marked as reviewed by shade (Reviewer). Marked as reviewed by shade (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java line 67: > 65: "-XX:+AOTClassLinking", > 66: "-XX:+UnlockExperimentalVMOptions", > 67: "-XX:+UseEpsilonGC", I propose setting up some static heap size for this test to be extra-reliable. Since Epsilon does not collect, the amount of heap we get is the amount of allocations the application can possibly do. So if we ergonomically set too small heap, this test might fail accidentally. ------------- PR Review: https://git.openjdk.org/jdk/pull/23741#pullrequestreview-2636387281 PR Review: https://git.openjdk.org/jdk/pull/23741#pullrequestreview-2636392386 PR Review Comment: https://git.openjdk.org/jdk/pull/23741#discussion_r1967258122 From kbarrett at openjdk.org Mon Feb 24 09:46:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Feb 2025 09:46:55 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 02:56:04 GMT, SendaoYan wrote: > Lots of gtests attempt to use SIZE_FORMAT. Isn't this just a missing include of globalDefinitions ?? There are no longer definitions of `SIZE_FORMAT` and `SSIZE_FORMAT` in globalDefinitions.hpp. Presumably the uses being looked at here (which appear to be all of the remaining residue) were overlooked because they were under conditional compilation that doesn't didn't get tested. Running `egrep -r "\bS?SIZE_FORMAT\b" .` in src/hotspot gets nothing. Running it in test/hotspot/gtest finds the ones being changed by this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2677886782 From mbaesken at openjdk.org Mon Feb 24 10:08:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Feb 2025 10:08:07 GMT Subject: RFR: 8350497: os::create_thread unify init thread attributes part across UNIX platforms Message-ID: In os::create_thread the 'init thread attributes' part of the method should be unified across UNIX platforms, e.g. regarding return code checking. ------------- Commit messages: - JDK-8350497 Changes: https://git.openjdk.org/jdk/pull/23746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350497 Stats: 12 lines in 2 files changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23746/head:pull/23746 PR: https://git.openjdk.org/jdk/pull/23746 From kbarrett at openjdk.org Mon Feb 24 10:33:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Feb 2025 10:33:52 GMT Subject: RFR: 8348536: Build fails with extra cflags -DLOG_PLEASE In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Fri, 24 Jan 2025 06:36:34 GMT, SendaoYan wrote: > make fails with extra flags '-DLOG_PLEASE' The way that macro is being used, I don't think it's intended to be globally enabled like that. It's definition is typically commented or uncommented to provide some additional logging for some tests of interest. I'm wondering if the places where it is currently being defined are debugging leftovers that shouldn't have been committed. For example, I think the LOG_PLEASE and LOG_HERE in runtime/test_os_reserve_between.cpp should either comment out the LOG_PLEASE definition or just use ordinary logging. Maybe @tstuefe has an opinion? Maybe the changes related to LOG_PLEASE definitions ought to be removed and examined as a separate issue? It's still good that the lingering SIZE_FORMATs were uncovered and are being fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2678001782 From azafari at openjdk.org Mon Feb 24 11:32:55 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 24 Feb 2025 11:32:55 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v2] In-Reply-To: References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> <2T8QiNDGZjC1qqGFoMaAsIBehDwrdLhaB3ENICIHy1g=.430718a8-bff2-419c-88f4-b737428ca385@github.com> Message-ID: On Thu, 9 Jan 2025 06:25:35 GMT, Axel Boldt-Christmas wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed extra blank lines > > I think the best way to fix this specific issue is the way I proposed in the JBS entry. > > - _accumulator |= ((fingerprint_t)type << _shift_count); > - _shift_count += fp_parameter_feature_size; > + if (_param_size < fp_max_size_of_parameters) { > + _accumulator |= ((fingerprint_t)type << _shift_count); > +. _shift_count += fp_parameter_feature_size; > + } > > > My reasoning for using the `_param_size < fp_max_size_of_parameters` condition instead of some `_shift_count < 64` is that the later makes it more confusing IMO. The current implementation of fingerprinting uses the `_param_size < fp_max_size_of_parameters` condition to determine if an overflow fingerprint should be used. (The only way we would currently install a accumulated fingerprint that when this condition is false is if there is a mismatch between `_method->size_of_parameters()` and `_param_size`. But I assume that `!_method || _method->size_of_parameters() == _param_size` is a post condition here). > > Generally UB in the implementation is because we have not through through the design enough. I feel it is rarely the best solution to create a `if (!ub) { do_the_thing(); }` rather than look at the algorithm and find what are we actually trying to do and then adapt the implementation in terms of the algorithm. Which in this case is if `_param_size < fp_max_size_of_parameters` we use an overflow fingerprint so stop accumulating a value which will never be read. > > > I then think we should create a RFE for investigating if there are any `_param_size < fp_max_size_of_parameters` implies overflow fingerprint dependencies or assumptions anywhere else. And with that information in mind, change the algorithm such that the condition for using a overflow fingerprint is not tied to the size of the parameters, but the number of parameters. So we can fingerprint any method with 14 or less parameters, regardless of their types. Dear @xmas92 and @kimbarrett and @dean-long , please check if new implementation is acceptable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22807#issuecomment-2678144650 From jsjolen at openjdk.org Mon Feb 24 12:32:19 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 24 Feb 2025 12:32:19 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v17] In-Reply-To: References: Message-ID: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Copy paste issue - Merge remote-tracking branch 'openjdk/master' into ul-stalling-mode-2 - And also check for nullptr - Inverted condition in assert... - Detached threads use UL - Support recursive logging on the producer thread - Of course, the buffer size is divided by 2 - Slightly increase the buffer size as GHA complained - NOT_DEBUG is not the same as PRODUCT_ONLY I assume - Add stress test for very small buffer - ... and 9 more: https://git.openjdk.org/jdk/compare/dfcd0df6...d9d1b512 ------------- Changes: https://git.openjdk.org/jdk/pull/22770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=16 Stats: 237 lines in 8 files changed: 183 ins; 3 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From azafari at openjdk.org Mon Feb 24 12:45:51 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 24 Feb 2025 12:45:51 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v30] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: test file got back, fixed coding style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/0a61fec3..5f4bc6dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=28-29 Stats: 594 lines in 2 files changed: 593 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From jsjolen at openjdk.org Mon Feb 24 13:07:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 24 Feb 2025 13:07:11 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v18] In-Reply-To: References: Message-ID: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Common Locker interface ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22770/files - new: https://git.openjdk.org/jdk/pull/22770/files/d9d1b512..1586df66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=16-17 Stats: 35 lines in 2 files changed: 5 ins; 12 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From jsjolen at openjdk.org Mon Feb 24 13:27:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 24 Feb 2025 13:27:10 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: Message-ID: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Self-review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22770/files - new: https://git.openjdk.org/jdk/pull/22770/files/1586df66..ce39257c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=17-18 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From jsjolen at openjdk.org Mon Feb 24 13:30:54 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 24 Feb 2025 13:30:54 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <02Ftapn4gKOR2sRD2pxBdWJuRstRhrbPRr9x4OLefP8=.f8583e86-c785-4c19-8729-d79bcaf82372@github.com> Message-ID: <_EvQNkpaaMFnHG6_PQOPKK-OJ2mhuTdEJhKSmp6bgUA=.a8354661-aa9c-48f5-8645-a90ab826af41@github.com> On Wed, 18 Dec 2024 10:45:48 GMT, David Holmes wrote: >>> > I was considering whether we should vm_exit_out_of_memory if that occurs. >>> >>> I prefer not to have secondary functionality, like logging, abort the VM. If malloc fails no doubt we will soon have an issue in primary functionality, but we will deal with that then. >> >> Sounds like you think the preferred way to go is to just ignore the stalled message on OOM and continue on until something else in the system fails? Fine by me. >> >>> > Is there something in particular you had in mind? >>> >>> Just running some small app with e.g. -Xlog:all=trace and checking that the different modes seem to cope okay with what they encounter. >> >> I believe that that is what I did with my Spring Boot experiment :-). > >> I believe that that is what I did with my Spring Boot experiment :-). > > Right. Sorry I see my comment could have been misconstrued. I wasn't referring about additional testing for this PR, but adding additional UL-async-stall testing in our regular tier testing somewhere. @dholmes-ora , @xmas92 , Hi. I've merged with mainline and run the tests locally and did some self-review. I applied Axel's suggestion to use `_data_available` as one signal for both states. Does this look good to you? Assuming GHA (and any other tests) passes, of course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22770#issuecomment-2678418484 From mbaesken at openjdk.org Mon Feb 24 13:40:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Feb 2025 13:40:24 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 Message-ID: On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. ------------- Commit messages: - JDK-8350103 Changes: https://git.openjdk.org/jdk/pull/23749/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23749&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350103 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23749/head:pull/23749 PR: https://git.openjdk.org/jdk/pull/23749 From mbaesken at openjdk.org Mon Feb 24 13:52:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Feb 2025 13:52:57 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 13:35:14 GMT, Matthias Baesken wrote: > On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. contributor add sgehwolf ------------- PR Comment: https://git.openjdk.org/jdk/pull/23749#issuecomment-2678472556 From sgehwolf at openjdk.org Mon Feb 24 13:56:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 24 Feb 2025 13:56:51 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: <7yax8vZT50r1jJwAEEs16zbozlkZdvoDRRhC7vXvafk=.4d332eb2-7456-4768-9dab-5be6c18ca833@github.com> On Mon, 24 Feb 2025 13:35:14 GMT, Matthias Baesken wrote: > On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. Test fix only. Runs fine here. Looks good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23749#pullrequestreview-2637170375 From asteiner at openjdk.org Mon Feb 24 14:37:53 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Mon, 24 Feb 2025 14:37:53 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 13:35:14 GMT, Matthias Baesken wrote: > On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. LGTM ------------- Marked as reviewed by asteiner (Author). PR Review: https://git.openjdk.org/jdk/pull/23749#pullrequestreview-2637315770 From sgehwolf at openjdk.org Mon Feb 24 15:27:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 24 Feb 2025 15:27:55 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 13:49:57 GMT, Matthias Baesken wrote: >> On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. > > contributor add sgehwolf @MBaesken If you want to add me, use `/contributor add sgehwolf` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23749#issuecomment-2678799259 From syan at openjdk.org Mon Feb 24 15:32:16 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 15:32:16 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v2] In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. On the other hand, I think it's better check macro `LOG_PLEASE` has been defined or not before define it. > Change has been verified locally, test-fix only, risk is low. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove #ifndef LOG_PLEASE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23290/files - new: https://git.openjdk.org/jdk/pull/23290/files/af297c41..4d7440ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23290/head:pull/23290 PR: https://git.openjdk.org/jdk/pull/23290 From syan at openjdk.org Mon Feb 24 15:46:53 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 15:46:53 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 10:30:07 GMT, Kim Barrett wrote: > Maybe the changes related to LOG_PLEASE definitions ought to be removed and examined as a separate issue? It's still good that the lingering SIZE_FORMATs were uncovered and are being fixed. The LOG_PLEASE definition has been removed by this PR, and I create a new issue [JDK-8350584](https://bugs.openjdk.org/browse/JDK-8350584) to record this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2678868314 From coleenp at openjdk.org Mon Feb 24 15:52:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 24 Feb 2025 15:52:03 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v2] In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 15:32:16 GMT, SendaoYan wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove #ifndef LOG_PLEASE I didn't see these with the final grep and now I see they're conditionally compiled out. There are a couple others here. Can you get these too? gtest/nmt/test_nmt_totals.cpp: LOG("Deviation: n=" SSIZE_FORMAT ", s=" SSIZE_FORMAT ", ovrh=" SSIZE_FORMAT, \ gtest/runtime/test_virtualMemoryTracker.cpp: LOG("In reserved region " PTR_FORMAT ", size " SIZE_FORMAT_HEX ":", p2i(rmr->base()), rmr->size()); gtest/runtime/test_virtualMemoryTracker.cpp: LOG(" committed region: " PTR_FORMAT ", size " SIZE_FORMAT_HEX, p2i(region->base()), region->size()); test/hotspot/gtest/metaspace/test_blocktree.cpp line 146: > 144: } > 145: > 146: LOG("%zu" ": %zu.", request_size, real_size); This can be changed to: "%zu: %zu.", removing the extra " ". ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23290#pullrequestreview-2637595410 PR Review Comment: https://git.openjdk.org/jdk/pull/23290#discussion_r1967917138 From syan at openjdk.org Mon Feb 24 15:57:34 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 15:57:34 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v3] In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: <3_oerCkMiT3_7VXBmOoyfvhlpmK9pbapdgKmg2DjUmA=.4d7f1964-6877-43e6-b3b5-d6876506058f@github.com> > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. > > Change has been verified locally, test-fix only, risk is low. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove the extra whilespace in test/hotspot/gtest/metaspace/test_blocktree.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23290/files - new: https://git.openjdk.org/jdk/pull/23290/files/4d7440ce..2fc808b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23290/head:pull/23290 PR: https://git.openjdk.org/jdk/pull/23290 From syan at openjdk.org Mon Feb 24 15:57:34 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 15:57:34 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v2] In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: <5L8KKZOcQyz-WO-W0l-nl6KiSamAUakz9sBQCtqPOfE=.0905d5c7-1354-4df9-bb66-78134b5ca80a@github.com> On Mon, 24 Feb 2025 15:43:09 GMT, Coleen Phillimore wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove #ifndef LOG_PLEASE > > test/hotspot/gtest/metaspace/test_blocktree.cpp line 146: > >> 144: } >> 145: >> 146: LOG("%zu" ": %zu.", request_size, real_size); > > This can be changed to: > "%zu: %zu.", removing the extra " ". The extra whitespace has been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23290#discussion_r1967938532 From syan at openjdk.org Mon Feb 24 16:11:01 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 24 Feb 2025 16:11:01 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v2] In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 15:49:07 GMT, Coleen Phillimore wrote: > I didn't see these with the final grep and now I see they're conditionally compiled out. There are a couple others here. Can you get these too? Do you mean I should replace `SSIZE_FORMAT` as `%zd` in this PR? What's string should I use to replace to `PTR_FORMAT` and `PTR_FORMAT`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2678949616 From coleenp at openjdk.org Mon Feb 24 16:43:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 24 Feb 2025 16:43:52 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v3] In-Reply-To: <3_oerCkMiT3_7VXBmOoyfvhlpmK9pbapdgKmg2DjUmA=.4d7f1964-6877-43e6-b3b5-d6876506058f@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <3_oerCkMiT3_7VXBmOoyfvhlpmK9pbapdgKmg2DjUmA=.4d7f1964-6877-43e6-b3b5-d6876506058f@github.com> Message-ID: On Mon, 24 Feb 2025 15:57:34 GMT, SendaoYan wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove the extra whilespace in test/hotspot/gtest/metaspace/test_blocktree.cpp Yes, replace SSIZE_FORMAT with %zd. I see that the SIZE_FORMAT_HEX was the one I kept, so that should not be replaced. Sorry for the confusion. PTR_FORMAT should not be replaced. Edit. I'm the one suffering from confusion. I don't see any SIZE_FORMAT_HEX, just SIZE_FORMAT_X_0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2679026796 From iklam at openjdk.org Mon Feb 24 16:50:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 24 Feb 2025 16:50:13 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC [v2] In-Reply-To: References: Message-ID: > During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. > > When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. > > This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @shipilev comments - explicitly set memory size to avoid premature failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23741/files - new: https://git.openjdk.org/jdk/pull/23741/files/19f627f9..67987dbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23741&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23741/head:pull/23741 PR: https://git.openjdk.org/jdk/pull/23741 From shade at openjdk.org Mon Feb 24 17:06:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Feb 2025 17:06:56 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 16:50:13 GMT, Ioi Lam wrote: >> During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. >> >> When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. >> >> This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @shipilev comments - explicitly set memory size to avoid premature failure Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23741#pullrequestreview-2637851268 From never at openjdk.org Mon Feb 24 17:31:06 2025 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 24 Feb 2025 17:31:06 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Stricter assertion on ppc64 src/hotspot/share/runtime/deoptimization.cpp line 650: > 648: // would need to get the size from the resolved method entry. Another exception would > 649: // be an invokedynamic with an adapter that is really a MethodHandle linker. > 650: caller_was_method_handle = true; This flag also controls the code at 711 that controls the computation of caller_adjustment. Is the new answer also correct for that code? This code might be a bit clearer if the computations of caller_was_method_handle, caller_adjustment and the new caller_actual_parameters were all closer together, though that might complicate a backport so maybe it should be deferred to some later cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1968100587 From pchilanomate at openjdk.org Mon Feb 24 19:01:04 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 24 Feb 2025 19:01:04 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> Message-ID: On Mon, 24 Feb 2025 02:13:29 GMT, David Holmes wrote: >> Or should we simply be passing `allow_suspend=true` into more `ThreadBlockInVM` transitions? > > And again what is the call stack for this? > But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state? > Only for the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization(). In these cases we know there are no VM monitors held though. > Or should we simply be passing allow_suspend=true into more ThreadBlockInVM transitions? > I think this would be harder to get right. First because these ThreadBlockInVM could be anywhere along the path where we post an event. But also because at those points the thread could be holding VM monitors so we cannot suspend. Here where we post the event we are already checking no VM monitors are held. > And again what is the call stack for this? > For single step event the call is coming from InterpreterRuntime::at_safepoint(): Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1212523] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0xd3 (jvmtiExport.cpp:425) V [libjvm.so+0x121de66] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x66 (jvmtiExport.cpp:1332) V [libjvm.so+0xed8398] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1165) But note this same issue can happen with other events, the test is just checking for single step. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1968244740 From gziemski at openjdk.org Mon Feb 24 21:20:12 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 24 Feb 2025 21:20:12 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v30] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <2fTUz_oDUK6cNc-DY5AATuXDaqjQZ6XUa-t1VF_UzaI=.6fb21f2f-eccc-4950-9a31-98f467be48e6@github.com> On Mon, 24 Feb 2025 12:45:51 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > test file got back, fixed coding style My feedback so far, more tomorrow. Is the description out of date? It says > Both old and new versions exist in the code and can be selected via MemTracker::set_version() but that's not true right? src/hotspot/share/nmt/virtualMemoryTracker.hpp line 381: > 379: bool remove_uncommitted_region (address base_addr, size_t size); > 380: bool remove_released_region (address base_addr, size_t size); > 381: bool remove_released_region (ReservedMemoryRegion* rgn); Why are they returning `bool` ? I don't see the return value being used anywhere? ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2637959728 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2679666750 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1968340892 From gziemski at openjdk.org Mon Feb 24 21:20:13 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 24 Feb 2025 21:20:13 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v30] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 14 Oct 2024 08:52:50 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/memReporter.cpp line 442: >> >>> 440: if (all_committed) { >>> 441: bool reserved_and_committed = false; >>> 442: VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn, >> >> Change the signature of `visit_committed_regions` to taking `(position start, size size)` instead of the `ReservedMemoryRegion`. > > Done. 2 questions: 1st, I must be misunderstanding something here. Johan asked to change the API from: `visit_committed_regions(ReservedMemoryRegion& committed_rgn)` to `visit_committed_regions(position start, size size)` but I still see the old way. 2nd, why are we asking for this change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1968128713 From schernyshev at openjdk.org Mon Feb 24 21:20:49 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 24 Feb 2025 21:20:49 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v15] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: - added high level comment to CgroupV1Controller::set_subsystem_path - fix minor issue calling .getNameCount() twice ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/28122ff9..3568c138 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13-14 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Mon Feb 24 21:20:50 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 24 Feb 2025 21:20:50 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 20:05:07 GMT, Sergey Chernyshev wrote: >> Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take. > > How about this? > > int currentNameCount = cgp.getNameCount(); > cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of(""); I tested the builds with the above change. It seems to be doing the thing. Please see the updated PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1968429793 From schernyshev at openjdk.org Mon Feb 24 21:20:49 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 24 Feb 2025 21:20:49 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote: > `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening. > Done, added ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679664923 From dlong at openjdk.org Mon Feb 24 22:36:56 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 24 Feb 2025 22:36:56 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: <6I2PyXMG5jSH3dmfnmUvUOrtZ9ntwjkZEw2GqFFCsNg=.de6024a5-5c60-4842-afe5-3d878b65bb6c@github.com> On Mon, 24 Feb 2025 17:28:03 GMT, Tom Rodriguez wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> Stricter assertion on ppc64 > > src/hotspot/share/runtime/deoptimization.cpp line 650: > >> 648: // would need to get the size from the resolved method entry. Another exception would >> 649: // be an invokedynamic with an adapter that is really a MethodHandle linker. >> 650: caller_was_method_handle = true; > > This flag also controls the code at 711 that controls the computation of caller_adjustment. Is the new answer also correct for that code? > > This code might be a bit clearer if the computations of caller_was_method_handle, caller_adjustment and the new caller_actual_parameters were all closer together, though that might complicate a backport so maybe it should be deferred to some later cleanup. Yes, I have further cleanup that I want to do later, but I want to minimize changes in this one to simplify backports. Good catch about line 711. I left it in on purpose, again to simplify backports, but it could be safely removed. All it does here is over-estimate the adjustment, which is harmless. In future cleanups, I hope to make the adjustment exact rather than a possibly over-estimated increment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1968511371 From schernyshev at openjdk.org Mon Feb 24 23:35:58 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 24 Feb 2025 23:35:58 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote: > The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`. ========== NEW TEST CASE: Cgroup V1 subgroup memory limit: 100m [COMMAND] docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369 [ELAPSED: 5385 ms] [STDERR] [STDOUT] [0.002s][trace][os,container] OSContainer::init: Initializing Container Support [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. With additional logging added before line 77, this could be looking like [STDOUT] [0.002s][trace][os,container] OSContainer::init: Initializing Container Support [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. Before the fix, the current path adjustment scheme would produce the following order: /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370 /sys/fs/cgroup/memory/docker /sys/fs/cgroup/memory Only the last path is valid in the container, others are non-existent. The result will be 200m, while the correct is 100m. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679936058 From kvn at openjdk.org Mon Feb 24 23:50:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 24 Feb 2025 23:50:54 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 16:50:13 GMT, Ioi Lam wrote: >> During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. >> >> When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. >> >> This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @shipilev comments - explicitly set memory size to avoid premature failure Marked as reviewed by kvn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23741#pullrequestreview-2638726173 From xpeng at openjdk.org Mon Feb 24 23:52:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 24 Feb 2025 23:52:04 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging Message-ID: Hi there, Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). Current safepoint log is like: [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". With the new "Leaving safepoint" counter, the log will be like: [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns ### Tests - [x] Verified the new safepoint log - [x] Tier 2 ------------- Commit messages: - 8350313: Include timings for leaving safepoint in safepoint logging Changes: https://git.openjdk.org/jdk/pull/23756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350313 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23756/head:pull/23756 PR: https://git.openjdk.org/jdk/pull/23756 From dlong at openjdk.org Mon Feb 24 23:53:55 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 24 Feb 2025 23:53:55 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v4] In-Reply-To: References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> Message-ID: On Thu, 13 Feb 2025 09:31:08 GMT, Afshin Zafari wrote: >> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. >> Some compilers do not mask the shift value to the base size and UBSAN catches the case. >> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > count member is removed. Axel's suggestion is implemented. Looks good. src/hotspot/share/runtime/signature.cpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved. I see no changes in this file. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22807#pullrequestreview-2638730250 PR Review Comment: https://git.openjdk.org/jdk/pull/22807#discussion_r1968586238 From syan at openjdk.org Tue Feb 25 00:05:07 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 00:05:07 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. > > Change has been verified locally, test-fix only, risk is low. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Replace SSIZE_FORMAT as %zd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23290/files - new: https://git.openjdk.org/jdk/pull/23290/files/2fc808b2..806b5751 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23290&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23290/head:pull/23290 PR: https://git.openjdk.org/jdk/pull/23290 From syan at openjdk.org Tue Feb 25 00:05:07 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 00:05:07 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v3] In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <3_oerCkMiT3_7VXBmOoyfvhlpmK9pbapdgKmg2DjUmA=.4d7f1964-6877-43e6-b3b5-d6876506058f@github.com> Message-ID: On Mon, 24 Feb 2025 16:36:34 GMT, Coleen Phillimore wrote: > Yes, replace SSIZE_FORMAT with %zd. `SSIZE_FORMAT` has been replace as `%zd`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2679980907 From ccheung at openjdk.org Tue Feb 25 00:57:26 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 00:57:26 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled Message-ID: A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. Testing: - run gtest with -Xshare:on on linux-x64 - tier1 ------------- Commit messages: - 8348028: Unable to run gtests with CDS enabled Changes: https://git.openjdk.org/jdk/pull/23758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348028 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23758/head:pull/23758 PR: https://git.openjdk.org/jdk/pull/23758 From never at openjdk.org Tue Feb 25 02:03:57 2025 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 25 Feb 2025 02:03:57 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: <6I2PyXMG5jSH3dmfnmUvUOrtZ9ntwjkZEw2GqFFCsNg=.de6024a5-5c60-4842-afe5-3d878b65bb6c@github.com> References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> <6I2PyXMG5jSH3dmfnmUvUOrtZ9ntwjkZEw2GqFFCsNg=.de6024a5-5c60-4842-afe5-3d878b65bb6c@github.com> Message-ID: On Mon, 24 Feb 2025 22:34:01 GMT, Dean Long wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 650: >> >>> 648: // would need to get the size from the resolved method entry. Another exception would >>> 649: // be an invokedynamic with an adapter that is really a MethodHandle linker. >>> 650: caller_was_method_handle = true; >> >> This flag also controls the code at 711 that controls the computation of caller_adjustment. Is the new answer also correct for that code? >> >> This code might be a bit clearer if the computations of caller_was_method_handle, caller_adjustment and the new caller_actual_parameters were all closer together, though that might complicate a backport so maybe it should be deferred to some later cleanup. > > Yes, I have further cleanup that I want to do later, but I want to minimize changes in this one to simplify backports. > Good catch about line 711. I left it in on purpose, again to simplify backports, but it could be safely removed. All it does here is over-estimate the adjustment, which is harmless. In future cleanups, I hope to make the adjustment exact rather than a possibly over-estimated increment. Sounds good. I kind of assumed it was a benign oversizing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1968699203 From never at openjdk.org Tue Feb 25 02:11:54 2025 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 25 Feb 2025 02:11:54 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Stricter assertion on ppc64 The new asserts look good and the logic seems right. ------------- Marked as reviewed by never (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2638933792 From dholmes at openjdk.org Tue Feb 25 02:38:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 02:38:04 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds Message-ID: Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: Before: 532377 ns After: 361178 ns which is 32% improvement. Testing: - tiers 1-3 sanity Thanks ------------- Commit messages: - 8350616: Skip ValidateHazardPtrsClosure in non-debug builds Changes: https://git.openjdk.org/jdk/pull/23762/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23762&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350616 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23762/head:pull/23762 PR: https://git.openjdk.org/jdk/pull/23762 From syan at openjdk.org Tue Feb 25 03:37:16 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 03:37:16 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE Message-ID: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Hi all, Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically commented or uncommented to provide some additional logging for some tests of interest. This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8350584: Check the usage of LOG_PLEASE Changes: https://git.openjdk.org/jdk/pull/23764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23764&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350584 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23764/head:pull/23764 PR: https://git.openjdk.org/jdk/pull/23764 From dlong at openjdk.org Tue Feb 25 04:05:05 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 25 Feb 2025 04:05:05 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Stricter assertion on ppc64 Thanks, Tom, for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2680380837 From kbarrett at openjdk.org Tue Feb 25 04:24:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 25 Feb 2025 04:24:54 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> Message-ID: On Tue, 25 Feb 2025 00:05:07 GMT, SendaoYan wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Replace SSIZE_FORMAT as %zd Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23290#pullrequestreview-2639196369 From dholmes at openjdk.org Tue Feb 25 04:34:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 04:34:55 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> Message-ID: On Tue, 25 Feb 2025 00:05:07 GMT, SendaoYan wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Replace SSIZE_FORMAT as %zd Seems fine. Thanks Okay so this is no longer about LOG_PLEASE but just the leftover SIZE_FORMAT. > The way that macro is being used, I don't think it's intended to be globally enabled like that. I don't see why not, but I will take that up in the other PR. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23290#pullrequestreview-2639220867 PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2680449014 From dholmes at openjdk.org Tue Feb 25 04:36:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 04:36:51 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan wrote: > Hi all, > > Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically > commented or uncommented to provide some additional logging for some tests of interest. > > This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk. Having debug logging enabled in some tests is not necessarily an issue that needs to be "fixed". You need to ask the person who enabled it why they did so. If it is enabled in some tests then we do need to guard against redefinition incase it is globally enabled (and there is nothing wrong with that either). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2680458000 From iklam at openjdk.org Tue Feb 25 05:40:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 05:40:58 GMT Subject: RFR: 8349888: AOTMode=create crashes with EpsilonGC [v2] In-Reply-To: References: Message-ID: <8R8qmxwBKxr7LNBuFcQ7UTd4xs5y_cR8ESg335zEPC4=.736bfc25-3aa5-4e0f-921e-306ccad1ffe5@github.com> On Mon, 24 Feb 2025 17:04:13 GMT, Aleksey Shipilev wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @shipilev comments - explicitly set memory size to avoid premature failure > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23741#issuecomment-2680645076 From iklam at openjdk.org Tue Feb 25 05:40:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 05:40:59 GMT Subject: Integrated: 8349888: AOTMode=create crashes with EpsilonGC In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 04:26:09 GMT, Ioi Lam wrote: > During AOT cache assembly, some classes may become excluded for various reasons. In the bug report, we have a class that was excluded because it wasn't loaded from a JAR file. > > When AOT-resolving lambda call sites, we already exclude all sites that **refer** to excluded classes. However, we didn't exclude class sites that **live in** an excluded class. This PR fixes that. > > This bug only affects EpsilonGC, which doesn't perform any collection. It doesn't affect other "real" collectors. Please see JBS issue for details. This pull request has now been integrated. Changeset: a6cc37fd Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/a6cc37fdbe77ff3c1bd8e2332f67f48e3850e56b Stats: 111 lines in 2 files changed: 111 ins; 0 del; 0 mod 8349888: AOTMode=create crashes with EpsilonGC Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.org/jdk/pull/23741 From syan at openjdk.org Tue Feb 25 06:14:57 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 06:14:57 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 In-Reply-To: References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Mon, 24 Feb 2025 10:30:07 GMT, Kim Barrett wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > >> make fails with extra flags '-DLOG_PLEASE' > > The way that macro is being used, I don't think it's intended to be globally enabled like that. It's definition is typically > commented or uncommented to provide some additional logging for some tests of interest. I'm wondering if the places > where it is currently being defined are debugging leftovers that shouldn't have been committed. > > For example, I think the LOG_PLEASE and LOG_HERE in runtime/test_os_reserve_between.cpp should either comment > out the LOG_PLEASE definition or just use ordinary logging. Maybe @tstuefe has an opinion? > > Maybe the changes related to LOG_PLEASE definitions ought to be removed and examined as a separate issue? > It's still good that the lingering SIZE_FORMATs were uncovered and are being fixed. Thanks @kimbarrett @coleenp @dholmes-ora for the suggestions and reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2680728031 From syan at openjdk.org Tue Feb 25 06:14:58 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 06:14:58 GMT Subject: Integrated: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 In-Reply-To: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> Message-ID: On Fri, 24 Jan 2025 06:36:34 GMT, SendaoYan wrote: > Hi all, > This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. > > Change has been verified locally, test-fix only, risk is low. This pull request has now been integrated. Changeset: e1081cff Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/e1081cffcbec6020bf4cbec9f795b59b6ec1e9ef Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 Reviewed-by: dholmes, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/23290 From syan at openjdk.org Tue Feb 25 06:57:00 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 06:57:00 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE In-Reply-To: References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 04:34:12 GMT, David Holmes wrote: > and there is nothing wrong with that either. Yes, after https://git.openjdk.org/jdk/pull/23290 merged, the '"LOG_PLEASE" redefined' compiler error do not occur anymore. So I think it's not an issue anymore. I think I should close this PR and the JBS issue as 'not an issue' ------------- PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2680843099 From syan at openjdk.org Tue Feb 25 06:57:01 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 06:57:01 GMT Subject: Withdrawn: 8350584: Check the usage of LOG_PLEASE In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan wrote: > Hi all, > > Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically > commented or uncommented to provide some additional logging for some tests of interest. > > This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23764 From dholmes at openjdk.org Tue Feb 25 07:36:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 07:36:52 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> Message-ID: On Mon, 24 Feb 2025 18:58:41 GMT, Patricio Chilano Mateo wrote: > But note this same issue can happen with other events, the test is just checking for single step. Does that mean we need the suspension check (and suspend) at other locations? I am looking at `JRT_ENTRY` and it uses `ThreadInVMfromJava` - so why are we not checking for suspension in that transition somewhere, or else somewhere directly in the JRT_ENTRY? I guess maybe not all JRT_ENTRY points are safe for suspension? But then how do we know all the callers of `get_jvmti_thread_state` are safe for suspension? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1969133633 From dholmes at openjdk.org Tue Feb 25 08:03:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 08:03:57 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Mon, 24 Feb 2025 13:27:10 GMT, Johan Sj?len wrote: >> Hi, >> >> In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. >> >> This PR does a much smaller change by only focusing on implementing the actual stalling. >> >> The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: >> >> >> $ java -Xlog:async:drop # Dropping mode, same as today >> $ java -Xlog:async:stall # Stalling mode! >> $ java -Xlog:async # Dropping mode by default still >> >> >> The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. >> >> We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. >> >> In pseudo-code we have something like this in the stalling case. >> >> >> void produce() { >> OuterLock olock; >> InnerLock ilock; >> bool out_of_memory = attempt_produce(shared_buffer); >> if (out_of_memory) { >> pmsg = new Message(); >> shared_message = pmsg; >> while (shared_message != nullptr) ilock.wait(); >> free(pmsg); >> } >> } >> >> void consume() { >> InnerLock ilock; >> consume(shared_buffer); >> if (shared_message != nullptr) { >> consume(shared_message); >> ilock.notify(); >> } >> } >> >> >> *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. >> >> *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circu... > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Self-review I don't really get the `Locker` interface as it is used here. Why is Locker not a base class for ProducerLocker and ConsumerLocker, which contains a PlatformMonitor and a Thread*. Using references in Locker to connect it to the standalone globals seems odd to me. It took me a while to get my head around what you were doing. src/hotspot/share/logging/logAsyncWriter.hpp line 65: > 63: class Locker; > 64: class ProducerLocker; > 65: class ConsumerLocker; Why are these needed? ------------- PR Review: https://git.openjdk.org/jdk/pull/22770#pullrequestreview-2639937321 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969177663 From dholmes at openjdk.org Tue Feb 25 08:07:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 08:07:05 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Tue, 25 Feb 2025 08:00:46 GMT, David Holmes wrote: > I don't really get the Locker interface as it is used here. Ugghh - nevermind. Of course you want a scoped Locker helper. The way it was plumbed in confused me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22770#issuecomment-2681038029 From aboldtch at openjdk.org Tue Feb 25 08:11:56 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 25 Feb 2025 08:11:56 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v4] In-Reply-To: References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> Message-ID: On Thu, 13 Feb 2025 09:31:08 GMT, Afshin Zafari wrote: >> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. >> Some compilers do not mask the shift value to the base size and UBSAN catches the case. >> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > count member is removed. Axel's suggestion is implemented. Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22807#pullrequestreview-2640000182 From mbaesken at openjdk.org Tue Feb 25 08:23:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Feb 2025 08:23:01 GMT Subject: Integrated: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: <8g38weKG5rFh4O6Ax_lGUVdPgZusoQsl6s3gZX_Ms7U=.64c5ce2a-b37f-412e-95c4-b6be9dc0dd20@github.com> On Mon, 24 Feb 2025 13:35:14 GMT, Matthias Baesken wrote: > On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. This pull request has now been integrated. Changeset: d551daca Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d551dacaef938cea0cad10047b79a0a7a26dcacb Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 Co-authored-by: Severin Gehwolf Reviewed-by: sgehwolf, asteiner ------------- PR: https://git.openjdk.org/jdk/pull/23749 From mbaesken at openjdk.org Tue Feb 25 08:23:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Feb 2025 08:23:00 GMT Subject: RFR: 8350103: Test containers/systemd/SystemdMemoryAwarenessTest.java fails on Linux ppc64le SLES15 SP6 In-Reply-To: References: Message-ID: <1yoOrNQ_BkmjpllZY04_or8h-07LvQdr-e6u8rltAfY=.751f7d0d-9d56-43c7-8aee-c11b413e930d@github.com> On Mon, 24 Feb 2025 13:35:14 GMT, Matthias Baesken wrote: > On a new SLES 15 SP6 machine cgroup v2 is used by default. Unfortunately the test containers/systemd/SystemdMemoryAwarenessTest.java failed there because of missing memory/cpu delegation. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23749#issuecomment-2681075856 From shade at openjdk.org Tue Feb 25 09:13:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Feb 2025 09:13:00 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:48:25 GMT, Xiaolong Peng wrote: > Hi there, > Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). > > Current safepoint log is like: > > [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms > [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns > > > > The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. > > As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". > > With the new "Leaving safepoint" counter, the log will be like: > > [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms > [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns > > > ### Tests > - [x] Verified the new safepoint log > - [x] Tier 2 Looks good conceptually, I think we just need better names. src/hotspot/share/runtime/safepoint.cpp line 870: > 868: jlong SafepointTracing::_last_safepoint_begin_time_ns = 0; > 869: jlong SafepointTracing::_last_safepoint_sync_time_ns = 0; > 870: jlong SafepointTracing::_last_vmop_evaluation_end_time_ns = 0; >From the adjacent names, I think it should be `_last_safepoint_leave_time_ns`. src/hotspot/share/runtime/safepoint.hpp line 255: > 253: static void begin(VM_Operation::VMOp_Type type); > 254: static void synchronized(int nof_threads, int nof_running, int traps); > 255: static void end_vmop_evaluation(); I think of a little better name: `leave()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/23756#pullrequestreview-2640156507 PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1969293400 PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1969292458 From jsjolen at openjdk.org Tue Feb 25 09:16:38 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 09:16:38 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v20] In-Reply-To: References: Message-ID: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/logging/logAsyncWriter.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22770/files - new: https://git.openjdk.org/jdk/pull/22770/files/ce39257c..d6688e0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From dholmes at openjdk.org Tue Feb 25 09:16:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 09:16:38 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Mon, 24 Feb 2025 13:27:10 GMT, Johan Sj?len wrote: >> Hi, >> >> In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. >> >> This PR does a much smaller change by only focusing on implementing the actual stalling. >> >> The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: >> >> >> $ java -Xlog:async:drop # Dropping mode, same as today >> $ java -Xlog:async:stall # Stalling mode! >> $ java -Xlog:async # Dropping mode by default still >> >> >> The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. >> >> We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. >> >> In pseudo-code we have something like this in the stalling case. >> >> >> void produce() { >> OuterLock olock; >> InnerLock ilock; >> bool out_of_memory = attempt_produce(shared_buffer); >> if (out_of_memory) { >> pmsg = new Message(); >> shared_message = pmsg; >> while (shared_message != nullptr) ilock.wait(); >> free(pmsg); >> } >> } >> >> void consume() { >> InnerLock ilock; >> consume(shared_buffer); >> if (shared_message != nullptr) { >> consume(shared_message); >> ilock.notify(); >> } >> } >> >> >> *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. >> >> *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circu... > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Self-review Looks good. I think it makes sense. Only a couple of minor comments, plus we need the manpage updated. src/hotspot/share/logging/logAsyncWriter.cpp line 133: > 131: while (_stalled_message != nullptr) { > 132: clocker.wait(); > 133: } I was worried about lost wakeups here until I again remembered that we still hold the producer lock while we wait so the only thread that can interact with the clocker is the async logging thread. Perhaps a comment before the while loop: // Note we still hold the producer lock so cannot race against other threads trying to log a message src/hotspot/share/logging/logAsyncWriter.cpp line 205: > 203: > 204: // If we get here we know the AsyncLogWriter is initialized. > 205: ProducerLocker locker; Suggestion: ProducerLocker plocker; src/hotspot/share/logging/logConfiguration.cpp line 639: > 637: > 638: out->print_cr("Asynchronous logging (off by default):"); > 639: out->print_cr(" -Xlog:async[:[mode]]"); This reminded me we need an update to the Java manpage/command-reference as well. src/hotspot/share/runtime/globals.hpp line 1874: > 1872: "Memory budget (in bytes) for the buffer of Asynchronous " \ > 1873: "Logging (-Xlog:async).") \ > 1874: range(DEBUG_ONLY(96) NOT_DEBUG(100*K), 50*M) \ Why 96 when the test uses 192? I guess it could be anything. ------------- PR Review: https://git.openjdk.org/jdk/pull/22770#pullrequestreview-2640175394 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969304525 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969306651 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969313824 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969322750 From jsjolen at openjdk.org Tue Feb 25 09:16:38 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 09:16:38 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: <2NV_QigaBijm2zZoyFApYKyEclyagN6wn_Iq0NhrrwM=.8c3cb96d-ef55-4b42-bd8c-fe5f266e8906@github.com> On Tue, 25 Feb 2025 09:09:03 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Self-review > > src/hotspot/share/runtime/globals.hpp line 1874: > >> 1872: "Memory budget (in bytes) for the buffer of Asynchronous " \ >> 1873: "Logging (-Xlog:async).") \ >> 1874: range(DEBUG_ONLY(96) NOT_DEBUG(100*K), 50*M) \ > > Why 96 when the test uses 192? I guess it could be anything. Short answer: It should be 192, I was confused. Long answer: I picked 96 because that's what I used when hard-coding the buffer size, but I forgot that we have 2 buffers who share `AsyncLogBufferSize` and 192/2 = 96. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969328829 From aboldtch at openjdk.org Tue Feb 25 09:19:05 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 25 Feb 2025 09:19:05 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Mon, 24 Feb 2025 13:27:10 GMT, Johan Sj?len wrote: >> Hi, >> >> In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. >> >> This PR does a much smaller change by only focusing on implementing the actual stalling. >> >> The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: >> >> >> $ java -Xlog:async:drop # Dropping mode, same as today >> $ java -Xlog:async:stall # Stalling mode! >> $ java -Xlog:async # Dropping mode by default still >> >> >> The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. >> >> We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. >> >> In pseudo-code we have something like this in the stalling case. >> >> >> void produce() { >> OuterLock olock; >> InnerLock ilock; >> bool out_of_memory = attempt_produce(shared_buffer); >> if (out_of_memory) { >> pmsg = new Message(); >> shared_message = pmsg; >> while (shared_message != nullptr) ilock.wait(); >> free(pmsg); >> } >> } >> >> void consume() { >> InnerLock ilock; >> consume(shared_buffer); >> if (shared_message != nullptr) { >> consume(shared_message); >> ilock.notify(); >> } >> } >> >> >> *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. >> >> *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circu... > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Self-review Looks good. The `Locker` could have used CRTP, but as this is a stack object using two references should be irrelevant. src/hotspot/share/logging/logAsyncWriter.cpp line 40: > 38: Locker(Thread*& holder, PlatformMonitor& lock) > 39: : _holder(holder), > 40: _lock(lock) { The other constructor in this file indents the initializer list. Suggestion: : _holder(holder), _lock(lock) { src/hotspot/share/logging/logAsyncWriter.cpp line 53: > 51: void notify() { > 52: _lock.notify(); > 53: } Suggestion: } src/hotspot/share/logging/logAsyncWriter.cpp line 128: > 126: } > 127: new (stalled_message) Message(output, decorations, msg, msg_len); > 128: _stalled_message = (Message*)stalled_message; Suggestion: _stalled_message = new (stalled_message) Message(output, decorations, msg, msg_len); ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22770#pullrequestreview-2640019554 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969255459 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969219542 PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969245588 From dholmes at openjdk.org Tue Feb 25 09:22:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 09:22:54 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 This doesn't look right to me. What if we are in a client-only VM build, or a minimal-VM build? I'm not even sure hotspot/libjvm.so is meant to be a filesystem path because it doesn't exist in the filesystem image. ?? ------------- PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2640242325 From rrich at openjdk.org Tue Feb 25 09:34:26 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 25 Feb 2025 09:34:26 GMT Subject: RFR: 8350106: [PPC] Avoid ticks_unknown_not_Java AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set Message-ID: This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where 1. `JavaThread::last_Java_sp()` returns != null 2. `JavaThread::last_Java_pc()` returns null If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)). This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method. For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure. Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null. Testing: * DaCapo Tomcat with async-profiler on a fastdebug build. * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. ------------- Commit messages: - Better handle _last_Java_pc == null Changes: https://git.openjdk.org/jdk/pull/23640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350106 Stats: 25 lines in 2 files changed: 17 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23640/head:pull/23640 PR: https://git.openjdk.org/jdk/pull/23640 From dholmes at openjdk.org Tue Feb 25 09:35:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 09:35:59 GMT Subject: RFR: 8350497: os::create_thread unify init thread attributes part across UNIX platforms In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 10:03:22 GMT, Matthias Baesken wrote: > In os::create_thread the 'init thread attributes' part of the method should be unified across UNIX platforms, e.g. regarding return code checking. Looks fine and trivial. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23746#pullrequestreview-2640309835 From rrich at openjdk.org Tue Feb 25 09:36:28 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 25 Feb 2025 09:36:28 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP Message-ID: With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. This will prevent crashes as described by the JBS item. The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. Testing: * DaCapo Tomcat with async-profiler on a fastdebug build. * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. ------------- Commit messages: - Handle attempt to sample stack while handling SIGTRAP Changes: https://git.openjdk.org/jdk/pull/23641/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23641&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350111 Stats: 16 lines in 2 files changed: 12 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23641/head:pull/23641 PR: https://git.openjdk.org/jdk/pull/23641 From stuefe at openjdk.org Tue Feb 25 09:41:54 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Feb 2025 09:41:54 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:11:55 GMT, Richard Reingruber wrote: > With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. > > This will prevent crashes as described by the JBS item. > > The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. Can this also happen on other platforms when in signal handling (e.g. segfault based nullchecks?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2681341134 From jsjolen at openjdk.org Tue Feb 25 09:46:06 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 09:46:06 GMT Subject: RFR: 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry Message-ID: Hi, This fixes a potential null pointer dereference in case of OOM. We return `nullptr` instead of `p` because I didn't feel like casting `p` from `void*` to `MallocSiteHashtableEntry*`. I believe that this is a trivial PR, and I would appreciate it if a reviewer agrees! Thanks, Johan ------------- Commit messages: - Check for null Changes: https://git.openjdk.org/jdk/pull/23768/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23768&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350636 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23768/head:pull/23768 PR: https://git.openjdk.org/jdk/pull/23768 From dholmes at openjdk.org Tue Feb 25 09:47:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 09:47:09 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan wrote: > Hi all, > > Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically > commented or uncommented to provide some additional logging for some tests of interest. > > This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk. I don't understand how the redefinition error could be resolved. ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2681356240 From jsjolen at openjdk.org Tue Feb 25 09:53:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 09:53:58 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Tue, 25 Feb 2025 08:32:40 GMT, Axel Boldt-Christmas wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Self-review > > src/hotspot/share/logging/logAsyncWriter.cpp line 40: > >> 38: Locker(Thread*& holder, PlatformMonitor& lock) >> 39: : _holder(holder), >> 40: _lock(lock) { > > The other constructor in this file indents the initializer list. > Suggestion: > > : _holder(holder), > _lock(lock) { I did the opposite, and changed the style of the other constructor. AFAIK, the style that `Locker` has currently is the most common in Hotspot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969401037 From dholmes at openjdk.org Tue Feb 25 10:01:08 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 10:01:08 GMT Subject: RFR: 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:32:50 GMT, Johan Sj?len wrote: > Hi, > > This fixes a potential null pointer dereference in case of OOM. We return `nullptr` instead of `p` because I didn't feel like casting `p` from `void*` to `MallocSiteHashtableEntry*`. > > I believe that this is a trivial PR, and I would appreciate it if a reviewer agrees! > > Thanks, > Johan LGTM. Trivial? hmmm okay. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23768#pullrequestreview-2640416785 From jsjolen at openjdk.org Tue Feb 25 10:01:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 10:01:28 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v21] In-Reply-To: References: Message-ID: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: - Merge remote-tracking branch 'origin/ul-stalling-mode-2' into ul-stalling-mode-2 - Comment - Axel's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22770/files - new: https://git.openjdk.org/jdk/pull/22770/files/d6688e0f..d932912d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=19-20 Stats: 11 lines in 1 file changed: 2 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From jsjolen at openjdk.org Tue Feb 25 10:01:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 10:01:28 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: <3uRERxmbDeN9xCV5547yvynATS75xwOHGdtyGrXhESQ=.b1454835-4ec8-40e6-9ca4-8b4e97a0ed90@github.com> On Tue, 25 Feb 2025 09:16:07 GMT, Axel Boldt-Christmas wrote: > Looks good. > > The `Locker` could have used CRTP, but as this is a stack object using two references should be irrelevant. Ooh right, I was thinking about how I could get a hold of `_holder`without passing it into the ctr. Good reminder, but I agree, this is so trivial so we can keep it as-is. I fixed your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22770#issuecomment-2681392466 From mdoerr at openjdk.org Tue Feb 25 10:21:03 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 25 Feb 2025 10:21:03 GMT Subject: RFR: 8350106: [PPC] Avoid ticks_unknown_not_Java AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:11:05 GMT, Richard Reingruber wrote: > This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where > > 1. `JavaThread::last_Java_sp()` returns != null > 2. `JavaThread::last_Java_pc()` returns null > > If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)). > > This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method. > > For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure. > > Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. Nice enhancement to get more samples! LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23640#pullrequestreview-2640504700 From mdoerr at openjdk.org Tue Feb 25 10:21:52 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 25 Feb 2025 10:21:52 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:11:55 GMT, Richard Reingruber wrote: > With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. > > This will prevent crashes as described by the JBS item. > > The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23641#pullrequestreview-2640507857 From syan at openjdk.org Tue Feb 25 10:27:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 10:27:52 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE In-Reply-To: References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 09:43:58 GMT, David Holmes wrote: > I don't understand how the redefinition error could be resolved. ?? Sorry, I forgot pass `--with-gtest=/home/yansendao/git/googletest-v1.14.x` argument when execute configure command. Without `--with-gtest` argument make will success with extra CXXFLAGS/CFLAGS=-DLOG_PLEASE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2681482196 From syan at openjdk.org Tue Feb 25 10:43:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 10:43:52 GMT Subject: RFR: 8350584: Check the usage of LOG_PLEASE In-Reply-To: References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com> Message-ID: On Tue, 25 Feb 2025 04:34:12 GMT, David Holmes wrote: > Having debug logging enabled in some tests is not necessarily an issue that needs to be "fixed". You need to ask the person who enabled it why they did so. > > If it is enabled in some tests then we do need to guard against redefinition incase it is globally enabled (and there is nothing wrong with that either). @tstuefe @rkennke Hi, Does the `#define LOG_PLEASE` in gtests is necessary actually, should we comment out the `#define LOG_PLEASE`, because it will cause make report redefinition error when configure with arguments `--with-extra-cflags=-DLOG_PLEASE --with-extra-cxxflags=-DLOG_PLEASE` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2681530047 From sspitsyn at openjdk.org Tue Feb 25 10:57:53 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Feb 2025 10:57:53 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> Message-ID: On Tue, 25 Feb 2025 07:34:24 GMT, David Holmes wrote: >>> But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state? >>> >> Only for the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization(). In these cases we know there are no VM monitors held though. >> >>> Or should we simply be passing allow_suspend=true into more ThreadBlockInVM transitions? >>> >> I think this would be harder to get right. First because these ThreadBlockInVM could be anywhere along the path where we post an event. But also because at those points the thread could be holding VM monitors so we cannot suspend. Here where we post the event we are already checking no VM monitors are held. >> >>> And again what is the call stack for this? >>> >> For single step event the call is coming from InterpreterRuntime::at_safepoint(): >> >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x1212523] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0xd3 (jvmtiExport.cpp:425) >> V [libjvm.so+0x121de66] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x66 (jvmtiExport.cpp:1332) >> V [libjvm.so+0xed8398] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1165) >> >> >> But note this same issue can happen with other events, the test is just checking for single step. > >> But note this same issue can happen with other events, the test is just checking for single step. > > Does that mean we need the suspension check (and suspend) at other locations? > > I am looking at `JRT_ENTRY` and it uses `ThreadInVMfromJava` - so why are we not checking for suspension in that transition somewhere, or else somewhere directly in the JRT_ENTRY? I guess maybe not all JRT_ENTRY points are safe for suspension? But then how do we know all the callers of `get_jvmti_thread_state` are safe for suspension? > What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack. As Patricio pointed out (thanks, Patricio), with this particular test `GetStackTraceSuspendedStressTest.java` the `JvmtiExport::get_jvmti_thread_state` is called from `JvmtiExport::at_single_stepping_point()` which is called from `InterpreterRuntime::at_safepoint()`. There are no other points before to place the `ThreadBlockInVM`. It can be different for other events. As an experiment I've added the following assert at the beginning of the `JvmtiExport::get_jvmti_thread_state()` and ran the mach5 tiers 1-6: + assert(!thread->owns_locks(), "all locks must be released before suspension"); and got many failures of the following tests: applications/renaissance/RenaissanceStressTest.java applications/runthese/RunThese30M.java applications/skynet/SkyNet.java serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/TestDescription.java vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java The assert was only triggered in the context of `post_dynamic_code_generated_while_holding_locks()` which make a direct call to `JvmtiExport::get_jvmti_thread_state()`. A typical stack trace is: Current thread (0x00007ff468008290): JavaThread "ForkJoinPool-1-worker-4" daemon [_thread_in_vm, id=437394, stack(0x00007ff4eb6ea000,0x00007ff4eb7ea000) (1024K)] Stack: [0x00007ff4eb6ea000,0x00007ff4eb7ea000], sp=0x00007ff4eb7e5190, free space=1004k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1223114] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x94 (jvmtiExport.cpp:423) V [libjvm.so+0x122628c] JvmtiExport::post_dynamic_code_generated_while_holding_locks(char const*, unsigned char*, unsigned char*)+0x3c (jvmtiExport.cpp:2636) V [libjvm.so+0x19ad47e] VtableStubs::find_stub(bool, int)+0x1ce (vtableStubs.cpp:238) V [libjvm.so+0xa81b0b] CompiledIC::set_to_megamorphic(CallInfo*)+0x4b (vtableStubs.hpp:107) V [libjvm.so+0x17005a4] SharedRuntime::handle_ic_miss_helper(JavaThread*)+0x2d4 (sharedRuntime.cpp:1637) V [libjvm.so+0x1700a08] SharedRuntime::handle_wrong_method_ic_miss(JavaThread*)+0xf8 (sharedRuntime.cpp:1441) v ~RuntimeStub::Shared Runtime ic_miss_blob 0x00007ff50be5f449 J 378 c1 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;I)V java.base at 25-internal (18 bytes) @ 0x00007ff50485c274 [0x00007ff50485c040+0x0000000000000234] j java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+362 java.base at 25-internal j java.util.concurrent.ForkJoinWorkerThread.run()V+31 java.base at 25-internal v ~StubRoutines::call_stub 0x00007ff50bd48d01 V [libjvm.so+0xf06d9c] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4ac (javaCalls.cpp:415) V [libjvm.so+0xf07483] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x2f3 (javaCalls.cpp:323) V [libjvm.so+0xf07a86] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76 (javaCalls.cpp:185) V [libjvm.so+0x107cc33] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2756) V [libjvm.so+0xf417de] JavaThread::thread_main_inner()+0xee (javaThread.cpp:776) V [libjvm.so+0x1896416] Thread::call_run()+0xb6 (thread.cpp:231) V [libjvm.so+0x156e5a8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877) The following fix fixed the issue: git diff diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp index 377dece1b1c..eda99e57b5d 100644 --- a/src/hotspot/share/prims/jvmtiExport.cpp +++ b/src/hotspot/share/prims/jvmtiExport.cpp @@ -418,11 +418,12 @@ JvmtiExport::get_jvmti_interface(JavaVM *jvm, void **penv, jint version) { } JvmtiThreadState* -JvmtiExport::get_jvmti_thread_state(JavaThread *thread) { +JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) { assert(thread == JavaThread::current(), "must be current thread"); + assert(!allow_suspend || !thread->owns_locks(), "all locks must be released before suspension"); if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { JvmtiEventController::thread_started(thread); - if (thread->is_suspended()) { + if (allow_suspend && thread->is_suspended()) { // suspend here if there is a suspend request ThreadBlockInVM tbivm(thread, true /* allow suspend */); } @@ -2632,7 +2633,7 @@ void JvmtiExport::post_dynamic_code_generated_while_holding_locks(const char* na // jvmti thread state. // The collector and/or state might be null if JvmtiDynamicCodeEventCollector // has been initialized while JVMTI_EVENT_DYNAMIC_CODE_GENERATED was disabled. - JvmtiThreadState *state = get_jvmti_thread_state(thread); + JvmtiThreadState *state = get_jvmti_thread_state(thread, false /* allow_suspend = false */ ); if (state != nullptr) { JvmtiDynamicCodeEventCollector *collector = state->get_dynamic_code_event_collector(); if (collector != nullptr) { diff --git a/src/hotspot/share/prims/jvmtiExport.hpp b/src/hotspot/share/prims/jvmtiExport.hpp index 324e437411a..f4bede4d76e 100644 --- a/src/hotspot/share/prims/jvmtiExport.hpp +++ b/src/hotspot/share/prims/jvmtiExport.hpp @@ -309,7 +309,7 @@ class JvmtiExport : public AllStatic { // If the jvmti_thread_state is absent and any thread filtered event // is enabled globally then it is created. // Otherwise, the thread->jvmti_thread_state() is returned. - static JvmtiThreadState* get_jvmti_thread_state(JavaThread *thread); + static JvmtiThreadState* get_jvmti_thread_state(JavaThread *thread, bool allow_suspend = true); // single stepping management methods static void at_single_stepping_point(JavaThread *thread, Method* method, address location) NOT_JVMTI_RETURN; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1969530676 From azafari at openjdk.org Tue Feb 25 11:06:26 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:06:26 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. 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/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/5f4bc6dd..5aa4556a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=29-30 Stats: 48 lines in 5 files changed: 5 ins; 11 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Tue Feb 25 11:06:26 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:06:26 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v30] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <8jsJSagIyDrTIC0DRnJtOjNaYQI3UaKEn4TC42lXqcU=.8e76aefd-5b48-48bd-982f-aceb9bd12d19@github.com> On Mon, 24 Feb 2025 12:45:51 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > test file got back, fixed coding style Description is up to date now. Other related PRs are: https://github.com/openjdk/jdk/pull/23769 https://github.com/openjdk/jdk/pull/23770 https://github.com/openjdk/jdk/pull/23771 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2681581172 From azafari at openjdk.org Tue Feb 25 11:06:27 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:06:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v29] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 24 Feb 2025 08:24:06 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> once more. > > src/hotspot/share/nmt/memoryFileTracker.cpp line 183: > >> 181: // Only account the committed memory. >> 182: snap->commit_memory(current->committed()); >> 183: });} > > Style: Restore to what it was before. Done. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 404: > >> 402: friend class VirtualMemoryTrackerTest; >> 403: friend class CommittedVirtualMemoryTest; >> 404: > > These two classes doesn't exist anymore. The first got back to life. The second is removed. > src/hotspot/share/nmt/vmatree.cpp line 80: > >> 78: MemTag tag = leqA_n->val().out.mem_tag(); >> 79: stA.out.set_tag(tag); >> 80: LEQ_A.state.out.set_tag(tag); > > This also seems like a bug fix that must be separated out into a separate PR along with test cases. Moved to this PR: https://github.com/openjdk/jdk/pull/23771 > src/hotspot/share/nmt/vmatree.cpp line 211: > >> 209: // Finally, we can register the new region [A, B)'s summary data. >> 210: MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag; >> 211: SingleDiff& rescom = diff.tag[NMTUtil::tag_to_index(tag_to_change)]; > > This seems to be a bug fix to 8335091. You should open a separate mainline PR with this fix and add a testcase for it. Your fix should be integrated before this PR is. Moved to this PR: https://github.com/openjdk/jdk/pull/23771 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969542371 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969543273 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969538538 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969539202 From azafari at openjdk.org Tue Feb 25 11:06:27 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:06:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v30] In-Reply-To: <2fTUz_oDUK6cNc-DY5AATuXDaqjQZ6XUa-t1VF_UzaI=.6fb21f2f-eccc-4950-9a31-98f467be48e6@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <2fTUz_oDUK6cNc-DY5AATuXDaqjQZ6XUa-t1VF_UzaI=.6fb21f2f-eccc-4950-9a31-98f467be48e6@github.com> Message-ID: <4vEqzxQM4EWODHCEEEU4HsEB9n11OY0B9askJZwUCaQ=.03a1652b-c793-4a57-9c44-3f55ae1f2a41@github.com> On Mon, 24 Feb 2025 20:01:18 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> test file got back, fixed coding style > > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 381: > >> 379: bool remove_uncommitted_region (address base_addr, size_t size); >> 380: bool remove_released_region (address base_addr, size_t size); >> 381: bool remove_released_region (ReservedMemoryRegion* rgn); > > Why are they returning `bool` ? I don't see the return value being used anywhere? Good catch. They are removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969540784 From azafari at openjdk.org Tue Feb 25 11:06:27 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:06:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v28] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 24 Feb 2025 08:09:46 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed remaining of the unrelated changes. > > test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 1: > >> (failed to retrieve contents of file, check the PR for context) > Why are these tests removed? Can they be adapted to the new implementation? They are now implemented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1969543987 From jsjolen at openjdk.org Tue Feb 25 11:12:38 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 11:12:38 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v22] In-Reply-To: References: Message-ID: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: - Fix - Update markdown file - Increase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22770/files - new: https://git.openjdk.org/jdk/pull/22770/files/d932912d..e81f2d61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22770&range=20-21 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22770/head:pull/22770 PR: https://git.openjdk.org/jdk/pull/22770 From azafari at openjdk.org Tue Feb 25 11:15:05 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:15:05 GMT Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with memory tag Message-ID: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com> There were some remaining flag or type for Memory Tag contexts. Tests: gtest:NMT* and runtime/NMT sets of tasks all passed. ------------- Commit messages: - 8350565: NMT: remaining memory flag/type to be replaced with memory tag Changes: https://git.openjdk.org/jdk/pull/23769/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23769&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350565 Stats: 77 lines in 17 files changed: 0 ins; 0 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/23769.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23769/head:pull/23769 PR: https://git.openjdk.org/jdk/pull/23769 From azafari at openjdk.org Tue Feb 25 11:15:26 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 11:15:26 GMT Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region Message-ID: When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR. With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR. Tests: linux-x64-debug, gtest:NMT*, runtime/NMT ------------- Commit messages: - 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region Changes: https://git.openjdk.org/jdk/pull/23771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23771&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350567 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23771/head:pull/23771 PR: https://git.openjdk.org/jdk/pull/23771 From jsjolen at openjdk.org Tue Feb 25 11:17:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 11:17:58 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Tue, 25 Feb 2025 09:04:04 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Self-review > > src/hotspot/share/logging/logConfiguration.cpp line 639: > >> 637: >> 638: out->print_cr("Asynchronous logging (off by default):"); >> 639: out->print_cr(" -Xlog:async[:[mode]]"); > > This reminded me we need an update to the Java manpage/command-reference as well. Fixed! See picture for a render. ![image](https://github.com/user-attachments/assets/105ff56a-d79e-49ee-bc91-89733af5b1b0) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1969560749 From coleenp at openjdk.org Tue Feb 25 12:32:58 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 25 Feb 2025 12:32:58 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> Message-ID: <2ObPsURtgHIyw9goSVVWEY567VZbF5kfNR-KI2vo8gQ=.f86f0bbd-f3c2-4409-aeb1-6d1bc1aa8676@github.com> On Tue, 25 Feb 2025 00:05:07 GMT, SendaoYan wrote: >> Hi all, >> This is complement implement PR of [JDK-8347990](https://bugs.openjdk.org/browse/JDK-8347990), which fix make fails with extra flags '-DLOG_PLEASE'. >> >> Change has been verified locally, test-fix only, risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Replace SSIZE_FORMAT as %zd I requested since you were doing this, that you should fix SIZE_FORMAT_HEX in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2681806494 From syan at openjdk.org Tue Feb 25 12:46:59 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 12:46:59 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <2ObPsURtgHIyw9goSVVWEY567VZbF5kfNR-KI2vo8gQ=.f86f0bbd-f3c2-4409-aeb1-6d1bc1aa8676@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> <2ObPsURtgHIyw9goSVVWEY567VZbF5kfNR-KI2vo8gQ=.f86f0bbd-f3c2-4409-aeb1-6d1bc1aa8676@github.com> Message-ID: On Tue, 25 Feb 2025 12:30:09 GMT, Coleen Phillimore wrote: > I requested since you were doing this, that you should fix SIZE_FORMAT_HEX in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp too. Sorry, I did not got your request exately. Do you mean the `SIZE_FORMAT_HEX` should be deal with? What's flags should be replace to `SIZE_FORMAT_HEX` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2681866435 From jwaters at openjdk.org Tue Feb 25 13:17:51 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 25 Feb 2025 13:17:51 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 Agree with David, also it's interesting to see that this code expects the JVM to be in a hotspot directory, I don't think I've ever seen any JDK distribution have HotSpot inside a hotspot directory before ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2681949691 From mbaesken at openjdk.org Tue Feb 25 13:33:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Feb 2025 13:33:56 GMT Subject: RFR: 8350497: os::create_thread unify init thread attributes part across UNIX platforms In-Reply-To: References: Message-ID: <4wlmjnzguKVQdsKrDI-gmjMIQFeLOUIY3T6yMxuPCaw=.bf25e29f-a39c-4cdc-8424-9dbdf1dd7d51@github.com> On Mon, 24 Feb 2025 10:03:22 GMT, Matthias Baesken wrote: > In os::create_thread the 'init thread attributes' part of the method should be unified across UNIX platforms, e.g. regarding return code checking. Hi David, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23746#issuecomment-2681991170 From mbaesken at openjdk.org Tue Feb 25 13:33:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Feb 2025 13:33:57 GMT Subject: Integrated: 8350497: os::create_thread unify init thread attributes part across UNIX platforms In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 10:03:22 GMT, Matthias Baesken wrote: > In os::create_thread the 'init thread attributes' part of the method should be unified across UNIX platforms, e.g. regarding return code checking. This pull request has now been integrated. Changeset: cfeb7d6c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/cfeb7d6c964f63184c939f6f0625c6e7f1afdc31 Stats: 12 lines in 2 files changed: 9 ins; 0 del; 3 mod 8350497: os::create_thread unify init thread attributes part across UNIX platforms Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23746 From sgehwolf at openjdk.org Tue Feb 25 14:04:20 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Feb 2025 14:04:20 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev wrote: >> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening. >> >> Testing: >>>>And after the patch this would become this, right? >>>>``` >>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >>>>/sys/fs/cgroup/cpu,cpuacct/ >>>>``` >>> >>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be >>> >>>``` >>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c >>>/sys/fs/cgroup/cpu,cpuacct/bad >>>/sys/fs/cgroup/cpu,cpuacct/ >>>``` >> >> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. > >> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. > > The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`. > > ========== NEW TEST CASE: Cgroup V1 subgroup memory limit: 100m > [COMMAND] > docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version > [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369 > [ELAPSED: 5385 ms] > [STDERR] > > [STDOUT] > [0.002s][trace][os,container] OSContainer::init: Initializing Container Support > [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. > > With additional logging added before line 77, this could be looking like > > [STDOUT] > [0.002s][trace][os,container] OSContainer::init: Initializing Container Support > [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. > [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. > [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. > > Before the fix, the current path adjustment scheme would produce the following order: > > /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test > /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370 > /sys/fs/cgroup/memory/docker > /sys/fs/cgroup/memory > > Only the last path is valid in the conta... @sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code: https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77 That is, some sub-group without a match, but some with one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682078012 From sgehwolf at openjdk.org Tue Feb 25 14:09:03 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Feb 2025 14:09:03 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v15] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 21:20:49 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: > > - added high level comment to CgroupV1Controller::set_subsystem_path > - fix minor issue calling .getNameCount() twice src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42: > 40: * When runs in a container, the method handles the case > 41: * when a process is moved between cgroups. > 42: */ This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1969851316 From azafari at openjdk.org Tue Feb 25 14:31:00 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 25 Feb 2025 14:31:00 GMT Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int' [v4] In-Reply-To: References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com> Message-ID: On Thu, 13 Feb 2025 09:31:08 GMT, Afshin Zafari wrote: >> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up. >> Some compilers do not mask the shift value to the base size and UBSAN catches the case. >> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > count member is removed. Axel's suggestion is implemented. Dear @kimbarrett, if you have no comments on the changes of this PR, it can be integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22807#issuecomment-2682171458 From jsjolen at openjdk.org Tue Feb 25 14:33:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 14:33:03 GMT Subject: RFR: 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:32:50 GMT, Johan Sj?len wrote: > Hi, > > This fixes a potential null pointer dereference in case of OOM. We return `nullptr` instead of `p` because I didn't feel like casting `p` from `void*` to `MallocSiteHashtableEntry*`. > > I believe that this is a trivial PR, and I would appreciate it if a reviewer agrees! > > Thanks, > Johan Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23768#issuecomment-2682178275 From jsjolen at openjdk.org Tue Feb 25 14:33:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 25 Feb 2025 14:33:03 GMT Subject: Integrated: 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:32:50 GMT, Johan Sj?len wrote: > Hi, > > This fixes a potential null pointer dereference in case of OOM. We return `nullptr` instead of `p` because I didn't feel like casting `p` from `void*` to `MallocSiteHashtableEntry*`. > > I believe that this is a trivial PR, and I would appreciate it if a reviewer agrees! > > Thanks, > Johan This pull request has now been integrated. Changeset: 62f39bd6 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/62f39bd6468d1c99bb0d6af6a96972bae96a7588 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23768 From mdoerr at openjdk.org Tue Feb 25 15:23:54 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 25 Feb 2025 15:23:54 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:38:58 GMT, Thomas Stuefe wrote: > Can this also happen on other platforms when in signal handling (e.g. segfault based nullchecks?) I guess such problems can happen on all platforms which use some kind of link register (aarch64, s390, ?). I also don't like that we lose so many samples with this current solution. I only approved it because I think it is better than crashing. Recognizing that a signal handler is on stack may be a better solution. Do we already have functionality for that? There are efforts to read the stack at a safepoint. @parttimenerd: Would it make sense to wait for that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2682353832 From syan at openjdk.org Tue Feb 25 15:43:27 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 15:43:27 GMT Subject: RFR: 8350665: SIZE_FORMAT_HEX macro undefined in gtest Message-ID: Hi all, SIZE_FORMAT_HEX macro undefined in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp. The SIZE_FORMAT_HEX macro should be replace as "0x%zx" instead. Trivial fix, change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8350665: SIZE_FORMAT_HEX macro undefined in gtest Changes: https://git.openjdk.org/jdk/pull/23778/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23778&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350665 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23778.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23778/head:pull/23778 PR: https://git.openjdk.org/jdk/pull/23778 From gziemski at openjdk.org Tue Feb 25 15:44:11 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 25 Feb 2025 15:44:11 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Tue, 25 Feb 2025 11:06:26 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > reviews applied. How would I go about verifying the performance gain? You mentioned previously that you wrote a microbenchmark for testing this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2682420600 From syan at openjdk.org Tue Feb 25 15:44:12 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 25 Feb 2025 15:44:12 GMT Subject: RFR: 8348536: Remove remain SIZE_FORMAT usage after JDK-8347990 [v4] In-Reply-To: <1F45RaE7dAPnKLLJ9dJeEdCrN0Gl4j1YuEg7ye9xLns=.52078a12-835e-4d7b-92c9-fa2fe7f0a431@github.com> References: <5qgeHZCPVnLjxBIF22Th8o50iA8UPOxCVZ_T3P84skU=.ca3d83cc-4d7b-45b4-be83-c516c8fb64ef@github.com> <1HQXm0aeTg7XOA4FdY-cqGPBQPacekMK9MEGMVIrmmA=.4a0f2276-28fe-4301-90f0-b6ff77c91580@github.com> <1F45RaE7dAPnKLLJ9dJeEdCrN0Gl4j1YuEg7ye9xLns=.52078a12-835e-4d7b-92c9-fa2fe7f0a431@github.com> Message-ID: On Tue, 25 Feb 2025 12:58:16 GMT, Coleen Phillimore wrote: > From the test_globalDefinitions.cpp, this seems like a good format for that. If you want to make a trivial change. check_format("0x%zx", (intx)0x123, "0x123"); I have create a new PR https://github.com/openjdk/jdk/pull/23778 to fix remain SIZE_FORMAT_HEX macro undefined issue since this PR has been integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23290#issuecomment-2682419522 From coleenp at openjdk.org Tue Feb 25 15:49:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 25 Feb 2025 15:49:55 GMT Subject: RFR: 8350665: SIZE_FORMAT_HEX macro undefined in gtest In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:37:40 GMT, SendaoYan wrote: > Hi all, > > SIZE_FORMAT_HEX macro undefined in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp. > The SIZE_FORMAT_HEX macro should be replace as "0x%zx" instead. > > Trivial fix, change has been verified locally, test-fix only, no risk. Looks great, and trivial. Thanks for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23778#pullrequestreview-2641573129 From stuefe at openjdk.org Tue Feb 25 15:55:04 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Feb 2025 15:55:04 GMT Subject: RFR: 8350665: SIZE_FORMAT_HEX macro undefined in gtest In-Reply-To: References: Message-ID: <2y0-EvQMcPS4tr2GemihHKdT_mdEil2GJZ3DnlYNoa4=.6313b32c-7de6-48c4-b582-fa36a7b56fa4@github.com> On Tue, 25 Feb 2025 15:37:40 GMT, SendaoYan wrote: > Hi all, > > SIZE_FORMAT_HEX macro undefined in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp. > The SIZE_FORMAT_HEX macro should be replace as "0x%zx" instead. > > Trivial fix, change has been verified locally, test-fix only, no risk. ok ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23778#pullrequestreview-2641598889 From mbaesken at openjdk.org Tue Feb 25 16:04:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Feb 2025 16:04:21 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX Message-ID: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. ------------- Commit messages: - JDK-8350667 Changes: https://git.openjdk.org/jdk/pull/23779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350667 Stats: 14 lines in 3 files changed: 2 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23779/head:pull/23779 PR: https://git.openjdk.org/jdk/pull/23779 From iklam at openjdk.org Tue Feb 25 16:08:08 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 16:08:08 GMT Subject: RFR: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized Message-ID: Please review this trivial patch. The `has_extra_module_paths` local variable should be initialized to `false`. ------------- Commit messages: - 8350668: has_extra_module_paths in filemap.cpp may be uninitialized Changes: https://git.openjdk.org/jdk/pull/23780/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23780&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350668 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23780/head:pull/23780 PR: https://git.openjdk.org/jdk/pull/23780 From ccheung at openjdk.org Tue Feb 25 16:08:08 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 16:08:08 GMT Subject: RFR: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:59:46 GMT, Ioi Lam wrote: > Please review this trivial patch. The `has_extra_module_paths` local variable should be initialized to `false`. Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23780#pullrequestreview-2641643517 From schernyshev at openjdk.org Tue Feb 25 16:34:04 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 25 Feb 2025 16:34:04 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v15] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 14:06:03 GMT, Severin Gehwolf wrote: > This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly? Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970137041 From stuefe at openjdk.org Tue Feb 25 16:41:02 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 25 Feb 2025 16:41:02 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: On Tue, 25 Feb 2025 15:58:36 GMT, Matthias Baesken wrote: > The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. ok ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23779#pullrequestreview-2641758618 From xpeng at openjdk.org Tue Feb 25 16:58:17 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 25 Feb 2025 16:58:17 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v2] In-Reply-To: References: Message-ID: > Hi there, > Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). > > Current safepoint log is like: > > [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms > [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns > > > > The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. > > As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". > > With the new "Leaving safepoint" counter, the log will be like: > > [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms > [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns > > > ### Tests > - [x] Verified the new safepoint log > - [x] Tier 2 Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23756/files - new: https://git.openjdk.org/jdk/pull/23756/files/e2bbd440..166ba0e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23756&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23756&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23756/head:pull/23756 PR: https://git.openjdk.org/jdk/pull/23756 From shade at openjdk.org Tue Feb 25 16:58:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Feb 2025 16:58:17 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v2] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 16:54:58 GMT, Xiaolong Peng wrote: >> Hi there, >> Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). >> >> Current safepoint log is like: >> >> [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms >> [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns >> >> >> >> The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. >> >> As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". >> >> With the new "Leaving safepoint" counter, the log will be like: >> >> [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms >> [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns >> >> >> ### Tests >> - [x] Verified the new safepoint log >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Renames src/hotspot/share/runtime/safepoint.cpp line 870: > 868: jlong SafepointTracing::_last_safepoint_begin_time_ns = 0; > 869: jlong SafepointTracing::_last_safepoint_sync_time_ns = 0; > 870: jlong SafepointTracing::_last_leave_safepoint_time_ns = 0; Note: it is `_last_safepoint_...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1970183768 From xpeng at openjdk.org Tue Feb 25 17:03:42 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 25 Feb 2025 17:03:42 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v3] In-Reply-To: References: Message-ID: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> > Hi there, > Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). > > Current safepoint log is like: > > [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms > [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns > > > > The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. > > As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". > > With the new "Leaving safepoint" counter, the log will be like: > > [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms > [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns > > > ### Tests > - [x] Verified the new safepoint log > - [x] Tier 2 Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23756/files - new: https://git.openjdk.org/jdk/pull/23756/files/166ba0e0..b6c86f68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23756&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23756&range=01-02 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23756/head:pull/23756 PR: https://git.openjdk.org/jdk/pull/23756 From shade at openjdk.org Tue Feb 25 17:05:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Feb 2025 17:05:05 GMT Subject: RFR: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:59:46 GMT, Ioi Lam wrote: > Please review this trivial patch. The `has_extra_module_paths` local variable should be initialized to `false`. Looks fine! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23780#pullrequestreview-2641843250 From xpeng at openjdk.org Tue Feb 25 17:06:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 25 Feb 2025 17:06:04 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v3] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 08:52:43 GMT, Aleksey Shipilev wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Renames > > src/hotspot/share/runtime/safepoint.cpp line 870: > >> 868: jlong SafepointTracing::_last_safepoint_begin_time_ns = 0; >> 869: jlong SafepointTracing::_last_safepoint_sync_time_ns = 0; >> 870: jlong SafepointTracing::_last_vmop_evaluation_end_time_ns = 0; > > From the adjacent names, I think it should be `_last_safepoint_leave_time_ns`. Thanks, I have updated the names. > src/hotspot/share/runtime/safepoint.hpp line 255: > >> 253: static void begin(VM_Operation::VMOp_Type type); >> 254: static void synchronized(int nof_threads, int nof_running, int traps); >> 255: static void end_vmop_evaluation(); > > I think of a little better name: `leave()`? Thanks, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1970198067 PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1970198366 From xpeng at openjdk.org Tue Feb 25 17:12:12 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 25 Feb 2025 17:12:12 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v2] In-Reply-To: References: Message-ID: <199Fzft1rm7MKPjVV8EOfX5mBrvSWW9sybuG_ZjPDcg=.960ef762-69b1-40a7-ab3f-21a5094c08c6@github.com> On Tue, 25 Feb 2025 16:54:43 GMT, Aleksey Shipilev wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Renames > > src/hotspot/share/runtime/safepoint.cpp line 870: > >> 868: jlong SafepointTracing::_last_safepoint_begin_time_ns = 0; >> 869: jlong SafepointTracing::_last_safepoint_sync_time_ns = 0; >> 870: jlong SafepointTracing::_last_leave_safepoint_time_ns = 0; > > Note: it is `_last_safepoint_...` lol, fixed. I realized it after pushing code(wasn't feeling conformable to put verb after the noun.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23756#discussion_r1970204051 From shade at openjdk.org Tue Feb 25 17:12:12 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 25 Feb 2025 17:12:12 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v3] In-Reply-To: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> References: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> Message-ID: On Tue, 25 Feb 2025 17:03:42 GMT, Xiaolong Peng wrote: >> Hi there, >> Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). >> >> Current safepoint log is like: >> >> [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms >> [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns >> >> >> >> The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. >> >> As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". >> >> With the new "Leaving safepoint" counter, the log will be like: >> >> [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms >> [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns >> >> >> ### Tests >> - [x] Verified the new safepoint log >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Renames This looks fine to me, but someone else should take a look as well. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23756#pullrequestreview-2641861802 From sgehwolf at openjdk.org Tue Feb 25 17:14:10 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 25 Feb 2025 17:14:10 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v15] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 16:31:05 GMT, Sergey Chernyshev wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42: >> >>> 40: * When runs in a container, the method handles the case >>> 41: * when a process is moved between cgroups. >>> 42: */ >> >> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly? > >> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly? > > Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means. A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch. Example: Sets the subsystem path for a controller. The common container case is handled by XXX. When a process has been moved from a cgroup to another the following happens: - A - B - C I believe this is desperately needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970211567 From schernyshev at openjdk.org Tue Feb 25 17:23:00 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 25 Feb 2025 17:23:00 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: <1dczYd447I2XbdYWyDWOceZH6YjiJIM7rmsM2l2kAMM=.ea796f48-3ac2-412f-badd-46e08942c9bd@github.com> On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev wrote: >> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening. >> >> Testing: >>>>And after the patch this would become this, right? >>>>``` >>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >>>>/sys/fs/cgroup/cpu,cpuacct/ >>>>``` >>> >>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be >>> >>>``` >>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c >>>/sys/fs/cgroup/cpu,cpuacct/bad >>>/sys/fs/cgroup/cpu,cpuacct/ >>>``` >> >> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. > >> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those. > > The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`. > > ========== NEW TEST CASE: Cgroup V1 subgroup memory limit: 100m > [COMMAND] > docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version > [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369 > [ELAPSED: 5385 ms] > [STDERR] > > [STDOUT] > [0.002s][trace][os,container] OSContainer::init: Initializing Container Support > [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. > > With additional logging added before line 77, this could be looking like > > [STDOUT] > [0.002s][trace][os,container] OSContainer::init: Initializing Container Support > [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. > [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test. > [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test. > > Before the fix, the current path adjustment scheme would produce the following order: > > /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test > /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370 > /sys/fs/cgroup/memory/docker > /sys/fs/cgroup/memory > > Only the last path is valid in the conta... > @sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code: > > https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77 The code fragment you mentioned is executed under condition at line 62, that is, `_root` and `cgroup_path` are not equal. This happens exactly when a process PID is written to `cgroup.procs` file in the directory, belonging to a certain control group G, i.e. the process PID is moved to the control group G. Now that we have `_root` and `cgroup_path` non-equal, such as in my response [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436), i.e. _root: /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c cgroup_path: /system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c the loop at lines 67-77 is determining the "subgroup" part of the above `cgroup_path` , producing the debug message at line 73. The above case is CloudFoundry specific, while in the default docker setup it will be _root: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370 cgroup_path: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test In both cases it needs to be determined what (trailing) part of `cgroup_path` is an actual subgroup path, because this is how we find a directory that exists in the container. It's not known whether the subgroup path is /bad/2f57368b-0eda-4e52-64d8-af5c or /garden/bad/2f57368b-0eda-4e52-64d8-af5c and then the cgroup files path is either /sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c or /sys/fs/cgroup/cpu,cpuacct/garden/bad/2f57368b-0eda-4e52-64d8-af5c The docker case is not any different from the CF case. I therefore suggest [this](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436) case is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` as noted previously. Hope this helps. > > That is, some sub-group without a match, but some with one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682721738 From iklam at openjdk.org Tue Feb 25 19:28:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 19:28:06 GMT Subject: RFR: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 16:04:16 GMT, Calvin Cheung wrote: >> Please review this trivial patch. The `has_extra_module_paths` local variable should be initialized to `false`. > > Looks good and trivial. Thanks @calvinccheung @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23780#issuecomment-2683052061 From iklam at openjdk.org Tue Feb 25 19:28:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 19:28:06 GMT Subject: Integrated: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:59:46 GMT, Ioi Lam wrote: > Please review this trivial patch. The `has_extra_module_paths` local variable should be initialized to `false`. This pull request has now been integrated. Changeset: d422abc5 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/d422abc55aa93d8603d29d269dfb3325bd77f34d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8350668: has_extra_module_paths in filemap.cpp may be uninitialized Reviewed-by: ccheung, shade ------------- PR: https://git.openjdk.org/jdk/pull/23780 From ccheung at openjdk.org Tue Feb 25 20:51:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 20:51:54 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:19:52 GMT, David Holmes wrote: > This doesn't look right to me. What if we are in a client-only VM build, or a minimal-VM build? > For minimal-VM build, libjvm.so is located at: jdk/lib/minimal/libjvm.so For zero-VM build, libjvm.so is located at: jdk/lib/zero/libjvm.so For client-only VM build, I think it should be located under the "client" directory, e.g. on Windows: jdk/bin/client/jvm.dll > I'm not even sure hotspot/libjvm.so is meant to be a filesystem path because it doesn't exist in the filesystem image. ?? The "hotspot" directory maybe a leftover from some old JDK releases? More details: the `init_vm()` in gtestMain.cpp set the following property before creating a JVM: -Dsun.java.launcher.is_altjvm=true `CDSConfig::default_archive_path()` calls `os::jvm_path()` to locate the default CDS archive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683251639 From pchilanomate at openjdk.org Tue Feb 25 21:15:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 25 Feb 2025 21:15:58 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> Message-ID: <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2xYQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> On Tue, 25 Feb 2025 10:54:14 GMT, Serguei Spitsyn wrote: >>> But note this same issue can happen with other events, the test is just checking for single step. >> >> Does that mean we need the suspension check (and suspend) at other locations? >> >> I am looking at `JRT_ENTRY` and it uses `ThreadInVMfromJava` - so why are we not checking for suspension in that transition somewhere, or else somewhere directly in the JRT_ENTRY? I guess maybe not all JRT_ENTRY points are safe for suspension? But then how do we know all the callers of `get_jvmti_thread_state` are safe for suspension? > >> What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack. > > As Patricio pointed out (thanks, Patricio), with this particular test `GetStackTraceSuspendedStressTest.java` the `JvmtiExport::get_jvmti_thread_state` is called from `JvmtiExport::at_single_stepping_point()` which is called from `InterpreterRuntime::at_safepoint()`. There are no other points before to place the `ThreadBlockInVM`. It can be different for other events. > > As an experiment I've added the following assert at the beginning of the `JvmtiExport::get_jvmti_thread_state()` and ran the mach5 tiers 1-6: > > + assert(!thread->owns_locks(), "all locks must be released before suspension"); > > and got many failures of the following tests: > > applications/renaissance/RenaissanceStressTest.java > applications/runthese/RunThese30M.java > applications/skynet/SkyNet.java > serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java > vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java > > > The assert was only triggered in the context of `post_dynamic_code_generated_while_holding_locks()` which make a direct call to `JvmtiExport::get_jvmti_thread_state()`. > > A typical stack trace is: > > Current thread (0x00007ff468008290): JavaThread "ForkJoinPool-1-worker-4" daemon [_thread_in_vm, id=437394, stack(0x00007ff4eb6ea000,0x00007ff4eb7ea000) (1024K)] > > Stack: [0x00007ff4eb6ea000,0x00007ff4eb7ea000], sp=0x00007ff4eb7e5190, free space=1004k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1223114] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x94 (jvmtiExport.cpp:423) > V [libjvm.so+0x122628c] JvmtiExport::post_dynamic_code_generated_while_holding_locks(char const*, unsigned char*, unsigned char*)+0x3c (jvmtiExport.cpp:2636) > V [libjvm.so+0x19ad47e] VtableStubs::find_stub(bool, int)+0x1ce (vtableStubs.cpp:238) > V [libjvm.so+0xa81b0b] CompiledIC::set_to_megamorphic(CallInfo*)+0x4b (vtableStubs.hpp:107) > V [libjvm.so+0x17005a4] SharedRuntime::handle_ic_miss_helper(JavaThread*)+0x2d4 (sharedRuntime.cpp:1637) > V [libjvm.so+0x1700a08] SharedRuntime::handle_wrong_method_ic_miss(JavaThread*)+0xf8 (sharedRuntime.cpp:1441) > v ~RuntimeStub::Shared Runtime ic_miss_blob 0x00007ff50be5f449 > J 378 c1 java.util.concurrent.ForkJoinPool$WorkQueue.top... > Does that mean we need the suspension check (and suspend) at other locations? > Yes, basically before posting any event. That?s why Serguei moved the check to `JvmtiExport::get_jvmti_thread_state()` to cover other events too. But I agree this method should not have side-effects. Also I don't see it is used for all events. I think we should probably use a new method. > I am looking at JRT_ENTRY and it uses ThreadInVMfromJava - so why are we not checking for suspension in that transition somewhere, or else somewhere directly in the JRT_ENTRY? I guess maybe not all JRT_ENTRY points are safe for suspension? But then how do we know all the callers of get_jvmti_thread_state are safe for suspension? > We are checking for suspension in ~ThreadInVMfromJava(), the problem is that the check there is too late, and we have already posted the event. The fix aims to prevent the case where we suspend a thread, then we enable an event, and then the suspended thread posts that new enabled event without being resumed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1970548765 From jbechberger at openjdk.org Tue Feb 25 21:22:51 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 25 Feb 2025 21:22:51 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:20:50 GMT, Martin Doerr wrote: > There are efforts to read the stack at a safepoint. @parttimenerd: Would it make sense to wait for that? Probably not, as the problems will still exists with external profilers like async-profiler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2683319183 From dholmes at openjdk.org Tue Feb 25 21:33:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 21:33:51 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 We have never had a "hotspot" directory. I was under the impression this was a path used for jrt-fs not the actual on-disk filesystem, for which we should end up in the other part of the code. I think this is a bug in the altjvm handling. Would be interesting to see what this code did pre-modules. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683341057 From dholmes at openjdk.org Tue Feb 25 21:48:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 21:48:52 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 Actually this is historical but not related to actual image on disk: + // The next steps are taken in the product version: + // + // Obtain the JAVA_HOME value from the location of libjvm[_g].so. + // This library should be located at: + // /jre/lib//{client|server}/libjvm[_g].so. + // + // If "/jre/lib/" appears at the right place in the path, then we + // assume libjvm[_g].so is installed in a JDK and we use this path. + // + // Otherwise exit with message: "Could not create the Java virtual machine." + // + // The following extra steps are taken in the debugging version: + // + // If "/jre/lib/" does NOT appear at the right place in the path + // instead of exit check for $JAVA_HOME environment variable. + // + // If it is defined and we are able to locate $JAVA_HOME/jre/lib/, + // then we append a fake suffix "hotspot/libjvm[_g].so" to this path so + // it looks like libjvm[_g].so is installed there + // /jre/lib//hotspot/libjvm[_g].so. + // + // Otherwise exit. It was a "fake" path though I have no idea how it was supposed to be used. I think the current code may be a misunderstanding of the original, but it still has: + if (Arguments::sun_java_launcher_is_altjvm()) { + // Support for the java launcher's '-XXaltjvm=' option. Typical + // value for buf is "/jre/lib///libjvm.so". + // If "/jre/lib/" appears at the right place in the string, then + // assume we are installed in a JDK and we're done. Otherwise, check + // for a JAVA_HOME environment variable and fix up the path so it + // looks like libjvm.so is installed there (append a fake suffix + // hotspot/libjvm.so). This use of a fake path makes absolutely no sense to me, and I don't know how it is supposed to work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683368289 From dholmes at openjdk.org Tue Feb 25 22:01:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 25 Feb 2025 22:01:58 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 21:30:46 GMT, David Holmes wrote: > We have never had a "hotspot" directory. This code is really, really ancient. It pertains to when you could select `-hotspot` or `-classic` on the Windows VM, which was then copied across to solaris code and then to linux port. Maybe gtest should not be using -XXaltjvm? That evolved from the old gamma launcher, but it is not at all clear how it is supposed to work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683388967 From coleenp at openjdk.org Tue Feb 25 22:56:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 25 Feb 2025 22:56:53 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 -XXaltjvm=X should find libjvm.so in $JAVA_HOME/{lib,bin}/X/libjvm.so Where the minimal build is this: -XXaltjvm=minimal I thought that's how it used to work. I'm surprised this code still exists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683474649 From coleenp at openjdk.org Tue Feb 25 23:16:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 25 Feb 2025 23:16:52 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 src/hotspot/os/aix/os_aix.cpp line 1356: > 1354: // Use current module name "libjvm.so" > 1355: len = strlen(buf); > 1356: snprintf(buf + len, buflen-len, "/server/libjvm.so"); Still no idea what this is supposed to do but there's a comment above at 1317 that should be fixed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1970672190 From ccheung at openjdk.org Tue Feb 25 23:18:06 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 23:18:06 GMT Subject: RFR: 8350666: cmp-baseline builds fail after JDK-8280682 Message-ID: A fix for initializing the `_timestamp` field in `AOTClassLocation` properly so that the cmp-baseline builds are successful. Sanity tested with builds-tier5. ------------- Commit messages: - 8350666: cmp-baseline builds fail after JDK-8280682 Changes: https://git.openjdk.org/jdk/pull/23787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350666 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23787/head:pull/23787 PR: https://git.openjdk.org/jdk/pull/23787 From iklam at openjdk.org Tue Feb 25 23:18:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 23:18:06 GMT Subject: RFR: 8350666: cmp-baseline builds fail after JDK-8280682 In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 23:08:39 GMT, Calvin Cheung wrote: > A fix for initializing the `_timestamp` field in `AOTClassLocation` properly so that the cmp-baseline builds are successful. > > Sanity tested with builds-tier5. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23787#pullrequestreview-2642673688 From iklam at openjdk.org Tue Feb 25 23:42:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 25 Feb 2025 23:42:01 GMT Subject: RFR: 8350666: cmp-baseline builds fail after JDK-8280682 In-Reply-To: References: Message-ID: <8wi1zR2W0Tm6AU4IOKnA0vlMTObBDOyq6pFyMyCSKdI=.ff160e40-bd35-4210-8cfa-dca327d91ac7@github.com> On Tue, 25 Feb 2025 23:08:39 GMT, Calvin Cheung wrote: > A fix for initializing the `_timestamp` field in `AOTClassLocation` properly so that the cmp-baseline builds are successful. > > Sanity tested with builds-tier5. BTW I think this qualifies as a trivial fix. It reverts back to the same behavior before JDK-8280682. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23787#issuecomment-2683533424 From ccheung at openjdk.org Tue Feb 25 23:48:01 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 23:48:01 GMT Subject: RFR: 8350666: cmp-baseline builds fail after JDK-8280682 In-Reply-To: <8wi1zR2W0Tm6AU4IOKnA0vlMTObBDOyq6pFyMyCSKdI=.ff160e40-bd35-4210-8cfa-dca327d91ac7@github.com> References: <8wi1zR2W0Tm6AU4IOKnA0vlMTObBDOyq6pFyMyCSKdI=.ff160e40-bd35-4210-8cfa-dca327d91ac7@github.com> Message-ID: On Tue, 25 Feb 2025 23:39:15 GMT, Ioi Lam wrote: >> A fix for initializing the `_timestamp` field in `AOTClassLocation` properly so that the cmp-baseline builds are successful. >> >> Sanity tested with builds-tier5. > > BTW I think this qualifies as a trivial fix. It reverts back to the same behavior before JDK-8280682. Thanks @iklam for the quick review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23787#issuecomment-2683539991 From ccheung at openjdk.org Tue Feb 25 23:52:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 25 Feb 2025 23:52:55 GMT Subject: Integrated: 8350666: cmp-baseline builds fail after JDK-8280682 In-Reply-To: References: Message-ID: <3bY8j4pCx6zCFZuEW6apXp0sT_xaRhIKH0Z-1w4ICZE=.fd03f995-15ad-4bab-bae4-d681c88c083b@github.com> On Tue, 25 Feb 2025 23:08:39 GMT, Calvin Cheung wrote: > A fix for initializing the `_timestamp` field in `AOTClassLocation` properly so that the cmp-baseline builds are successful. > > Sanity tested with builds-tier5. This pull request has now been integrated. Changeset: 037e4711 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/037e47112bdf2fa2324f7c58198f6d433f17d9fd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8350666: cmp-baseline builds fail after JDK-8280682 Reviewed-by: iklam ------------- PR: https://git.openjdk.org/jdk/pull/23787 From dholmes at openjdk.org Wed Feb 26 00:19:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 00:19:52 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 I remain baffled by what the logic in `os::jvm_path` is trying to do for the altjvm case. It is almost like it sets up the dummy hotspot/libjvm.so so that "hotspot" can later be replaced by the actual altjvm value - because os::jvm_path has no idea what that is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683579096 From dholmes at openjdk.org Wed Feb 26 00:47:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 00:47:57 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 So basic problem is that `os::jvm_path` was meant to be used in a very specific way, not as a general "give me the filesystem path to the jvm" - even though it usually does just that. So CDS use of this method reflects an incomplete understanding of what it does. It works fine until the altjvm property is set but then gives this unexpected lib/hotspot/libjvm.so path. IIUC when running gtests the gtestlauncher is co-located in the same directory as its custom libjvm.so file. So the launcher knows how to load that custom libjvm. The launcher is pointed to a real JDK so that everything else works as expected. The gtest launcher sets the altjvm property but I don't understand why it does that - we are using a custom libjvm.so but we are also using a custom launcher, so this is not the scenario for which `-XXaltjvm=xxx` was designed. AFAICS the is_altjvm property is only used by this `os::jvm_path` logic, so perhaps the solution is to simply not set that property for the gtestlauncher? Otherwise for CDS to work it needs to locate the classes.jsa in the real JDK that the gtestlauncher was told to use. So maybe a solution there is for the gtestlauncher to explicitly set the path to the CDS archive using the value of the JDK it is given. It will still have to know about the jvm-type (server, client etc). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683612195 From schernyshev at openjdk.org Wed Feb 26 00:52:41 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 26 Feb 2025 00:52:41 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: References: Message-ID: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: updated comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/3568c138..c9391dd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14-15 Stats: 42 lines in 1 file changed: 40 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Wed Feb 26 00:52:41 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 26 Feb 2025 00:52:41 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v15] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 17:11:30 GMT, Severin Gehwolf wrote: >>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly? >> >> Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means. > > A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch. > > Example: > > Sets the subsystem path for a controller. The common container case is > handled by XXX. When a process has been moved from a cgroup to another > the following happens: > - A > - B > - C > > > I believe this is desperately needed. Please see the updated comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970739677 From iklam at openjdk.org Wed Feb 26 01:11:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Feb 2025 01:11:02 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 For a short-term fix, I think we can take this code from os_bsd.cpp and move it into os.hpp: // JVM variant #if defined(ZERO) #define JVM_VARIANT "zero" #elif defined(COMPILER2) #define JVM_VARIANT "server" #else #define JVM_VARIANT "client" #endif Then we can do `snprintf(buf + len, buflen-len, "/%s/libjvm.so", JVM_VARIANT);` instead of hard-coding "hotspot". It's no worse than before and solves the immediate problem. Next, we should completely get rid of `os::jvm_path()`. This API has lots of legacy that we no longer support. It is convoluted and is getting misused. For example, for `Disassembler::load_library()` to find the hsdis dll, but why do we need to put hsdis.so inside `/lib//`? It should just be placed in the same directory as libjava.so. I.e., `$JAVA_HOME/lib`. https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/src/hotspot/share/compiler/disassembler.cpp#L811-L812 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683642786 From dholmes at openjdk.org Wed Feb 26 01:18:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 01:18:58 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 That presumes you are dealing with a single variant JDK, not one that has both client and server. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683651781 From dholmes at openjdk.org Wed Feb 26 02:03:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 02:03:57 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v22] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 11:12:38 GMT, Johan Sj?len wrote: >> Hi, >> >> In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. >> >> This PR does a much smaller change by only focusing on implementing the actual stalling. >> >> The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: >> >> >> $ java -Xlog:async:drop # Dropping mode, same as today >> $ java -Xlog:async:stall # Stalling mode! >> $ java -Xlog:async # Dropping mode by default still >> >> >> The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. >> >> We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. >> >> In pseudo-code we have something like this in the stalling case. >> >> >> void produce() { >> OuterLock olock; >> InnerLock ilock; >> bool out_of_memory = attempt_produce(shared_buffer); >> if (out_of_memory) { >> pmsg = new Message(); >> shared_message = pmsg; >> while (shared_message != nullptr) ilock.wait(); >> free(pmsg); >> } >> } >> >> void consume() { >> InnerLock ilock; >> consume(shared_buffer); >> if (shared_message != nullptr) { >> consume(shared_message); >> ilock.notify(); >> } >> } >> >> >> *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. >> >> *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circu... > > Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: > > - Fix > - Update markdown file > - Increase Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22770#pullrequestreview-2642843229 From dholmes at openjdk.org Wed Feb 26 02:03:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 02:03:58 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Tue, 25 Feb 2025 11:14:59 GMT, Johan Sj?len wrote: >> src/hotspot/share/logging/logConfiguration.cpp line 639: >> >>> 637: >>> 638: out->print_cr("Asynchronous logging (off by default):"); >>> 639: out->print_cr(" -Xlog:async[:[mode]]"); >> >> This reminded me we need an update to the Java manpage/command-reference as well. > > Fixed! See picture for a render. > > ![image](https://github.com/user-attachments/assets/105ff56a-d79e-49ee-bc91-89733af5b1b0) Is that html rendering or a markdown viewer? If the latter just double-check the html to ensure no additional escaping is needed. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1970786101 From iklam at openjdk.org Wed Feb 26 02:42:05 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Feb 2025 02:42:05 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: <8dRbdXAwgJS3apUosd8gJH5_KFI3-eizLMpxlDMFKIc=.e6139f1e-c34b-4b38-8639-f9c70ba854e9@github.com> On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 An alternative suggestion: Instead of finding the default archive in the same directory as `os::jvm_path()`, which is wrong when using gtestLauncher https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/src/hotspot/share/cds/cdsConfig.cpp#L90-L97 We should find it from `Arguments::get_java_home()`: stringStream tmp; const char* subdir = WINDOWS_ONLY("bin") NOT_WINDOWS("lib"); tmp.print("%s%s%s%s%sclasses", Arguments::get_java_home(), os::file_separator(), subdir, JVM_VARIANT, os::file_separator()); We need to modify make/hotspot/lib/JvmFeatures.gmk to add this at the top of the file: JVM_CFLAGS_FEATURES += -DJVM_VARIANT="$(JVM_VARIANT)" Note: the location of the default CDS archives are decided here: https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/make/Images.gmk#L150-L154 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2683749734 From dholmes at openjdk.org Wed Feb 26 02:52:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 02:52:55 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2xYQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Tue, 25 Feb 2025 21:13:14 GMT, Patricio Chilano Mateo wrote: > We are checking for suspension in ~ThreadInVMfromJava(), the problem is that the check there is too late, Okay but why are we not checking in the initial transition from Java, or elsewhere in the JRT_ENTRY? It just seems to me this is a general problem but we only happened to have tripped over one case of it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1970821413 From dholmes at openjdk.org Wed Feb 26 04:37:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 04:37:56 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: On Tue, 25 Feb 2025 15:58:36 GMT, Matthias Baesken wrote: > The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. src/hotspot/os/aix/os_aix.cpp line 800: > 798: > 799: // child thread synchronization is not done here on AIX, a thread is started in suspended state > 800: It is interesting that on Windows, where we also start threads suspended, we also do: // Thread state now is INITIALIZED, not SUSPENDED osthread->set_state(INITIALIZED); then we have: // The thread is returned suspended (in state INITIALIZED), and is started higher up in the call chain return true; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23779#discussion_r1970891998 From dholmes at openjdk.org Wed Feb 26 04:43:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 04:43:52 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: On Wed, 26 Feb 2025 04:34:54 GMT, David Holmes wrote: >> The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. > > src/hotspot/os/aix/os_aix.cpp line 800: > >> 798: >> 799: // child thread synchronization is not done here on AIX, a thread is started in suspended state >> 800: > > It is interesting that on Windows, where we also start threads suspended, we also do: > > // Thread state now is INITIALIZED, not SUSPENDED > osthread->set_state(INITIALIZED); > > then we have: > > // The thread is returned suspended (in state INITIALIZED), and is started higher up in the call chain > return true; But I see now that states ALLOCATED and INITIALIZED are really only needed for the parent/child handshake. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23779#discussion_r1970896138 From dholmes at openjdk.org Wed Feb 26 05:14:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 05:14:57 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v3] In-Reply-To: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> References: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> Message-ID: On Tue, 25 Feb 2025 17:03:42 GMT, Xiaolong Peng wrote: >> Hi there, >> Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). >> >> Current safepoint log is like: >> >> [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms >> [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns >> >> >> >> The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. >> >> As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". >> >> With the new "Leaving safepoint" counter, the log will be like: >> >> [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms >> [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns >> >> >> ### Tests >> - [x] Verified the new safepoint log >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Renames This refinement of the logging information seems reasonable to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23756#pullrequestreview-2643089733 From kbarrett at openjdk.org Wed Feb 26 05:47:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 26 Feb 2025 05:47:52 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 02:33:23 GMT, David Holmes wrote: > Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: > > Before: 532377 ns > After: 361178 ns > > which is 32% improvement. > > Testing: > - tiers 1-3 sanity > > Thanks Changes requested by kbarrett (Reviewer). src/hotspot/share/runtime/threadSMR.cpp line 369: > 367: }; > 368: > 369: #ifdef DEBUG Shouldn't that be s/DEBUG/ASSERT/ ? And similarly for the use. ------------- PR Review: https://git.openjdk.org/jdk/pull/23762#pullrequestreview-2643133440 PR Review Comment: https://git.openjdk.org/jdk/pull/23762#discussion_r1970942114 From ktakakuri at openjdk.org Wed Feb 26 07:07:38 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Wed, 26 Feb 2025 07:07:38 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v3] In-Reply-To: References: Message-ID: <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com> > To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. > I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. > After this fix, I verified that the test passed. > > https://github.com/openjdk/jdk/pull/22142 > I refer to this fix. > tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. > > Thanks. Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23536/files - new: https://git.openjdk.org/jdk/pull/23536/files/b18bbdac..890f0135 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23536/head:pull/23536 PR: https://git.openjdk.org/jdk/pull/23536 From dholmes at openjdk.org Wed Feb 26 07:12:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 07:12:17 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: > Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: > > Before: 532377 ns > After: 361178 ns > > which is 32% improvement. > > Testing: > - tiers 1-3 sanity > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Change DEBUG to ASSERT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23762/files - new: https://git.openjdk.org/jdk/pull/23762/files/2411daa6..e38b45ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23762&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23762&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23762/head:pull/23762 PR: https://git.openjdk.org/jdk/pull/23762 From dholmes at openjdk.org Wed Feb 26 07:12:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 07:12:17 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 05:44:07 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Change DEBUG to ASSERT > > src/hotspot/share/runtime/threadSMR.cpp line 369: > >> 367: }; >> 368: >> 369: #ifdef DEBUG > > Shouldn't that be s/DEBUG/ASSERT/ ? And similarly for the use. Ugghh! Thanks Kim. Yes a mental slip after initially using DEBUG_ONLY. I guess we will never fix that inconsistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23762#discussion_r1971047083 From ktakakuri at openjdk.org Wed Feb 26 07:23:00 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Wed, 26 Feb 2025 07:23:00 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> References: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> Message-ID: <-oPuqNqnVOghYuQjha76l7RIJZduJes2KvtyQHXWVEM=.1e6d7bd1-0d1a-402f-9d7f-c4a250122ed9@github.com> On Wed, 12 Feb 2025 02:34:11 GMT, David Holmes wrote: >> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: >> >> 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform > > test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 66: > >> 64: >> 65: List command = new ArrayList<>(); >> 66: //Execution command to prevent garbled characters > > Suggestion: > > // Force language to English before running systeminfo to get the OS version I fixed it. > test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 69: > >> 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); >> 68: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); >> 69: //Execute command to obtain OS Version > > Suggestion: I fixed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1971061865 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1971062120 From duke at openjdk.org Wed Feb 26 07:25:04 2025 From: duke at openjdk.org (Nicole Xu) Date: Wed, 26 Feb 2025 07:25:04 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. > > Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. Hi @cushon , I've prepared a rollback patch for your recent changes due to some balancing considerations. Could you please review and verify that? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2684145693 From ktakakuri at openjdk.org Wed Feb 26 07:29:54 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Wed, 26 Feb 2025 07:29:54 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> References: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> Message-ID: On Wed, 12 Feb 2025 02:38:02 GMT, David Holmes wrote: >> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: >> >> 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform > > test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 68: > >> 66: //Execution command to prevent garbled characters >> 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); >> 68: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); > > I see the use of `chcp` in the test `./tools/jpackage/helpers/jdk/jpackage/test/Executor.java` so that is okay. However it doesn't set the path and it does not seem necessary to do so, and potentially assumes what the paths are anyway. So I think you can simplify this a little. As well as tools/jpackage/windows/Win8301247Test.java, the tools tests is not included in jdk/tier1, so it will not run in GHA? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1971069041 From rrich at openjdk.org Wed Feb 26 08:04:53 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 26 Feb 2025 08:04:53 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:20:50 GMT, Martin Doerr wrote: > > Can this also happen on other platforms when in signal handling (e.g. segfault based nullchecks?) > > I guess such problems can happen on all platforms which use some kind of link register (aarch64, s390, ?). The actual issue here is that an attempt to walk native stack frames fails and we don't recognize that the stack is not walkable for our stackwalking code. The concrete problem is (likely) that caller pc was not yet stored to the stack. This specific problem cannot occur on x86 (caller pc passed on stack) but also there pushing a new frame isn't atomic and there are states where our stackwalking code can crash I'm sure. >I also don't like that we lose so many samples with this current solution. I only approved it because I think it is better than crashing. > Recognizing that a signal handler is on stack may be a better solution. This would avoid this specific type of crash. Attempts to walk native frames until the top java frame is found can fail, though, in similar ways. That's what I meant referring to ffi calls in the pr description. > Do we already have functionality for that? There are efforts to read the stack at a safepoint. @parttimenerd: Would it make sense to wait for that? With that enhancement we would capture the top java frame (sp, pc) in the signal handler too and then do the stack walk at the safepoint. Finding the top java frame is the purpose of [find_initial_Java_frame](https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/src/hotspot/share/prims/forte.cpp#L271) but it crashes and would also crash with the walk of java frames delayed to the next safepoint. It would only help if we would use the java frame (sp, pc) we find on top at the safepoint but doing so you loose precision, e.g. if you where in an critical ffi call when the thread was interrupted then you would loose this information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2684215884 From tschatzl at openjdk.org Wed Feb 26 08:22:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 26 Feb 2025 08:22:51 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 07:12:17 GMT, David Holmes wrote: >> Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: >> >> Before: 532377 ns >> After: 361178 ns >> >> which is 32% improvement. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Change DEBUG to ASSERT Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23762#pullrequestreview-2643537163 From kbarrett at openjdk.org Wed Feb 26 08:57:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 26 Feb 2025 08:57:54 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 07:12:17 GMT, David Holmes wrote: >> Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: >> >> Before: 532377 ns >> After: 361178 ns >> >> which is 32% improvement. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Change DEBUG to ASSERT Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23762#pullrequestreview-2643647203 From shade at openjdk.org Wed Feb 26 09:21:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 26 Feb 2025 09:21:01 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 07:12:17 GMT, David Holmes wrote: >> Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: >> >> Before: 532377 ns >> After: 361178 ns >> >> which is 32% improvement. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Change DEBUG to ASSERT Wow, this is great! Change looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23762#pullrequestreview-2643724883 From rrich at openjdk.org Wed Feb 26 09:22:58 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 26 Feb 2025 09:22:58 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 08:02:11 GMT, Richard Reingruber wrote: > I also don't like that we lose so many samples with this current solution. That worries me too (see pr descr.). It might be possible to handle this situation better in `frame::safe_for_sender` if we only make sure that the sender pc is not null. I was worried about the case where sender pc is random but within the code cache. This seems to be handled though in `find_initial_Java_frame`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2684386046 From stuefe at openjdk.org Wed Feb 26 09:31:53 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Feb 2025 09:31:53 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 09:20:49 GMT, Richard Reingruber wrote: >>> > Can this also happen on other platforms when in signal handling (e.g. segfault based nullchecks?) >>> >>> I guess such problems can happen on all platforms which use some kind of link register (aarch64, s390, ?). >> >> The actual issue here is that an attempt to walk native stack frames fails and we don't recognize that the stack is not walkable for our stackwalking code. The concrete problem is (likely) that caller pc was not yet stored to the stack. This specific problem cannot occur on x86 (caller pc passed on stack) but also there pushing a new frame isn't atomic and there are states where our stackwalking code can crash I'm sure. >> >>>I also don't like that we lose so many samples with this current solution. I only approved it because I think it is better than crashing. >>> Recognizing that a signal handler is on stack may be a better solution. >> >> This would avoid this specific type of crash. >> Attempts to walk native frames until the top java frame is found can fail, though, in similar ways. >> That's what I meant referring to ffi calls in the pr description. >> >>> Do we already have functionality for that? There are efforts to read the stack at a safepoint. @parttimenerd: Would it make sense to wait for that? >> >> With that enhancement we would capture the top java frame (sp, pc) in the signal handler too and then do the stack walk at the safepoint. Finding the top java frame is the purpose of [find_initial_Java_frame](https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/src/hotspot/share/prims/forte.cpp#L271) but it crashes and would also crash with the walk of java frames delayed to the next safepoint. >> It would only help if we would use the java frame (sp, pc) we find on top at the safepoint but doing so you loose precision, e.g. if you where in an critical ffi call when the thread was interrupted then you would loose this information. > >> I also don't like that we lose so many samples with this current solution. > > That worries me too (see pr descr.). > It might be possible to handle this situation better in `frame::safe_for_sender` if we only make sure that the sender pc is not null. > I was worried about the case where sender pc is random but within the code cache. This seems to be handled though in `find_initial_Java_frame`. @reinrich @TheRealMDoerr Thank you for the explanations. > Recognizing that a signal handler is on stack may be a better solution. I think the SIGTRAP handler should block SIGPROF or SIGVTALARM (whatever 26 is on linux ppc). This should be possible since SIGPROF is asynchronous. And if we enter the SIGTRAP jvm handler via the normal path (JVM gets SIGTRAP), this is already done. All signals that are not synchronous error signals are blocked, which should include SIGPROF. However, if we enter the signal handling via chaining (in this case, via async_profiler::trap_handler), nothing is blocked. At least I don't see any setup for it. The simple solution could be to just block SIGPROF for the current thread when entering the JVM signal handler. A better fix would be for async profiler to block SIGPROF in its trap handler (when setting up the sigaction). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2684407552 From jkern at openjdk.org Wed Feb 26 10:31:57 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 26 Feb 2025 10:31:57 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: On Tue, 25 Feb 2025 15:58:36 GMT, Matthias Baesken wrote: > The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. LGTM ------------- Marked as reviewed by jkern (Committer). PR Review: https://git.openjdk.org/jdk/pull/23779#pullrequestreview-2643964881 From jsjolen at openjdk.org Wed Feb 26 10:54:08 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 10:54:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <1BsBLyqT4rLpUQTF_ganIYfb8ZyfT5DAf0eJcx8XJes=.e700c4ed-9a34-462f-a143-b352056781d3@github.com> On Tue, 25 Feb 2025 15:40:54 GMT, Gerard Ziemski wrote: > How would I go about verifying the performance gain? You mentioned previously that you wrote a microbenchmark for testing this? Hi, The performance gain Afshin mentions is from comparing SLL and Treap, so it's pretty clear from the get-go that Treap will be faster. Those micros are deleted from the source now, you can find them most easily by going through Afshin's last commits and finding where they were deleted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2684608778 From rrich at openjdk.org Wed Feb 26 10:57:31 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 26 Feb 2025 10:57:31 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v2] In-Reply-To: References: Message-ID: <0l-_Ou-g5D8jlDQbSQk1fJOdBMQYhVvW_7SxshfLhbs=.62eda93a-0498-4c4c-9c4d-4a295c3893e0@github.com> > With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. > > This will prevent crashes as described by the JBS item. > > The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: - A frame isn't safe_for_sender if sender_pc() returns null - Revert first fix This reverts commit c4b81e2dc5a854efde8475d09b33b8f53dde987d. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23641/files - new: https://git.openjdk.org/jdk/pull/23641/files/c4b81e2d..9a2eedc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23641&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23641&range=00-01 Stats: 26 lines in 3 files changed: 9 ins; 12 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23641/head:pull/23641 PR: https://git.openjdk.org/jdk/pull/23641 From rrich at openjdk.org Wed Feb 26 11:04:54 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 26 Feb 2025 11:04:54 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v2] In-Reply-To: <0l-_Ou-g5D8jlDQbSQk1fJOdBMQYhVvW_7SxshfLhbs=.62eda93a-0498-4c4c-9c4d-4a295c3893e0@github.com> References: <0l-_Ou-g5D8jlDQbSQk1fJOdBMQYhVvW_7SxshfLhbs=.62eda93a-0498-4c4c-9c4d-4a295c3893e0@github.com> Message-ID: On Wed, 26 Feb 2025 10:57:31 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: > > - A frame isn't safe_for_sender if sender_pc() returns null > - Revert first fix > > This reverts commit c4b81e2dc5a854efde8475d09b33b8f53dde987d. I've pushed an alternative fix to consider a frame not `safe_for_sender` if its sender pc is null. This of course avoids the assertion given in the bug. As explained in the comment we might find other random values when looking for the sender pc if it hasn't been stored to stack yet. This has to be handled by subsequent consistency checks. Let's see how the nightly testing goes... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2684636597 From kbarrett at openjdk.org Wed Feb 26 12:08:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 26 Feb 2025 12:08:11 GMT Subject: RFR: 8350623: Fix -Wzero-as-null-pointer-constant warnings in nsk native test utilities Message-ID: Please review this trivial change to remove a use of literal zero as a null pointer constant. Testing: mach5 tier1 Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to verify the warnings associated with this code were removed. ------------- Commit messages: - fix nsk native test utils Changes: https://git.openjdk.org/jdk/pull/23797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350623 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23797/head:pull/23797 PR: https://git.openjdk.org/jdk/pull/23797 From kbarrett at openjdk.org Wed Feb 26 12:15:46 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 26 Feb 2025 12:15:46 GMT Subject: RFR: 8350767: Fix -Wzero-as-null-pointer-constant warnings in nsk jni stress tests Message-ID: Please review this change to remove uses of literal zero as a null pointer constant in nsk jni stress tests. Testing: mach5 tier1 Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to verify the warnings associated with this code were removed. ------------- Commit messages: - fix warnings in vmTestbase/nsk/stress/jni Changes: https://git.openjdk.org/jdk/pull/23798/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23798&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350767 Stats: 20 lines in 5 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23798.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23798/head:pull/23798 PR: https://git.openjdk.org/jdk/pull/23798 From cushon at openjdk.org Wed Feb 26 12:16:58 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 26 Feb 2025 12:16:58 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. > > Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted? > Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform. It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with 1ab1c1d53b86228be85aac96fa5d69db39ac6317 backed out and with this change it would fail with: test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release import sun.misc.Unsafe; ^ ... error: warnings found and -Werror specified ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2684789082 From jsjolen at openjdk.org Wed Feb 26 12:34:22 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 12:34:22 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Tue, 25 Feb 2025 11:06:26 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > reviews applied. test/hotspot/gtest/nmt/test_vmatree.cpp line 221: > 219: EXPECT_EQ(-50, diff.tag[NMTUtil::tag_to_index(mtTest)].commit); > 220: } > 221: What's going on with this test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1971504677 From jsjolen at openjdk.org Wed Feb 26 12:36:51 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 12:36:51 GMT Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 10:01:17 GMT, Afshin Zafari wrote: > When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR. > With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR. > > Tests: > linux-x64-debug, gtest:NMT*, runtime/NMT I thought that this was what `use_tag_inplace` did from the start? There's some difference in behavior here that I do not understand. I'd like to see a test introduced which does not pass before, but passes now. ------------- PR Review: https://git.openjdk.org/jdk/pull/23771#pullrequestreview-2644321105 From mbaesken at openjdk.org Wed Feb 26 12:43:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Feb 2025 12:43:55 GMT Subject: RFR: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: <7Pwwfs0APsKGFQI7JW8iUxX7Dd51yIg_w3XbeuGhQkg=.30083fa8-89b2-49f9-85c0-a0aa984c8674@github.com> On Tue, 25 Feb 2025 15:58:36 GMT, Matthias Baesken wrote: > The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23779#issuecomment-2684847023 From mbaesken at openjdk.org Wed Feb 26 12:43:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Feb 2025 12:43:56 GMT Subject: Integrated: 8350667: Remove startThread_lock() and _startThread_lock on AIX In-Reply-To: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> References: <-13o8T8p6x0i4fCUWQHvQ3J63fGqf42lpoWa71KqSbo=.e4c2091d-80ab-440c-b88d-ee48e8a99655@github.com> Message-ID: On Tue, 25 Feb 2025 15:58:36 GMT, Matthias Baesken wrote: > The startThread_lock() and _startThread_lock coding is not used on AIX so it can be removed. This pull request has now been integrated. Changeset: e7d4b360 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/e7d4b360fe27585f1a021fd1d1da1fda7f27a37c Stats: 14 lines in 3 files changed: 2 ins; 11 del; 1 mod 8350667: Remove startThread_lock() and _startThread_lock on AIX Reviewed-by: stuefe, jkern ------------- PR: https://git.openjdk.org/jdk/pull/23779 From jsjolen at openjdk.org Wed Feb 26 12:54:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 12:54:05 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v22] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 11:12:38 GMT, Johan Sj?len wrote: >> Hi, >> >> In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. >> >> This PR does a much smaller change by only focusing on implementing the actual stalling. >> >> The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: >> >> >> $ java -Xlog:async:drop # Dropping mode, same as today >> $ java -Xlog:async:stall # Stalling mode! >> $ java -Xlog:async # Dropping mode by default still >> >> >> The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. >> >> We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. >> >> In pseudo-code we have something like this in the stalling case. >> >> >> void produce() { >> OuterLock olock; >> InnerLock ilock; >> bool out_of_memory = attempt_produce(shared_buffer); >> if (out_of_memory) { >> pmsg = new Message(); >> shared_message = pmsg; >> while (shared_message != nullptr) ilock.wait(); >> free(pmsg); >> } >> } >> >> void consume() { >> InnerLock ilock; >> consume(shared_buffer); >> if (shared_message != nullptr) { >> consume(shared_message); >> ilock.notify(); >> } >> } >> >> >> *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. >> >> *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circu... > > Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: > > - Fix > - Update markdown file > - Increase Thank you for your hard work reviewing this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22770#issuecomment-2684870115 From jsjolen at openjdk.org Wed Feb 26 12:54:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 12:54:05 GMT Subject: RFR: 8323807: Async UL: Add a stalling mode to async UL [v19] In-Reply-To: References: <7ZozTFdpLV9lX4y9g_Pv2_361OiY5Fp0cSi85Sct78I=.437c985c-f7e8-4506-a126-4be1455afb7d@github.com> Message-ID: On Wed, 26 Feb 2025 01:59:44 GMT, David Holmes wrote: >> Fixed! See picture for a render. >> >> ![image](https://github.com/user-attachments/assets/105ff56a-d79e-49ee-bc91-89733af5b1b0) > > Is that html rendering or a markdown viewer? If the latter just double-check the html to ensure no additional escaping is needed. Thanks That's `man` opening the generated man page file from markdown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22770#discussion_r1971531119 From jsjolen at openjdk.org Wed Feb 26 12:54:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 12:54:07 GMT Subject: Integrated: 8323807: Async UL: Add a stalling mode to async UL In-Reply-To: References: Message-ID: <0F8PRuPLMsQyksmUYmssAnW-fnR1tIAogrxIHhV6Ktg=.7a00a670-525f-4431-88c7-88184b0caa87@github.com> On Mon, 16 Dec 2024 17:11:13 GMT, Johan Sj?len wrote: > Hi, > > In January of this year I took a stab at implementing a stalling mode for UL, see link: https://github.com/openjdk/jdk/pull/17757 . I also talked about this feature in the mailing lists and seemed to receive positive feedback. With that PR, I also implemented a circular buffer. This PR didn't go through because 1. The stalling mode was broken 2. The complexity was a bit too large imho. > > This PR does a much smaller change by only focusing on implementing the actual stalling. > > The addition in terms of command line changes are the same as before, you can now specify the mode of your async logging: > > > $ java -Xlog:async:drop # Dropping mode, same as today > $ java -Xlog:async:stall # Stalling mode! > $ java -Xlog:async # Dropping mode by default still > > > The change in protocol is quite simple. If a producer thread `P` cannot fit a message into the buffer, it `malloc`s a message and exposes it via a shared pointer. It blocks all other producer threads from writing into the buffer. At the same time, the consumer thread (`AsyncLogWriter`) will perform all writing. When the consumer thread has emptied the write buffer, it writes the stalled message, notifies `P` and releases all locks. `P` then let's all other producer threads continue. > > We do this by having two locks: `Outer` and `Inner`. In our example above, `P` prevents any other producers from progressing by holding the outer lock, but allows the consumer thread to progress by releasing the inner lock. > > In pseudo-code we have something like this in the stalling case. > > > void produce() { > OuterLock olock; > InnerLock ilock; > bool out_of_memory = attempt_produce(shared_buffer); > if (out_of_memory) { > pmsg = new Message(); > shared_message = pmsg; > while (shared_message != nullptr) ilock.wait(); > free(pmsg); > } > } > > void consume() { > InnerLock ilock; > consume(shared_buffer); > if (shared_message != nullptr) { > consume(shared_message); > ilock.notify(); > } > } > > > *Note!* It is very important that the consumer prints all output found in the buffer before printing the stalled message. This is because logging is output in Program Order. In other words: `print(m0); print(m1);` means that `m0` must appear before `m1` in the log file. > > *Note!* Yes, we do force *all* threads to stall before the original stalled message has been printed. This isn't optimal, but I still have hope that we can switch to a faster circular buffer in the future (actually, I've got that code too). If logs are written to a SSD wi... This pull request has now been integrated. Changeset: ea2c9238 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/ea2c92384927a22dd1e1e8676723c7cc720a128b Stats: 246 lines in 9 files changed: 185 ins; 5 del; 56 mod 8323807: Async UL: Add a stalling mode to async UL Reviewed-by: dholmes, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/22770 From mdoerr at openjdk.org Wed Feb 26 13:22:54 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 26 Feb 2025 13:22:54 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v2] In-Reply-To: <0l-_Ou-g5D8jlDQbSQk1fJOdBMQYhVvW_7SxshfLhbs=.62eda93a-0498-4c4c-9c4d-4a295c3893e0@github.com> References: <0l-_Ou-g5D8jlDQbSQk1fJOdBMQYhVvW_7SxshfLhbs=.62eda93a-0498-4c4c-9c4d-4a295c3893e0@github.com> Message-ID: On Wed, 26 Feb 2025 10:57:31 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: > > - A frame isn't safe_for_sender if sender_pc() returns null > - Revert first fix > > This reverts commit c4b81e2dc5a854efde8475d09b33b8f53dde987d. Thanks! This solution looks much better! src/hotspot/cpu/ppc/frame_ppc.cpp line 200: > 198: if (sender_pc() == nullptr) { > 199: // Likely the return pc was not yet stored to stack. We rather discard this > 200: // sample also because we would hit an assertion in frame::setup(). We can Double-whitespaces seem to be uncommon. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23641#pullrequestreview-2644462134 PR Review Comment: https://git.openjdk.org/jdk/pull/23641#discussion_r1971574689 From azafari at openjdk.org Wed Feb 26 14:05:24 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 26 Feb 2025 14:05:24 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 26 Feb 2025 12:31:39 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> reviews applied. > > test/hotspot/gtest/nmt/test_vmatree.cpp line 221: > >> 219: EXPECT_EQ(-50, diff.tag[NMTUtil::tag_to_index(mtTest)].commit); >> 220: } >> 221: > > What's going on with this test? It checks the `use_tag_inplace` in committing a region, by passing `true` to the last parameter of the `VMATree::commit_mapping`. It is expected that the existing tag from the previous region to be copied to this new region. The mem tag of the `rd2` (`mtNone`) should not be used for the new committed region. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1971643555 From azafari at openjdk.org Wed Feb 26 14:05:25 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 26 Feb 2025 14:05:25 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 26 Feb 2025 14:01:07 GMT, Afshin Zafari wrote: >> test/hotspot/gtest/nmt/test_vmatree.cpp line 221: >> >>> 219: EXPECT_EQ(-50, diff.tag[NMTUtil::tag_to_index(mtTest)].commit); >>> 220: } >>> 221: >> >> What's going on with this test? > > It checks the `use_tag_inplace` in committing a region, by passing `true` to the last parameter of the `VMATree::commit_mapping`. It is expected that the existing tag from the previous region to be copied to this new region. The mem tag of the `rd2` (`mtNone`) should not be used for the new committed region. Also, it is skipped until the corresponding PR get integrated, otherwise it fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1971644873 From rrich at openjdk.org Wed Feb 26 14:06:20 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 26 Feb 2025 14:06:20 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: References: Message-ID: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> > With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. > > This will prevent crashes as described by the JBS item. > > The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23641/files - new: https://git.openjdk.org/jdk/pull/23641/files/9a2eedc5..92b0ef93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23641&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23641&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23641/head:pull/23641 PR: https://git.openjdk.org/jdk/pull/23641 From jsjolen at openjdk.org Wed Feb 26 14:23:15 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 26 Feb 2025 14:23:15 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 26 Feb 2025 14:01:58 GMT, Afshin Zafari wrote: >> It checks the `use_tag_inplace` in committing a region, by passing `true` to the last parameter of the `VMATree::commit_mapping`. It is expected that the existing tag from the previous region to be copied to this new region. The mem tag of the `rd2` (`mtNone`) should not be used for the new committed region. > > Also, it is skipped until the corresponding PR get integrated, otherwise it fails. Then move the test to that PR and enable it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1971676943 From ihse at openjdk.org Wed Feb 26 14:38:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 26 Feb 2025 14:38:52 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 I've been poking around a bit regarding loading of libjvm.so in relation to static builds (where there are no dynamic library to load). A lot of this code is ancient, poorly documented, and one hand does not know what the other does, so stuff is strangely converted from one format to another without any good reason more than "the rest of the chain seems to expect this". I have come to the conclusion that the entire process on how we "bootstrap" java up to the point that we can call `JNI_CreateJavaVM` would benefit from a complete rehaul, where we can see the entire picture at once. Also, > That presumes you are dealing with a single variant JDK, not one that has both client and server. Is this even relevant anymore? Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2685221296 PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2685226308 From jwaters at openjdk.org Wed Feb 26 14:41:55 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 26 Feb 2025 14:41:55 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 14:36:24 GMT, Magnus Ihse Bursie wrote: > Also, > > > That presumes you are dealing with a single variant JDK, not one that has both client and server. > > Is this even relevant anymore? Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed. Don't we still have support for combining every kind of VM (Except Zero) into the resulting JDK or am I mixing it up with something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2685239740 From mdoerr at openjdk.org Wed Feb 26 14:56:05 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 26 Feb 2025 14:56:05 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: <3kNLR01rp2MmgPTMi-qga4_ApVk_oR2DNiky_3bHA1I=.f89d39c3-54ee-42fe-a24b-2fef269b8efc@github.com> On Wed, 26 Feb 2025 14:06:20 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve whitespace Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23641#pullrequestreview-2644793700 From stuefe at openjdk.org Wed Feb 26 15:30:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Feb 2025 15:30:01 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: On Wed, 26 Feb 2025 14:06:20 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve whitespace +1 ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23641#pullrequestreview-2644930039 From gziemski at openjdk.org Wed Feb 26 16:12:14 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 26 Feb 2025 16:12:14 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v3] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 09:36:44 GMT, Johan Sj?len wrote: >> Today NMT has two canaries: A header and a footer canary. These enable mainly two things: >> >> 1. For NMT to aid in describing a pointer >> 2. A basic form of out-of-bounds protection >> >> With the introduction of UBSan and Asan into OpenJDK we have gained stronger tools for this sort of analysis, without requiring NMT to be activated. Therefore, I believe that point 2 is no longer something that NMT needs to support. For point number one, we will unfortunately be losing this ability. >> >> I want to delete these canaries to open up a few free bytes. These can allow us to have "practically unlimited" (4 bytes) of memory tags. >> >> tier1-tier2 tests succeeded. >> >> I am awaiting discussion on the Hotspot-dev mailing list, but keeping this PR open for review. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'openjdk/master' into delete-canaries > - Comment > - Rename flags to tags > - Remove canaries Still LGTM. ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21560#pullrequestreview-2645057290 From gziemski at openjdk.org Wed Feb 26 16:12:14 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 26 Feb 2025 16:12:14 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: References: Message-ID: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> On Mon, 2 Dec 2024 09:23:38 GMT, Thomas Stuefe wrote: > As I said in preparation of this work, I don't oppose it, but I am not happy. > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2685518208 From stuefe at openjdk.org Wed Feb 26 16:51:54 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Feb 2025 16:51:54 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> References: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> Message-ID: On Wed, 26 Feb 2025 16:07:08 GMT, Gerard Ziemski wrote: > > As I said in preparation of this work, I don't oppose it, but I am not happy. > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. Nothing I can share, but I had two customers using Unsafe.AllocateMemory (which atm are the only allocations from outside the JVM that are tracked), and they overwrote the boundaries. Took a while to find this, but the canaries added by NMT (mainly the hex dump outputs) were helpful. I wonder, do we have to completely throw this feature away? Even a single byte as canary would be better than nothing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2685626377 From sspitsyn at openjdk.org Wed Feb 26 17:06:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 26 Feb 2025 17:06:54 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Wed, 26 Feb 2025 02:50:32 GMT, David Holmes wrote: >>> Does that mean we need the suspension check (and suspend) at other locations? >>> >> Yes, basically before posting any event. That?s why Serguei moved the check to `JvmtiExport::get_jvmti_thread_state()` to cover other events too. But I agree this method should not have side-effects. Also I don't see it is used for all events. I think we should probably use a new method. >> >>> I am looking at JRT_ENTRY and it uses ThreadInVMfromJava - so why are we not checking for suspension in that transition somewhere, or else somewhere directly in the JRT_ENTRY? I guess maybe not all JRT_ENTRY points are safe for suspension? But then how do we know all the callers of get_jvmti_thread_state are safe for suspension? >>> >> We are checking for suspension in ~ThreadInVMfromJava(), the problem is that the check there is too late, and we have already posted the event. The fix aims to prevent the case where we suspend a thread, then we enable an event, and then the suspended thread posts that new enabled event without being resumed. > >> We are checking for suspension in ~ThreadInVMfromJava(), the problem is that the check there is too late, > > Okay but why are we not checking in the initial transition from Java, or elsewhere in the JRT_ENTRY? > > It just seems to me this is a general problem but we only happened to have tripped over one case of it. David and Patricio, thank you for raising this concern and discussion. I agree that normal mechanisms like `JRT_ENTRY` or `ThreadInVMfromJava` should provide suspend points before posting the JVMTI events. Let me do some investigation/analysis first. I suspect we might need to provide a suspend point in the `ThreadInVMfromJava` constructor additionally to the one in the destructor even though it looks a little bit strange. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1971994711 From xpeng at openjdk.org Wed Feb 26 17:32:12 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 26 Feb 2025 17:32:12 GMT Subject: RFR: 8350313: Include timings for leaving safepoint in safepoint logging [v3] In-Reply-To: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> References: <5zoshJisPqXseOypm9uP0wWaDCKRLxnVxr4w3wp9vS0=.e02864fb-a7c3-4a3b-bfee-f267a3c45924@github.com> Message-ID: On Tue, 25 Feb 2025 17:03:42 GMT, Xiaolong Peng wrote: >> Hi there, >> Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). >> >> Current safepoint log is like: >> >> [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms >> [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns >> >> >> >> The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. >> >> As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". >> >> With the new "Leaving safepoint" counter, the log will be like: >> >> [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms >> [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns >> >> >> ### Tests >> - [x] Verified the new safepoint log >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Renames Thank you all for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23756#issuecomment-2685731150 From xpeng at openjdk.org Wed Feb 26 17:32:12 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 26 Feb 2025 17:32:12 GMT Subject: Integrated: 8350313: Include timings for leaving safepoint in safepoint logging In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:48:25 GMT, Xiaolong Peng wrote: > Hi there, > Please help with reviewing the PR. The change is to improve the observability of timings of safepoints. We have a production use case where leaving the safepoint introduced a significant latency, mostly due to VMThread getting de-scheduled, more details can be find in JBS bug [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324). > > Current safepoint log is like: > > [3.427s][info][gc ] GC(6) Pause Final Mark (unload classes) 0.201ms > [3.428s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 2463125 ns, Reaching safepoint: 14958 ns, At safepoint: 410834 ns, Total: 425792 ns > > > > The "At safepoint" time include the time to evaluate the VM operation and the time to leave safepoint(cleanup, disarm WaitBarrier..etc.), from safepoint log we don't really know how much time it takes to leave safepoint. > > As proposed in [JDK-8350313](https://bugs.openjdk.org/browse/JDK-8350313), we think a "Leaving safepoint" counter just like "Reaching safepoint" could be nice to have. It comes with the symmetry advantage with "Reaching safepoint" counter. "Leaving safepoint" measures the time spent in safepoint machinery from the "finishing side". And, it more clearly captures the transitional state where some threads might be still at safepoint, and some have already unparked, like "Reaching safepoint". > > With the new "Leaving safepoint" counter, the log will be like: > > [17.764s][info][gc ] GC(84) Pause Final Mark (unload classes) 0.179ms > [17.764s][info][safepoint] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3340792 ns, Reaching safepoint: 31250 ns, At safepoint: 187958 ns, Leaving safepoint: 177833 ns, Total: 397041 ns > > > ### Tests > - [x] Verified the new safepoint log > - [x] Tier 2 This pull request has now been integrated. Changeset: 9ec46968 Author: Xiaolong Peng Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/9ec46968fbfddf99a8349cb6903d24b1c2fdaf1d Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod 8350313: Include timings for leaving safepoint in safepoint logging Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23756 From gziemski at openjdk.org Wed Feb 26 17:33:07 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 26 Feb 2025 17:33:07 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: References: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> Message-ID: On Wed, 26 Feb 2025 16:48:59 GMT, Thomas Stuefe wrote: > > > As I said in preparation of this work, I don't oppose it, but I am not happy. > > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. > > > > > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. > > Nothing I can share, but I had two customers using Unsafe.AllocateMemory (which atm are the only allocations from outside the JVM that are tracked), and they overwrote the boundaries. Took a while to find this, but the canaries added by NMT (mainly the hex dump outputs) were helpful. > > I wonder, do we have to completely throw this feature away? Even a single byte as canary would be better than nothing? Or make the feature optional for those devs, who are willing to pay the price? I would be OK with this being a dynamic, optional feature that can be turned OFF/ON. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2685737613 From ccheung at openjdk.org Wed Feb 26 17:49:01 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 26 Feb 2025 17:49:01 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: <2VnPDHjox3eps6Q16EmqP_3bImZppqOu5XR_IeLjekM=.e4783c88-1161-48a9-90c7-84cbfe1f5473@github.com> On Wed, 26 Feb 2025 00:45:09 GMT, David Holmes wrote: > AFAICS the is_altjvm property is only used by this `os::jvm_path` logic, so perhaps the solution is to simply not set that property for the gtestlauncher? > It didn't work. I got the following error: [----------] 1 test from ThreadsListHandle [ RUN ] ThreadsListHandle.sanity_vm Error occurred during initialization of VM Failed setting boot class path. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2685774325 From ccheung at openjdk.org Wed Feb 26 17:55:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 26 Feb 2025 17:55:57 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: <8dRbdXAwgJS3apUosd8gJH5_KFI3-eizLMpxlDMFKIc=.e6139f1e-c34b-4b38-8639-f9c70ba854e9@github.com> References: <8dRbdXAwgJS3apUosd8gJH5_KFI3-eizLMpxlDMFKIc=.e6139f1e-c34b-4b38-8639-f9c70ba854e9@github.com> Message-ID: <5lTZYmSZGvEea-Jz4F6VLaqrLlkcIfHpP-Rb__wddpU=.41cb6974-1384-496b-8062-a1e084040b23@github.com> On Wed, 26 Feb 2025 02:39:08 GMT, Ioi Lam wrote: > An alternative suggestion: > > Instead of finding the default archive in the same directory as `os::jvm_path()`, which is wrong when using gtestLauncher > > https://github.com/openjdk/jdk/blob/037e47112bdf2fa2324f7c58198f6d433f17d9fd/src/hotspot/share/cds/cdsConfig.cpp#L90-L97 > > We should find it from `Arguments::get_java_home()`: > > ``` > stringStream tmp; > const char* subdir = WINDOWS_ONLY("bin") NOT_WINDOWS("lib"); > tmp.print("%s%s%s%s%sclasses", Arguments::get_java_home(), os::file_separator(), subdir, > JVM_VARIANT, os::file_separator()); > ``` > I like this approach better since the change is contained within CDS code. We probably need to file another but to address the issue in `os::jvm_path()`. I found the following email thread detailing some issues in `os::jvm_path()` https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2017-April/023226.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2685790209 From ccheung at openjdk.org Wed Feb 26 18:02:43 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 26 Feb 2025 18:02:43 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v2] In-Reply-To: References: Message-ID: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: Ioi's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23758/files - new: https://git.openjdk.org/jdk/pull/23758/files/6db007be..2a57876e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=00-01 Stats: 8 lines in 5 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23758/head:pull/23758 PR: https://git.openjdk.org/jdk/pull/23758 From stuefe at openjdk.org Wed Feb 26 19:26:00 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Feb 2025 19:26:00 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: References: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> Message-ID: On Wed, 26 Feb 2025 17:29:56 GMT, Gerard Ziemski wrote: > > > > As I said in preparation of this work, I don't oppose it, but I am not happy. > > > > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > > > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. > > > > > > > > > > > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. > > > > > > Nothing I can share, but I had two customers using Unsafe.AllocateMemory (which atm are the only allocations from outside the JVM that are tracked), and they overwrote the boundaries. Took a while to find this, but the canaries added by NMT (mainly the hex dump outputs) were helpful. > > > > > > I wonder, do we have to completely throw this feature away? Even a single byte as canary would be better than nothing? > > > > Or make the feature optional for those devs, who are willing to pay the price? > > > > I would be OK with this being a dynamic, optional feature that can be turned OFF/ON. > > increases complexity, though. malloc header is 16 byte, we could use eg the most significant byte of the size field. Heck, we could use the topmost four bytes, since probably Nobody ever allocates more than 4g with malloc. But certainly the topmost byte. 56 bit are larger than most addrss spaces. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2685987511 From iklam at openjdk.org Wed Feb 26 19:31:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Feb 2025 19:31:55 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:02:43 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's suggestion src/hotspot/share/cds/cdsConfig.cpp line 96: > 94: const char* subdir = WINDOWS_ONLY("bin") NOT_WINDOWS("lib"); > 95: tmp.print("%s%s%s%s%s%sclasses", Arguments::get_java_home(), os::file_separator(), subdir, > 96: os::file_separator(), JVM_VARIANT, os::file_separator()); I think the above call to os::jvm_path (lines 90-92) can also be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1972255748 From iklam at openjdk.org Wed Feb 26 19:31:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Feb 2025 19:31:55 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v2] In-Reply-To: References: Message-ID: <-KygqR4I0SlfJXaJsYi-IZpTnSnIdTTGeqR6TqwpNSs=.2be71ac1-5358-494e-9a81-81a147534064@github.com> On Wed, 26 Feb 2025 19:27:41 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> Ioi's suggestion > > src/hotspot/share/cds/cdsConfig.cpp line 96: > >> 94: const char* subdir = WINDOWS_ONLY("bin") NOT_WINDOWS("lib"); >> 95: tmp.print("%s%s%s%s%s%sclasses", Arguments::get_java_home(), os::file_separator(), subdir, >> 96: os::file_separator(), JVM_VARIANT, os::file_separator()); > > I think the above call to os::jvm_path (lines 90-92) can also be removed. Also, the definitions of JVM_VARIANT in os_bsd.cpp should be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1972257280 From ccheung at openjdk.org Wed Feb 26 19:50:43 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 26 Feb 2025 19:50:43 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: Message-ID: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @iklam comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23758/files - new: https://git.openjdk.org/jdk/pull/23758/files/2a57876e..4703c943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=01-02 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23758/head:pull/23758 PR: https://git.openjdk.org/jdk/pull/23758 From ccheung at openjdk.org Wed Feb 26 19:50:44 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 26 Feb 2025 19:50:44 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v2] In-Reply-To: <-KygqR4I0SlfJXaJsYi-IZpTnSnIdTTGeqR6TqwpNSs=.2be71ac1-5358-494e-9a81-81a147534064@github.com> References: <-KygqR4I0SlfJXaJsYi-IZpTnSnIdTTGeqR6TqwpNSs=.2be71ac1-5358-494e-9a81-81a147534064@github.com> Message-ID: On Wed, 26 Feb 2025 19:28:51 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/cdsConfig.cpp line 96: >> >>> 94: const char* subdir = WINDOWS_ONLY("bin") NOT_WINDOWS("lib"); >>> 95: tmp.print("%s%s%s%s%s%sclasses", Arguments::get_java_home(), os::file_separator(), subdir, >>> 96: os::file_separator(), JVM_VARIANT, os::file_separator()); >> >> I think the above call to os::jvm_path (lines 90-92) can also be removed. > > Also, the definitions of JVM_VARIANT in os_bsd.cpp should be removed. I've fixed both. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1972287202 From dholmes at openjdk.org Wed Feb 26 20:18:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 20:18:02 GMT Subject: RFR: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 08:54:46 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Change DEBUG to ASSERT > > Looks good. Thanks for the review @kimbarrett , @tschatzl , @shipilev ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23762#issuecomment-2686091586 From dholmes at openjdk.org Wed Feb 26 20:18:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 26 Feb 2025 20:18:03 GMT Subject: Integrated: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 02:33:23 GMT, David Holmes wrote: > Simple cleanup to skip debug code in a non-debug build. This removes some overhead when working with very large numbers of threads. Basic perf testing starting a new thread when 20000 already exist: > > Before: 532377 ns > After: 361178 ns > > which is 32% improvement. > > Testing: > - tiers 1-3 sanity > > Thanks This pull request has now been integrated. Changeset: e43960a0 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e43960a0170bf29b28ff4733e1c8c927947fb0bb Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8350616: Skip ValidateHazardPtrsClosure in non-debug builds Reviewed-by: kbarrett, tschatzl, shade ------------- PR: https://git.openjdk.org/jdk/pull/23762 From apangin at openjdk.org Thu Feb 27 01:55:00 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 27 Feb 2025 01:55:00 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: On Wed, 26 Feb 2025 14:06:20 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve whitespace A couple of comments for the record. Detecting another signal handler on the stack or blocking SIGPROF inside a handler is not a solution: a signal number that profiler uses is configurable; there may be multiple profilers working at the same time or one profiler working in dual mode (cpu + wall clock). In any case, the problem is not specific to signal handlers: it may happen with any frame that does not store frame pointer at a known location. A typical example is `clock_gettime` function called from `System.currentTimeMillis` and `System.nanoTime`. If libc is compiled without frame pointers, JVM fails to unwind `clock_gettime`. Note that `currentTimeMillis` and `nanoTime` are JVM intrinsics: they do not do regular state transition; a thread remains `in_Java` while executing `clock_gettime`. A signal trampoline is just another example of code with uncommon frame layout (not only on PPC). I'm OK with the proposed fix as long as it reduces possibility of crashes, but it's likely not a bullet-proof solution. Any native frame that does not belong to `libjvm.so` is potentially dangerous to walk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2686603796 From duke at openjdk.org Thu Feb 27 03:24:52 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 27 Feb 2025 03:24:52 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. > > Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. > Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted? > > > Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform. > > It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) backed out and with this change it would fail with: > > ``` > test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release > import sun.misc.Unsafe; > ^ > ... > error: warnings found and -Werror specified > ``` Thank you for your comments. I understand your concerns about potential "proprietary API" warnings if we revert to using `sun.misc.Unsafe`. However, this specific microbenchmark is designed for `sun.misc.Unsafe`, not `jdk.internal.misc.Unsafe`. For the "proprietary API" warning, while not passing `-Werror` during the build process for the microbenchmarks could have broad implications, I wonder if we could take a more targeted approach. Would it be possible to exclude just this particular microbenchmark from sunapi diagnostics? @AlanBateman @liach Do you have any comments on that? I'd appreciate your inputs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2686755067 From iklam at openjdk.org Thu Feb 27 03:29:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 27 Feb 2025 03:29:59 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 19:50:43 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2646475181 From liach at openjdk.org Thu Feb 27 04:36:52 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 27 Feb 2025 04:36:52 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 12:13:59 GMT, Liam Miller-Cushon wrote: >> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe >> >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. >> >> Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c >> - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" >> >> This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. > > Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted? > >> Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform. > > It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with 1ab1c1d53b86228be85aac96fa5d69db39ac6317 backed out and with this change it would fail with: > > > test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release > import sun.misc.Unsafe; > ^ > ... > error: warnings found and -Werror specified Hi @cushon, I believe disabling `JAVA_WARNINGS_ARE_ERRORS` should be done as part of those javac patches instead of part of this patch. We cannot verify such an addition in this patch, and it will just cause meaningless extra review and update cycles. This flag is defined at https://github.com/openjdk/jdk/blob/964dd18fd2ba998e5c1efed48e15e516b0c22b19/make/common/JavaCompilation.gmk#L268. Unfortunately I don't know about make well enough to say what's the best way to disable this for micro build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2686877434 From jwaters at openjdk.org Thu Feb 27 05:44:59 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 27 Feb 2025 05:44:59 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: Message-ID: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> On Wed, 26 Feb 2025 19:50:43 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments make/hotspot/lib/JvmFeatures.gmk line 36: > 34: ################################################################################ > 35: > 36: JVM_CFLAGS_FEATURES += -DJVM_VARIANT=\"$(JVM_VARIANT)\" Might it be a better idea to set -DJVM_VARIANT as the CXXFLAGS for cdsConfig.cpp directly instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1972905084 From syan at openjdk.org Thu Feb 27 06:19:03 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 27 Feb 2025 06:19:03 GMT Subject: RFR: 8350665: SIZE_FORMAT_HEX macro undefined in gtest In-Reply-To: <2y0-EvQMcPS4tr2GemihHKdT_mdEil2GJZ3DnlYNoa4=.6313b32c-7de6-48c4-b582-fa36a7b56fa4@github.com> References: <2y0-EvQMcPS4tr2GemihHKdT_mdEil2GJZ3DnlYNoa4=.6313b32c-7de6-48c4-b582-fa36a7b56fa4@github.com> Message-ID: On Tue, 25 Feb 2025 15:52:43 GMT, Thomas Stuefe wrote: >> Hi all, >> >> SIZE_FORMAT_HEX macro undefined in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp. >> The SIZE_FORMAT_HEX macro should be replace as "0x%zx" instead. >> >> Trivial fix, change has been verified locally, test-fix only, no risk. > > ok Thanks @tstuefe @coleenp ------------- PR Comment: https://git.openjdk.org/jdk/pull/23778#issuecomment-2687013162 From syan at openjdk.org Thu Feb 27 06:19:04 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 27 Feb 2025 06:19:04 GMT Subject: Integrated: 8350665: SIZE_FORMAT_HEX macro undefined in gtest In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:37:40 GMT, SendaoYan wrote: > Hi all, > > SIZE_FORMAT_HEX macro undefined in test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp. > The SIZE_FORMAT_HEX macro should be replace as "0x%zx" instead. > > Trivial fix, change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: b29f8b04 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/b29f8b04780bffff2b25acb95f22b4fdf83f3724 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8350665: SIZE_FORMAT_HEX macro undefined in gtest Reviewed-by: coleenp, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/23778 From ccheung at openjdk.org Thu Feb 27 06:57:59 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 27 Feb 2025 06:57:59 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> References: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> Message-ID: On Thu, 27 Feb 2025 05:42:45 GMT, Julian Waters wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @iklam comments > > make/hotspot/lib/JvmFeatures.gmk line 36: > >> 34: ################################################################################ >> 35: >> 36: JVM_CFLAGS_FEATURES += -DJVM_VARIANT=\"$(JVM_VARIANT)\" > > Might it be a better idea to set -DJVM_VARIANT as the CXXFLAGS for cdsConfig.cpp directly instead? Currently, os_bsd.cpp also needs the JVM_VARIANT definition. Later, if we fix the `os::jvm_path()` issues, os_windows.cpp, os_linux.cpp and os_aix.cpp also need JVM_VARIANT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1972978001 From rrich at openjdk.org Thu Feb 27 09:06:54 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 27 Feb 2025 09:06:54 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: On Thu, 27 Feb 2025 01:51:58 GMT, Andrei Pangin wrote: > I'm OK with the proposed fix as long as it reduces possibility of crashes, but it's likely not a bullet-proof solution. Any native frame that does not belong to `libjvm.so` is potentially dangerous to walk. Thanks for your comments, Andrei. I agree. Even frames from `libjvm.so` are dangerous since we might read an incorrect random sender_pc(). The outcome that is just undefined. Tests are good though :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2687322843 From jsjolen at openjdk.org Thu Feb 27 09:23:35 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 09:23:35 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails Message-ID: Hi, When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. ------------- Commit messages: - Fix async test in drop tests - Add check in JTReg - Delete poorly devised test Changes: https://git.openjdk.org/jdk/pull/23819/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350824 Stats: 24 lines in 2 files changed: 5 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23819.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23819/head:pull/23819 PR: https://git.openjdk.org/jdk/pull/23819 From azafari at openjdk.org Thu Feb 27 09:25:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 09:25:13 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: <1BsBLyqT4rLpUQTF_ganIYfb8ZyfT5DAf0eJcx8XJes=.e700c4ed-9a34-462f-a143-b352056781d3@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1BsBLyqT4rLpUQTF_ganIYfb8ZyfT5DAf0eJcx8XJes=.e700c4ed-9a34-462f-a143-b352056781d3@github.com> Message-ID: <0WOvPFaqBDE8Yr8Nvh4IQ3RbRMcPJKk3-LCNyovFybs=.f8dd913d-b99b-40f6-9c9a-f85acfa7f29a@github.com> On Wed, 26 Feb 2025 10:51:11 GMT, Johan Sj?len wrote: > How would I go about verifying the performance gain? You mentioned previously that you wrote a microbenchmark for testing this? There is no performance check for this PR. This PR just use the new VMATree instead of SortedLinkedList for managing the regions. Performance checks and comparisons are left for other future PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2687364436 From rrich at openjdk.org Thu Feb 27 09:26:58 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 27 Feb 2025 09:26:58 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: On Wed, 26 Feb 2025 14:06:20 GMT, Richard Reingruber wrote: >> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. >> >> This will prevent crashes as described by the JBS item. >> >> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. >> >> Testing: >> >> * DaCapo Tomcat with async-profiler on a fastdebug build. >> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve whitespace Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2687366171 From rrich at openjdk.org Thu Feb 27 09:26:59 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 27 Feb 2025 09:26:59 GMT Subject: Integrated: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:11:55 GMT, Richard Reingruber wrote: > With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc. > > This will prevent crashes as described by the JBS item. > > The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame. > > Testing: > > * DaCapo Tomcat with async-profiler on a fastdebug build. > * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX. This pull request has now been integrated. Changeset: e4d3c97c Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/e4d3c97c0f388fc4b1684b78844f2166277ffd91 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP Reviewed-by: mdoerr, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/23641 From jsjolen at openjdk.org Thu Feb 27 09:33:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 09:33:30 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: References: Message-ID: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> > Hi, > > When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. > > Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: bool in C++, boolean in Java, great :-) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23819/files - new: https://git.openjdk.org/jdk/pull/23819/files/269b2261..05792d0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23819&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23819&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23819.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23819/head:pull/23819 PR: https://git.openjdk.org/jdk/pull/23819 From azafari at openjdk.org Thu Feb 27 09:38:12 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 09:38:12 GMT Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region [v2] In-Reply-To: References: Message-ID: > When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR. > With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR. > > Tests: > linux-x64-debug, gtest:NMT*, runtime/NMT Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: - removed extra whitespace. - unit test added. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23771/files - new: https://git.openjdk.org/jdk/pull/23771/files/5d85bb8c..50a75b22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23771&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23771&range=00-01 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23771/head:pull/23771 PR: https://git.openjdk.org/jdk/pull/23771 From azafari at openjdk.org Thu Feb 27 10:37:33 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 10:37:33 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: removed UseFlagInPlace test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/5aa4556a..74e4872d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=30-31 Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Thu Feb 27 10:37:33 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 10:37:33 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 26 Feb 2025 14:20:26 GMT, Johan Sj?len wrote: >> Also, it is skipped until the corresponding PR get integrated, otherwise it fails. > > Then move the test to that PR and enable it? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973311931 From mdoerr at openjdk.org Thu Feb 27 10:38:58 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 27 Feb 2025 10:38:58 GMT Subject: RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v3] In-Reply-To: References: <-O_vbz7zcVvQyZcyr-PdI7f1lx75Vp16EqOINMbFgls=.6ccbf250-1de4-4b1a-9b2b-219988253082@github.com> Message-ID: On Thu, 27 Feb 2025 01:51:58 GMT, Andrei Pangin wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve whitespace > > A couple of comments for the record. > > Detecting another signal handler on the stack or blocking SIGPROF inside a handler is not a solution: a signal number that profiler uses is configurable; there may be multiple profilers working at the same time or one profiler working in dual mode (cpu + wall clock). > > In any case, the problem is not specific to signal handlers: it may happen with any frame that does not store frame pointer at a known location. A typical example is `clock_gettime` function called from `System.currentTimeMillis` and `System.nanoTime`. If libc is compiled without frame pointers, JVM fails to unwind `clock_gettime`. Note that `currentTimeMillis` and `nanoTime` are JVM intrinsics: they do not do regular state transition; a thread remains `in_Java` while executing `clock_gettime`. A signal trampoline is just another example of code with uncommon frame layout (not only on PPC). > > I'm OK with the proposed fix as long as it reduces possibility of crashes, but it's likely not a bullet-proof solution. Any native frame that does not belong to `libjvm.so` is potentially dangerous to walk. @apangin: Thanks for looking at this PR! > In any case, the problem is not specific to signal handlers: it may happen with any frame that does not store frame pointer at a known location. A typical example is clock_gettime function called from System.currentTimeMillis and System.nanoTime. If libc is compiled without frame pointers, JVM fails to unwind clock_gettime. Note that currentTimeMillis and nanoTime are JVM intrinsics: they do not do regular state transition; a thread remains in_Java while executing clock_gettime. A signal trampoline is just another example of code with uncommon frame layout (not only on PPC). I think frame pointers are problematic on some platforms, but not on PPC64. The PPC64 ABI requires a valid back chain at all time. *SP always points to the previous frame and frames are pushed atomically. On PPC64, retrieving the return PC from the top function (PC from ucontext) is unreliable because we don't know if it lives in the LR register or it was already written on stack. x86 doesn't have this problem because the call instruction writes the return PC on stack. I guess most other platforms have the problem like PPC64 that it's hard to figure out if we are before or after the frame complete offset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2687549517 From jsjolen at openjdk.org Thu Feb 27 10:59:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 10:59:02 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> References: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> Message-ID: <78xRqjvS-GMUESYEOx2qqU54--Ohbm8SAFGMsHTadbc=.118bfbe4-e178-4113-a710-4716b3dca68a@github.com> On Thu, 27 Feb 2025 09:33:30 GMT, Johan Sj?len wrote: >> Hi, >> >> When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. >> >> Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. >> >> Testing: StressAsyncUL.java, GHA > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > bool in C++, boolean in Java, great :-) Hi @MBaesken , @dholmes-ora Would you mind reviewing this? Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23819#issuecomment-2687601146 From jsjolen at openjdk.org Thu Feb 27 11:09:58 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 11:09:58 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> References: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> Message-ID: On Thu, 27 Feb 2025 09:33:30 GMT, Johan Sj?len wrote: >> Hi, >> >> When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. >> >> Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. >> >> Testing: StressAsyncUL.java, GHA > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > bool in C++, boolean in Java, great :-) test/hotspot/gtest/logging/test_asynclog.cpp line 265: > 263: bool async = AsyncLogWriter::instance() != nullptr > 264: && LogConfiguration::async_mode() == LogConfiguration::AsyncMode::Drop; > 265: if (async) { These tests do not currently fail, as the only mode gtests are run in are `drop` mode. However, let's fix them now in order to avoid failures in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23819#discussion_r1973369854 From jsjolen at openjdk.org Thu Feb 27 12:40:06 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 12:40:06 GMT Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region [v2] In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 09:38:12 GMT, Afshin Zafari wrote: >> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR. >> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR. >> >> Tests: >> linux-x64-debug, gtest:NMT*, runtime/NMT > > Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: > > - removed extra whitespace. > - unit test added. test/hotspot/gtest/nmt/test_vmatree.cpp line 728: > 726: } > 727: > 728: TEST_VM_F(NMTVMATreeTest, CommitUseFlagInplace) { Change this test to use `expect_equivalent_form`, see other usages to see what should look like. You can add multiple checks even, so that we get how the range changes over time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1973498475 From dholmes at openjdk.org Thu Feb 27 12:44:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 27 Feb 2025 12:44:59 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com> On Wed, 26 Feb 2025 14:39:11 GMT, Julian Waters wrote: > Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed. It is still allowed. Whether anyone actually needs it, or uses it is a different matter. The point is you have to match the gtest variant with the jdk variant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2687853352 From mbaesken at openjdk.org Thu Feb 27 12:55:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Feb 2025 12:55:52 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> References: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> Message-ID: On Thu, 27 Feb 2025 09:33:30 GMT, Johan Sj?len wrote: >> Hi, >> >> When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. >> >> Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. >> >> Testing: StressAsyncUL.java, GHA > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > bool in C++, boolean in Java, great :-) Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23819#pullrequestreview-2647685065 From jsjolen at openjdk.org Thu Feb 27 13:50:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 13:50:17 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 10:37:33 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > removed UseFlagInPlace test. More review comments. src/hotspot/share/nmt/memTracker.hpp line 60: > 58: static bool walk_virtual_memory(VirtualMemoryWalker* walker) { > 59: return VirtualMemoryTracker::Instance::walk_virtual_memory(walker); > 60: } The `MemTracker` API exposes the outer and locking implementation to the rest of Hotspot. These two methods are used by us internally. I think it's better if these methods are deleted and the `VirtualMemoryTracker::Instance` methods are called directly, instead. src/hotspot/share/nmt/nmtTreap.hpp line 388: > 386: head = to_visit.pop(); > 387: if (!f(head)) > 388: return; Style: Always use braces in `if` statements. src/hotspot/share/nmt/nmtTreap.hpp line 416: > 414: if (cmp_from >= 0 && cmp_to < 0) { > 415: if (!f(head)) > 416: return; Style: Always use braces in if statements. src/hotspot/share/nmt/regionsTree.hpp line 30: > 28: #include "nmt/nmtCommon.hpp" > 29: #include "nmt/vmatree.hpp" > 30: #include "nmt/virtualMemoryTracker.hpp" This doesn't seem used. However, you do not include the `nmt/nmtNativeCallStackStorage.hpp` header. src/hotspot/share/nmt/regionsTree.hpp line 49: > 47: using Node = VMATree::TreapNode; > 48: > 49: class NodeHelper { Most of the methods here should be `const` and take `const NodeHelper&` as arguments. src/hotspot/share/nmt/regionsTree.hpp line 62: > 60: inline VMATree::StateType in_state() { return _node->val().in.type(); } > 61: inline VMATree::StateType out_state() { return _node->val().out.type(); } > 62: inline size_t distance_from(NodeHelper& other) { return position() - other.position(); } `assert(position() > other.position()`. src/hotspot/share/nmt/regionsTree.hpp line 82: > 80: ); > 81: } > 82: }; 1. Doesn't need to be inline, move to `cpp` file. 2. No need to cast to `int`, just use the `VMATree::StateType` directly. 3. Should be wrapped in `#ifdef ASSERT` probably, I don't see us shipping this in product builds. src/hotspot/share/nmt/regionsTree.hpp line 90: > 88: return true; > 89: }); > 90: } Move to `cpp` file, wrap in `#ifdef ASSERT`. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 61: > 59: return _tracker->tree() != nullptr; > 60: } > 61: return true; ```c++ void* tracker = os::malloc(sizeof(VirtualMemoryTracker), mtNMT), if (tracker == nullptr) return false; _tracker = new (tracker) VirtualMemoryTracker(level == NMT_detail); src/hotspot/share/nmt/virtualMemoryTracker.cpp line 105: > 103: // " vms-committed: %zu", > 104: // str, NMTUtil::tag_to_name(tag), (long)reserve_delta, (long)commit_delta, reserved, committed); > 105: }; Any plan regarding this? src/hotspot/share/nmt/virtualMemoryTracker.cpp line 319: > 317: } > 318: VirtualMemoryTracker::Instance::add_committed_region(committed_start, committed_size, ncs); > 319: //log_warning(cds)("st start: " INTPTR_FORMAT " size: " SIZE_FORMAT, p2i(committed_start), committed_size); Outdated log src/hotspot/share/nmt/virtualMemoryTracker.hpp line 300: > 298: > 299: public: > 300: CommittedMemoryRegion() : Style: ```c== CommittedMemoryRegion() : VirtualMemoryRegion((address)1, 1), _stack(NativeCallStack::empty_stack()) { } src/hotspot/share/nmt/virtualMemoryTracker.hpp line 322: > 320: bool is_valid() { return base() != (address)1 && size() != 1;} > 321: ReservedMemoryRegion() : > 322: VirtualMemoryRegion((address)1, 1), _stack(NativeCallStack::empty_stack()), _mem_tag(mtNone) { } Style: Space between `is_valid` and constructor, fix initializer list as in `CommittedMemoryRegion`. src/hotspot/share/nmt/virtualMemoryTracker.hpp line 372: > 370: class VirtualMemoryTracker { > 371: private: > 372: RegionsTree *_tree; `class RegionsTree;` shouldn't be needed if you fix the circular include from above. There is no need to have the `private:` specifier. The `_tree` doesn't need to be a pointer after the forward declaration is removed, which in turn simplifies the initialization code. test/hotspot/gtest/nmt/test_nmt_treap.cpp line 30: > 28: #include "runtime/os.hpp" > 29: #include "unittest.hpp" > 30: #include "utilities/linkedlist.hpp" Outdated header inclusion ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2647773937 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973578352 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973584937 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973585248 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973610404 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973594825 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973594257 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973588473 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973589270 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973604346 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973603631 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973601861 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973599416 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973600519 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973612354 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973613179 From jsjolen at openjdk.org Thu Feb 27 13:50:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 13:50:17 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 24 Feb 2025 17:48:07 GMT, Gerard Ziemski wrote: >> Done. > > 2 questions: > > 1st, I must be misunderstanding something here. Johan asked to change the API from: > > `visit_committed_regions(ReservedMemoryRegion& committed_rgn)` > > to > > `visit_committed_regions(position start, size size)` > > but I still see the old way. > > 2nd, why are we asking for this change? We want to remove `ReservedMemoryRegion` in a follow up PR to this one. Another step is to remove the `CommittedMemoryRegion` class as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1973584029 From ihse at openjdk.org Thu Feb 27 15:03:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 27 Feb 2025 15:03:58 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com> References: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com> Message-ID: On Thu, 27 Feb 2025 12:42:35 GMT, David Holmes wrote: > actually is it still allowed? Does the build system require only a single JVM variant be configured? If not how do the different variants actually get built? Yes, it is allowed: `configure --with-jvm-variants=client,server`. But this "flexibility" causes a huge lot of mess in the build system, and I'm eager to see it go away if it is not actually used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2688218726 From ihse at openjdk.org Thu Feb 27 15:09:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 27 Feb 2025 15:09:59 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 19:50:43 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments Changes requested by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2648111916 From ihse at openjdk.org Thu Feb 27 15:10:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 27 Feb 2025 15:10:00 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> Message-ID: On Thu, 27 Feb 2025 06:53:26 GMT, Calvin Cheung wrote: >> make/hotspot/lib/JvmFeatures.gmk line 36: >> >>> 34: ################################################################################ >>> 35: >>> 36: JVM_CFLAGS_FEATURES += -DJVM_VARIANT=\"$(JVM_VARIANT)\" >> >> Might it be a better idea to set -DJVM_VARIANT as the CXXFLAGS for cdsConfig.cpp directly instead? > > Currently, os_bsd.cpp also needs the JVM_VARIANT definition. Later, if we fix the `os::jvm_path()` issues, os_windows.cpp, os_linux.cpp and os_aix.cpp also need JVM_VARIANT. This is completely wrong. The JVM_CFLAGS_FEATURES should be used to add feature-specific flags, not like this. If we really did want to add this to the CFLAGS for all Hotspot files, the correct thing to do would be to add it to JVM_CFLAGS in JvmFlags.gmk. However, that is not something we want to do. I fully agree with Julian. This is a specific patch needed for one file only, and it should be added just for this particular file. Compare how this is done for e.g. `abstract_vm_version.cpp` in CompileJvm.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1973779740 From pchilanomate at openjdk.org Thu Feb 27 15:19:57 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 27 Feb 2025 15:19:57 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Wed, 26 Feb 2025 17:04:28 GMT, Serguei Spitsyn wrote: >>> We are checking for suspension in ~ThreadInVMfromJava(), the problem is that the check there is too late, >> >> Okay but why are we not checking in the initial transition from Java, or elsewhere in the JRT_ENTRY? >> >> It just seems to me this is a general problem but we only happened to have tripped over one case of it. > > David and Patricio, thank you for raising this concern and discussion. I agree that normal mechanisms like `JRT_ENTRY` or `ThreadInVMfromJava` should provide suspend points before posting the JVMTI events. Let me do some investigation/analysis first. I suspect we might need to provide a suspend point in the `ThreadInVMfromJava` constructor additionally to the one in the destructor even though it looks a little bit strange. Adding a suspend check there won?t fix this issue though. It has to be added somewhere between coming out of the blocked state (where the thread can be seen as handshake-safe and suspended) and posting the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1973804882 From sspitsyn at openjdk.org Thu Feb 27 15:41:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 27 Feb 2025 15:41:54 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Thu, 27 Feb 2025 15:17:45 GMT, Patricio Chilano Mateo wrote: > Adding a suspend check there won?t fix this issue though. It has to be added somewhere between coming out of the blocked state (where the thread can be seen as handshake-safe and suspended) and posting the event. Agreed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1973847211 From iklam at openjdk.org Thu Feb 27 16:02:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 27 Feb 2025 16:02:32 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> Message-ID: On Thu, 27 Feb 2025 15:06:54 GMT, Magnus Ihse Bursie wrote: >> Currently, os_bsd.cpp also needs the JVM_VARIANT definition. Later, if we fix the `os::jvm_path()` issues, os_windows.cpp, os_linux.cpp and os_aix.cpp also need JVM_VARIANT. > > This is completely wrong. > > The JVM_CFLAGS_FEATURES should be used to add feature-specific flags, not like this. If we really did want to add this to the CFLAGS for all Hotspot files, the correct thing to do would be to add it to JVM_CFLAGS in JvmFlags.gmk. > > However, that is not something we want to do. I fully agree with Julian. This is a specific patch needed for one file only, and it should be added just for this particular file. Compare how this is done for e.g. `abstract_vm_version.cpp` in CompileJvm.gmk. Maybe we can add a new API `const char* Abstract_VM_Version::vm_variant()` that returns the value defined `-DJVM_VARIANT`? Files like os_*cpp and CDS can call this function to get the string such as "server" or "client". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1973885839 From kevinw at openjdk.org Thu Feb 27 16:48:13 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 27 Feb 2025 16:48:13 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK This change is implicated in the regression JDK-8350820 in the Windows management/cpu usage functions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688528615 From jwaters at openjdk.org Thu Feb 27 16:57:05 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 27 Feb 2025 16:57:05 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK That's not good. I cannot view JDK-8350820 however Is the issue in HotSpot, or another component? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688552358 PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688554610 From kevinw at openjdk.org Thu Feb 27 17:00:25 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 27 Feb 2025 17:00:25 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Issue recently logged, was marked confidential, will update... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688560132 From pchilanomate at openjdk.org Thu Feb 27 17:49:07 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 27 Feb 2025 17:49:07 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Stricter assertion on ppc64 Marked as reviewed by pchilanomate (Reviewer). src/hotspot/share/runtime/deoptimization.cpp line 645: > 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); > 644: Bytecode_invoke cur(method, deopt_sender.interpreter_frame_bci()); > 645: if (!cur.is_invokedynamic() && MethodHandles::has_member_arg(cur.klass(), cur.name())) { I was confused with this new condition but I see is the same we have in `vframeArray::unpack_to_stack()`. ------------- PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2648596315 PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1974069132 From jsjolen at openjdk.org Thu Feb 27 17:54:02 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 27 Feb 2025 17:54:02 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v3] In-Reply-To: References: Message-ID: <4c-z_6pxILWm0oAtNyGnhwSBhsLjCb59uV-95RsaYeY=.7a3bdfd1-e714-43b1-99d8-1b01e5656822@github.com> On Thu, 20 Feb 2025 09:36:44 GMT, Johan Sj?len wrote: >> Today NMT has two canaries: A header and a footer canary. These enable mainly two things: >> >> 1. For NMT to aid in describing a pointer >> 2. A basic form of out-of-bounds protection >> >> With the introduction of UBSan and Asan into OpenJDK we have gained stronger tools for this sort of analysis, without requiring NMT to be activated. Therefore, I believe that point 2 is no longer something that NMT needs to support. For point number one, we will unfortunately be losing this ability. >> >> I want to delete these canaries to open up a few free bytes. These can allow us to have "practically unlimited" (4 bytes) of memory tags. >> >> tier1-tier2 tests succeeded. >> >> I am awaiting discussion on the Hotspot-dev mailing list, but keeping this PR open for review. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'openjdk/master' into delete-canaries > - Comment > - Rename flags to tags > - Remove canaries Hi all, As you might suspect, there is a reason that this PR is still open. I am also a bit unsure about removing this. The goal is to replace the two canary bytes in the header with 2 bytes for MemTags, and using the unused byte to gain a total of 4 bytes. One thing we can do is to replace only one of the canary bytes, to gain a total of 3 bytes for MemTags. A 3 byte MemTag would absolutely be sufficient for what we want. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2688688245 From gziemski at openjdk.org Thu Feb 27 18:35:29 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 27 Feb 2025 18:35:29 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 10:37:33 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > removed UseFlagInPlace test. This is what I found today. Will do more tomorrow... src/hotspot/share/nmt/memReporter.cpp line 440: > 438: VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn, > 439: [&](CommittedMemoryRegion& committed_rgn) { > 440: if (committed_rgn.size() == reserved_rgn->size() && committed_rgn.call_stack()->equals(*stack)) { If we are calling here `equals()` anyhow, why not have CommittedMemoryRegion:equals() that checks both the size and the stack? This way we can simply have: `if (committed_rgn.equals(reserved_rgn)) ` src/hotspot/share/nmt/memTracker.hpp line 142: > 140: if (addr != nullptr) { > 141: NmtVirtualMemoryLocker nvml; > 142: VirtualMemoryTracker::Instance::add_reserved_region((address)addr, size, stack, mem_tag); I do not like: `VirtualMemoryTracker::Instance::add_reserved_region` with the `Instance` being repeated over and over. I'd prefer `VirtualMemoryTracker::add_reserved_region` and have `Instance` be impl detail inside. src/hotspot/share/nmt/memoryFileTracker.hpp line 32: > 30: #include "nmt/nmtNativeCallStackStorage.hpp" > 31: #include "nmt/vmatree.hpp" > 32: #include "nmt/virtualMemoryTracker.hpp" Are you 100% sure we need it here? src/hotspot/share/nmt/virtualMemoryTracker.cpp line 59: > 57: if (_tracker == nullptr) return false; > 58: new (_tracker) VirtualMemoryTracker(level == NMT_detail); > 59: return _tracker->tree() != nullptr; We should check for `tree() != nullptr;` inside VirtualMemoryTracker constructor as assert? src/hotspot/share/nmt/virtualMemoryTracker.cpp line 114: > 112: committed = VirtualMemorySummary::as_snapshot()->by_type(tag)->committed(); > 113: if (reserve_delta != 0) { > 114: if (reserve_delta > 0) Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 118: > 116: else { > 117: if ((size_t)-reserve_delta <= reserved) > 118: VirtualMemorySummary::record_released_memory(-reserve_delta, tag); Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 129: > 127: } > 128: else > 129: print_err("commit"); Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 133: > 131: else { > 132: if ((size_t)-commit_delta <= committed) > 133: VirtualMemorySummary::record_uncommitted_memory(-commit_delta, tag); Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 135: > 133: VirtualMemorySummary::record_uncommitted_memory(-commit_delta, tag); > 134: else > 135: print_err("uncommit"); Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 213: > 211: log_info(nmt)("region in walker vmem, base: " INTPTR_FORMAT " size: %zu , %s, committed: %zu", > 212: p2i(rgn.base()), rgn.size(), rgn.tag_name(), rgn.committed_size()); > 213: if (!walker->do_allocation_site(&rgn)) Missing braces. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 225: > 223: > 224: int compare_reserved_region_base(const ReservedMemoryRegion& r1, const ReservedMemoryRegion& r2) { > 225: return r1.compare(r2); Why did we name it `compare_reserved_region_base`, not simply `compare_reserved_region` src/hotspot/share/nmt/vmatree.cpp line 33: > 31: const VMATree::RegionData VMATree::empty_regiondata{NativeCallStackStorage::StackIndex{}, mtNone}; > 32: > 33: const char* VMATree::statetype_strings[4] = { You don't need do anything here if you take my suggestion from next comment... src/hotspot/share/nmt/vmatree.hpp line 73: > 71: assert(type < StateType::COUNT, "must be"); > 72: return statetype_strings[static_cast(type)]; > 73: } I don't like that we are hardcoding the size of this array and have COUNT be StateType. Can we do something like this?: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0 }; private: static constexpr const char* const statetype_strings[] = {"released", "reserved", "only-committed", "committed"}; static constexpr int STATETYPE_COUNT = static_cast(sizeof(statetype_strings)/sizeof(char*)); public: NONCOPYABLE(VMATree); static const char* statetype_to_string(StateType type) { assert(static_cast(type) < STATETYPE_COUNT, "must be"); return statetype_strings[static_cast(type)]; } ------------- Changes requested by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2648596994 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974069506 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974080149 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974082904 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974096829 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974100115 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974099677 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974100680 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974101028 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974101373 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974103095 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974105989 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974108411 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974129696 From gziemski at openjdk.org Thu Feb 27 18:35:30 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 27 Feb 2025 18:35:30 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 13:25:35 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/memTracker.hpp line 60: > >> 58: static bool walk_virtual_memory(VirtualMemoryWalker* walker) { >> 59: return VirtualMemoryTracker::Instance::walk_virtual_memory(walker); >> 60: } > > The `MemTracker` API exposes the outer and locking implementation to the rest of Hotspot. These two methods are used by us internally. I think it's better if these methods are deleted and the `VirtualMemoryTracker::Instance` methods are called directly, instead. Not sure I agree with Johan's comment here - in memBaseline.cpp we use MemTracker a lot, so adding these APIs make sense there, otherwise we would have to split work between MemTracker and VirtualMemoryTracker. Personally I like this way better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974077639 From iklam at openjdk.org Thu Feb 27 20:01:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 27 Feb 2025 20:01:57 GMT Subject: RFR: 8350148: Native stack overflow when writing Java heap objects into AOT cache In-Reply-To: References: Message-ID: On Sun, 16 Feb 2025 05:16:17 GMT, Ioi Lam wrote: > Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. > > The fix is to do the recursion using a side table, without making any recursive calls. > > Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline. @shipilev @rose00 could you take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23654#issuecomment-2688987381 From azafari at openjdk.org Thu Feb 27 21:04:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 21:04:13 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 17:50:25 GMT, Gerard Ziemski wrote: >> src/hotspot/share/nmt/memTracker.hpp line 60: >> >>> 58: static bool walk_virtual_memory(VirtualMemoryWalker* walker) { >>> 59: return VirtualMemoryTracker::Instance::walk_virtual_memory(walker); >>> 60: } >> >> The `MemTracker` API exposes the outer and locking implementation to the rest of Hotspot. These two methods are used by us internally. I think it's better if these methods are deleted and the `VirtualMemoryTracker::Instance` methods are called directly, instead. > > Not sure I agree with Johan's comment here - in memBaseline.cpp we use MemTracker a lot, so adding these APIs make sense there, otherwise we would have to split work between MemTracker and VirtualMemoryTracker. > > Personally I like this way better. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974328347 From azafari at openjdk.org Thu Feb 27 21:04:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 21:04:15 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 13:29:47 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/nmtTreap.hpp line 416: > >> 414: if (cmp_from >= 0 && cmp_to < 0) { >> 415: if (!f(head)) >> 416: return; > > Style: Always use braces in if statements. Done. > src/hotspot/share/nmt/regionsTree.hpp line 62: > >> 60: inline VMATree::StateType in_state() { return _node->val().in.type(); } >> 61: inline VMATree::StateType out_state() { return _node->val().out.type(); } >> 62: inline size_t distance_from(NodeHelper& other) { return position() - other.position(); } > > `assert(position() > other.position()`. Done. > src/hotspot/share/nmt/regionsTree.hpp line 82: > >> 80: ); >> 81: } >> 82: }; > > 1. Doesn't need to be inline, move to `cpp` file. > > 2. No need to cast to `int`, just use the `VMATree::StateType` directly. > > 3. Should be wrapped in `#ifdef ASSERT` probably, I don't see us shipping this in product builds. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974328543 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974331320 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974328760 From azafari at openjdk.org Thu Feb 27 21:07:12 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 21:07:12 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 13:35:40 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/regionsTree.hpp line 49: > >> 47: using Node = VMATree::TreapNode; >> 48: >> 49: class NodeHelper { > > Most of the methods here should be `const` and take `const NodeHelper&` as arguments. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974335058 From azafari at openjdk.org Thu Feb 27 21:13:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 27 Feb 2025 21:13:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 13:41:09 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 61: > >> 59: return _tracker->tree() != nullptr; >> 60: } >> 61: return true; > > ```c++ > void* tracker = os::malloc(sizeof(VirtualMemoryTracker), mtNMT), > if (tracker == nullptr) return false; > _tracker = new (tracker) VirtualMemoryTracker(level == NMT_detail); Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 319: > >> 317: } >> 318: VirtualMemoryTracker::Instance::add_committed_region(committed_start, committed_size, ncs); >> 319: //log_warning(cds)("st start: " INTPTR_FORMAT " size: " SIZE_FORMAT, p2i(committed_start), committed_size); > > Outdated log Done. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 300: > >> 298: >> 299: public: >> 300: CommittedMemoryRegion() : > > Style: > ```c== > CommittedMemoryRegion() > : VirtualMemoryRegion((address)1, 1), _stack(NativeCallStack::empty_stack()) { } Done. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 322: > >> 320: bool is_valid() { return base() != (address)1 && size() != 1;} >> 321: ReservedMemoryRegion() : >> 322: VirtualMemoryRegion((address)1, 1), _stack(NativeCallStack::empty_stack()), _mem_tag(mtNone) { } > > Style: Space between `is_valid` and constructor, fix initializer list as in `CommittedMemoryRegion`. Done. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 372: > >> 370: class VirtualMemoryTracker { >> 371: private: >> 372: RegionsTree *_tree; > > `class RegionsTree;` shouldn't be needed if you fix the circular include from above. There is no need to have the `private:` specifier. The `_tree` doesn't need to be a pointer after the forward declaration is removed, which in turn simplifies the initialization code. new `regionsTree.inline.hpp` is introduced to resolve the dependencies. > test/hotspot/gtest/nmt/test_nmt_treap.cpp line 30: > >> 28: #include "runtime/os.hpp" >> 29: #include "unittest.hpp" >> 30: #include "utilities/linkedlist.hpp" > > Outdated header inclusion Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974339508 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974339232 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974338173 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974338397 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974340867 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1974341165 From dholmes at openjdk.org Thu Feb 27 21:37:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 27 Feb 2025 21:37:09 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Thu, 27 Feb 2025 15:38:49 GMT, Serguei Spitsyn wrote: >> Adding a suspend check there won?t fix this issue though. It has to be added somewhere between coming out of the blocked state (where the thread can be seen as handshake-safe and suspended) and posting the event. > >> Adding a suspend check there won?t fix this issue though. It has to be added somewhere between coming out of the blocked state (where the thread can be seen as handshake-safe and suspended) and posting the event. > > Agreed, thanks. If we are racing with a suspend request then we cannot win if it could happen at any time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1974367081 From dholmes at openjdk.org Thu Feb 27 21:40:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 27 Feb 2025 21:40:01 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Thu, 27 Feb 2025 21:33:56 GMT, David Holmes wrote: >>> Adding a suspend check there won?t fix this issue though. It has to be added somewhere between coming out of the blocked state (where the thread can be seen as handshake-safe and suspended) and posting the event. >> >> Agreed, thanks. > > If we are racing with a suspend request then we cannot win if it could happen at any time. > It has to be added somewhere between coming out of the blocked state Sorry when are we in the blocked state in the current scenario? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1974370904 From pchilanomate at openjdk.org Thu Feb 27 22:30:53 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 27 Feb 2025 22:30:53 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Thu, 27 Feb 2025 21:37:19 GMT, David Holmes wrote: >> If we are racing with a suspend request then we cannot win if it could happen at any time. > >> It has to be added somewhere between coming out of the blocked state > > Sorry when are we in the blocked state in the current scenario? When trying to get the JvmtiThreadState_lock to create the JvmtiThreadState object: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x14ba342] Mutex::lock_contended(Thread*)+0x392 (interfaceSupport.inline.hpp:210) V [libjvm.so+0x14bbf7a] Mutex::lock()+0x9a (mutex.cpp:125) V [libjvm.so+0x120e9cb] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x31b (mutexLocker.hpp:196) V [libjvm.so+0x1212c08] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x98 (jvmtiExport.cpp:424) V [libjvm.so+0x121e54a] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x7a (jvmtiExport.cpp:1332) V [libjvm.so+0xed8728] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1165) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1974426551 From ccheung at openjdk.org Fri Feb 28 00:37:24 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 00:37:24 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4] In-Reply-To: References: Message-ID: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @magius and @iklam comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23758/files - new: https://git.openjdk.org/jdk/pull/23758/files/4703c943..2e6a55a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23758&range=02-03 Stats: 15 lines in 6 files changed: 10 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23758/head:pull/23758 PR: https://git.openjdk.org/jdk/pull/23758 From ccheung at openjdk.org Fri Feb 28 00:37:24 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 00:37:24 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3] In-Reply-To: References: <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com> Message-ID: On Thu, 27 Feb 2025 15:58:55 GMT, Ioi Lam wrote: >> This is completely wrong. >> >> The JVM_CFLAGS_FEATURES should be used to add feature-specific flags, not like this. If we really did want to add this to the CFLAGS for all Hotspot files, the correct thing to do would be to add it to JVM_CFLAGS in JvmFlags.gmk. >> >> However, that is not something we want to do. I fully agree with Julian. This is a specific patch needed for one file only, and it should be added just for this particular file. Compare how this is done for e.g. `abstract_vm_version.cpp` in CompileJvm.gmk. > > Maybe we can add a new API `const char* Abstract_VM_Version::vm_variant()` that returns the value defined `-DJVM_VARIANT`? Files like os_*cpp and CDS can call this function to get the string such as "server" or "client". I've pushed another commit based on the above comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1974546276 From dholmes at openjdk.org Fri Feb 28 01:35:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Feb 2025 01:35:00 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> References: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> Message-ID: On Thu, 27 Feb 2025 09:33:30 GMT, Johan Sj?len wrote: >> Hi, >> >> When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. >> >> Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. >> >> Testing: StressAsyncUL.java, GHA > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > bool in C++, boolean in Java, great :-) Seems okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23819#pullrequestreview-2649480617 From iklam at openjdk.org Fri Feb 28 02:02:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 28 Feb 2025 02:02:11 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @magius and @iklam comments Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2649512032 From dholmes at openjdk.org Fri Feb 28 02:06:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Feb 2025 02:06:57 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Thu, 27 Feb 2025 22:28:33 GMT, Patricio Chilano Mateo wrote: >>> It has to be added somewhere between coming out of the blocked state >> >> Sorry when are we in the blocked state in the current scenario? > > When trying to get the JvmtiThreadState_lock to create the JvmtiThreadState object: > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x14ba342] Mutex::lock_contended(Thread*)+0x392 (interfaceSupport.inline.hpp:210) > V [libjvm.so+0x14bbf7a] Mutex::lock()+0x9a (mutex.cpp:125) > V [libjvm.so+0x120e9cb] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x31b (mutexLocker.hpp:196) > V [libjvm.so+0x1212c08] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x98 (jvmtiExport.cpp:424) > V [libjvm.so+0x121e54a] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x7a (jvmtiExport.cpp:1332) > V [libjvm.so+0xed8728] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1165) Uggghhh - I see. So why isn't this caught at ` ~ThreadBlockInVMPreprocess()`? Sorry I'm struggling to see the complete code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1974625178 From dholmes at openjdk.org Fri Feb 28 02:12:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Feb 2025 02:12:53 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @magius and @iklam comments I like this approach as it addresses the real issue - that we need to know the variant name to find the right directory. The jvm_path logic in os_bsd is completely broken so we should look at cleaning that up separately. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2649521617 From iklam at openjdk.org Fri Feb 28 05:18:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 28 Feb 2025 05:18:03 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" Message-ID: Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. I verified with running all CDS tests and the assert is never triggered. ------------- Commit messages: - Remove misleading warning "Cannot dump shared archive while using shared archive" Changes: https://git.openjdk.org/jdk/pull/23836/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23836&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350916 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23836.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23836/head:pull/23836 PR: https://git.openjdk.org/jdk/pull/23836 From duke at openjdk.org Fri Feb 28 07:25:52 2025 From: duke at openjdk.org (mScott224) Date: Fri, 28 Feb 2025 07:25:52 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 02:10:16 GMT, Ioi Lam wrote: > Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. > > I verified with running all CDS tests and the assert is never triggered. Marked as reviewed by mScott224 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23836#pullrequestreview-2649952394 From duke at openjdk.org Fri Feb 28 07:32:58 2025 From: duke at openjdk.org (mScott224) Date: Fri, 28 Feb 2025 07:32:58 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" In-Reply-To: References: Message-ID: <8ZovDysVckmFg696cDTXTTbBDQj6L8o0d8XICC1w8Dc=.427d1187-96ee-46d9-b88b-770e7bd47494@github.com> On Fri, 28 Feb 2025 02:10:16 GMT, Ioi Lam wrote: > Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. > > I verified with running all CDS tests and the assert is never triggered. Marked as reviewed by mScott224 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23836#pullrequestreview-2649966352 From ccheung at openjdk.org Fri Feb 28 07:32:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 07:32:57 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 02:10:16 GMT, Ioi Lam wrote: > Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. > > I verified with running all CDS tests and the assert is never triggered. One typo. Looks good otherwise. src/hotspot/share/cds/cdsConfig.cpp line 72: > 70: if (is_dumping_static_archive() && !is_dumping_final_static_archive()) { > 71: // Note: -Xshare and -XX:AOTMode flags are mutually exclusive. > 72: // - Class workflow: -Xshare:on and -Xshare:dump cannot take effect at the same time. s/Class/Classic ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23836#pullrequestreview-2649964192 PR Review Comment: https://git.openjdk.org/jdk/pull/23836#discussion_r1974935296 From stuefe at openjdk.org Fri Feb 28 09:32:04 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Feb 2025 09:32:04 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: References: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> Message-ID: On Wed, 26 Feb 2025 19:23:08 GMT, Thomas Stuefe wrote: > > As I said in preparation of this work, I don't oppose it, but I am not happy. > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. Thinking about this, I actually rely on this feature a lot more often: A) Customer: "Look at my hs-err file" B) Me: (see crashes in somewhere in libc, or something that looks like corrupted C-heap) "Switch on NMT please" C) Customer: "ok" - does it, no change. D) Now I know it is not a simple double free or overwrite of memory allocated by the hotspot or direct byte buffers. I can exclude, for now, _us_ (the VM vendor) as a culprit and take a closer look at whatever third-party JNI libraries are running in the process. In the end, it may still turn out we broke something, but for now a misuse of C-heap from non-JDK code is more likely. So, NMT is a useful first-responder tool in these cases. This is not that rare. And this feature will be a lot more useful once we have full-process - or at least, with Johan's plans - full JDK integration of NMT. Because then, the surface of instrumented code is larger. If, at step (B), I would have asked the customer: "Can you please switch out the JVM against one I give you that has ASAN enabled", that runs into tons of problems: they may not be in a position to switch out binaries (maybe deployed out of reach somewhere), they may not be allowed to, ASAN build may be too slow, ASAN crashes may be unacceptable in production (and these crashes will be much more likely than NMT finding some problem). For that reason, I propose to leave the footer canary as it is. I cannot see what purpose removing it serves (other than "oh it is simpler now"), and arguably it's the more important of the two canaries for catching end-of-buffer overruns. The leading canary let's shrink to one byte. Ideally placed right in front of the user payload. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2690157167 From jsjolen at openjdk.org Fri Feb 28 09:47:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 09:47:14 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 17:52:19 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/memTracker.hpp line 142: > >> 140: if (addr != nullptr) { >> 141: NmtVirtualMemoryLocker nvml; >> 142: VirtualMemoryTracker::Instance::add_reserved_region((address)addr, size, stack, mem_tag); > > I do not like: > > `VirtualMemoryTracker::Instance::add_reserved_region` > > with the `Instance` being repeated over and over. > > I'd prefer `VirtualMemoryTracker::add_reserved_region` and have `Instance` be impl detail inside. The wordiness is a bit annoying. The reason that we do this is to separate the global static instance from the implementation, so that we can have many `VMT`s when testing (this is very useful). Do you have a concrete way we can refactor this such that we retain the possibility of having many VMTs and one static instance, whilst reducing the wordiness when using the code? Can this refactoring wait until after integration, as we have more classes following the same pattern that'd need to be refactored? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975118055 From jsjolen at openjdk.org Fri Feb 28 09:49:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 09:49:57 GMT Subject: RFR: 8342504: Remove NMT header and footer canaries [v2] In-Reply-To: References: <7C0XZyB945uCvJ4UlEgfCdXPAQXs5SGBu7RZZYJcDIs=.556d9a09-e360-41d0-9f11-394a2a7e23f5@github.com> Message-ID: <9qoiqn2I0trxuG3fCqsgV_2YIDvKUk5WIX8NKxWeoF4=.6a43679a-fe98-4768-9951-5e7a6a25124e@github.com> On Fri, 28 Feb 2025 09:29:23 GMT, Thomas Stuefe wrote: > > > As I said in preparation of this work, I don't oppose it, but I am not happy. > > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one. > > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability. > > > > > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field. > > Thinking about this, I actually rely on this feature a lot more often: > > A) Customer: "Look at my hs-err file" > > B) Me: (see crashes in somewhere in libc, or something that looks like corrupted C-heap) "Switch on NMT please" > > C) Customer: "ok" - does it, no change. > > D) Now I know it is not a simple double free or overwrite of memory allocated by the hotspot or direct byte buffers. I can exclude, for now, _us_ (the VM vendor) as a culprit and take a closer look at whatever third-party JNI libraries are running in the process. In the end, it may still turn out we broke something, but for now a misuse of C-heap from non-JDK code is more likely. So, NMT is a useful first-responder tool in these cases. > > This is not that rare. And this feature will be a lot more useful once we have full-process - or at least, with Johan's plans - full JDK integration of NMT. Because then, the surface of instrumented code is larger. > > If, at step (B), I would have asked the customer: "Can you please switch out the JVM against one I give you that has ASAN enabled", that runs into tons of problems: they may not be in a position to switch out binaries (maybe deployed out of reach somewhere), they may not be allowed to, ASAN build may be too slow, ASAN crashes may be unacceptable in production (and these crashes will be much more likely than NMT finding some problem). > > For that reason, I propose to leave the footer canary as it is. I cannot see what purpose removing it serves (other than "oh it is simpler now"), and arguably it's the more important of the two canaries for catching end-of-buffer overruns. The leading canary let's shrink to one byte. Ideally placed right in front of the user payload. This sounds like a good middle-ground. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2690200172 From jsjolen at openjdk.org Fri Feb 28 09:50:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 09:50:59 GMT Subject: RFR: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails [v2] In-Reply-To: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> References: <5woM9n8I5JD4DXYV1B5U0Y___k4Q8VZAfk0KCejv0Mk=.096d5138-2772-4ac4-a170-375d3c77f91c@github.com> Message-ID: On Thu, 27 Feb 2025 09:33:30 GMT, Johan Sj?len wrote: >> Hi, >> >> When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. >> >> Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. >> >> Testing: StressAsyncUL.java, GHA > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > bool in C++, boolean in Java, great :-) Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/23819#issuecomment-2690200572 From jsjolen at openjdk.org Fri Feb 28 09:51:00 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 09:51:00 GMT Subject: Integrated: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails In-Reply-To: References: Message-ID: <64u4YYKlvCtKG1jZgXornK4hRkxAy2mdEzqWFviCqBQ=.b7b5389f-b2c5-4299-9f12-cff12a10d1ee@github.com> On Thu, 27 Feb 2025 09:17:54 GMT, Johan Sj?len wrote: > Hi, > > When I added async stalling mode I also added this gtest early in the process, and as tier1/GHA passed I did not look at the test again. However, the test does not run until much deeper in the CI/CD process for us, as that's when we turn on async logging explicitly for all gtests. > > Looking at it now, it's clearly buggy. It doesn't check which async mode UL is in, and as `drop` is default, that makes it bound to fail. Besides, the goal of it is to check whether async stalling mode drops messages or not during stress. We already have an excellent test for that in JTReg, and this does run early as it spawns its own VM with the correct asynchronous mode specified. My suggested fix is to delete the gtest and add a dropped message check to the JTReg test instead. > > Testing: StressAsyncUL.java, GHA This pull request has now been integrated. Changeset: ac76d8d6 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/ac76d8d63ff7b06a3c116559712a8b48f8acfa20 Stats: 24 lines in 2 files changed: 5 ins; 12 del; 7 mod 8350824: New async logging gtest StallingModePreventsDroppedMessages fails Reviewed-by: mbaesken, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23819 From dholmes at openjdk.org Fri Feb 28 10:07:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Feb 2025 10:07:52 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v2] In-Reply-To: References: <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com> Message-ID: On Wed, 26 Feb 2025 07:27:23 GMT, Kazuhisa Takakuri wrote: >> test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 68: >> >>> 66: //Execution command to prevent garbled characters >>> 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); >>> 68: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); >> >> I see the use of `chcp` in the test `./tools/jpackage/helpers/jdk/jpackage/test/Executor.java` so that is okay. However it doesn't set the path and it does not seem necessary to do so, and potentially assumes what the paths are anyway. So I think you can simplify this a little. > > As well as tools/jpackage/windows/Win8301247Test.java, the tools tests is not included in jdk/tier1, so it will not run in GHA? Sorry I'm not sure what you are asking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1975150850 From jsjolen at openjdk.org Fri Feb 28 10:17:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 10:17:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 18:27:53 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/vmatree.hpp line 73: > >> 71: assert(type < StateType::COUNT, "must be"); >> 72: return statetype_strings[static_cast(type)]; >> 73: } > > I don't like that we are hardcoding the size of this array and have COUNT be StateType. Can we do something like this?: > > > enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0 }; > > private: > static constexpr const char* const statetype_strings[] = {"released", "reserved", "only-committed", "committed"}; > static constexpr int STATETYPE_COUNT = static_cast(sizeof(statetype_strings)/sizeof(char*)); > > public: > NONCOPYABLE(VMATree); > > static const char* statetype_to_string(StateType type) { > assert(static_cast(type) < STATETYPE_COUNT, "must be"); > return statetype_strings[static_cast(type)]; > } This is a fairly standard pattern in Hotspot, so personally I'm fine with keeping it as-is. Here's an incomplete list of pre-existing usages: ```c++ // UL tag list enum type { __NO_TAG, #define LOG_TAG(name) _##name, LOG_TAG_LIST #undef LOG_TAG Count }; // enum for figuring positions and size of Symbol::_vm_symbols[] enum class vmSymbolID : int { // [FIRST_SID ... LAST_SID] is the iteration range for the *valid* symbols. // NO_SID is used to indicate an invalid symbol. Some implementation code // *may* read _vm_symbols[NO_SID], so it must be a valid array index. NO_SID = 0, // exclusive lower limit #define VM_SYMBOL_ENUM(name, string) VM_SYMBOL_ENUM_NAME_(name), VM_SYMBOLS_DO(VM_SYMBOL_ENUM, VM_ALIAS_IGNORE) #undef VM_SYMBOL_ENUM SID_LIMIT, // exclusive upper limit #define VM_ALIAS_ENUM(name, def) VM_SYMBOL_ENUM_NAME_(name) = VM_SYMBOL_ENUM_NAME_(def), VM_SYMBOLS_DO(VM_SYMBOL_IGNORE, VM_ALIAS_ENUM) #undef VM_ALIAS_ENUM FIRST_SID = NO_SID + 1, // inclusive lower limit LAST_SID = SID_LIMIT - 1, // inclusive upper limit }; enum class InjectedFieldID : int { ALL_INJECTED_FIELDS(DECLARE_INJECTED_FIELD_ENUM) MAX_enum }; enum class vmClassID : int { #define DECLARE_VM_CLASS(name, symbol) _VM_CLASS_ENUM(name), _VM_CLASS_ENUM(symbol) = _VM_CLASS_ENUM(name), VM_CLASSES_DO(DECLARE_VM_CLASS) #undef DECLARE_VM_CLASS LIMIT, // exclusive upper limit FIRST = 0, // inclusive upper limit LAST = LIMIT - 1 // inclusive upper limit }; enum class CodeBlobType { MethodNonProfiled = 0, // Execution level 1 and 4 (non-profiled) nmethods (including native nmethods) MethodProfiled = 1, // Execution level 2 and 3 (profiled) nmethods NonNMethod = 2, // Non-nmethods like Buffers, Adapters and Runtime Stubs All = 3, // All types (No code cache segmentation) NumTypes = 4 // Number of CodeBlobTypes }; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975161907 From jsjolen at openjdk.org Fri Feb 28 10:22:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 28 Feb 2025 10:22:17 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 20:58:13 GMT, Afshin Zafari wrote: >> Not sure I agree with Johan's comment here - in memBaseline.cpp we use MemTracker a lot, so adding these APIs make sense there, otherwise we would have to split work between MemTracker and VirtualMemoryTracker. >> >> Personally I like this way better. > > Done. I'm not sure what you mean with using MemTracker a lot, we use it twice: Once for taking the NMT lock, and once for checking the NMT level. The current structure of NMT is that `MemTracker` is responsible for taking locks and checking if NMT is enabled, and then calling the underlying APIs. The underlying APIs are only meant to be called directly by other NMT components, such as `MemBaseline` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975168022 From ihse at openjdk.org Fri Feb 28 10:23:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 28 Feb 2025 10:23:58 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote: >> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. >> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. >> >> Testing: >> >> - run gtest with -Xshare:on on linux-x64 >> - tier1 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @magius and @iklam comments This looks good from a build perspective! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2650346184 From kevinw at openjdk.org Fri Feb 28 11:18:08 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 28 Feb 2025 11:18:08 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Quick fix is PR https://github.com/openjdk/jdk/pull/23832 taking care of it in JDK 25, and there should be a backport to JDK 24 first update. I will come back with a further update in JDK-8350939 to reinstate snprintf. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2690383444 From rrich at openjdk.org Fri Feb 28 12:14:07 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 28 Feb 2025 12:14:07 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long wrote: >> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received. In deoptimization, we check for this in several places, but in one place we had outdated code. See the bug for the gory details. >> >> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations. There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports. >> >> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee. The asserts I added compute locals both ways and check that they are still within the frame. I attempted this on all platforms, but am only able to test x64 and aarch64. I need help testing those asserts for arm32, ppc, riscv, and s390. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Stricter assertion on ppc64 Marked as reviewed by rrich (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2650575715 From rrich at openjdk.org Fri Feb 28 12:14:09 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 28 Feb 2025 12:14:09 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Thu, 27 Feb 2025 17:44:05 GMT, Patricio Chilano Mateo wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> Stricter assertion on ppc64 > > src/hotspot/share/runtime/deoptimization.cpp line 645: > >> 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); >> 644: Bytecode_invoke cur(method, deopt_sender.interpreter_frame_bci()); >> 645: if (!cur.is_invokedynamic() && MethodHandles::has_member_arg(cur.klass(), cur.name())) { > > I was confused with this new condition but I see is the same we have in `vframeArray::unpack_to_stack()`. +1 I see there's also an assertion in `ConstantPool::klass_ref_index_at()`. It might be worth a little comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1975310438 From mbaesken at openjdk.org Fri Feb 28 12:23:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Feb 2025 12:23:59 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated comment src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2: > 1: /* > 2: * Copyright (c) 2020, 2024, Red Hat Inc. Guess this must be 2025 now ? Same for other files ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975321465 From mbaesken at openjdk.org Fri Feb 28 12:30:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 28 Feb 2025 12:30:13 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated comment test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69: > 67: /* > 68: * Less common cases: Containers > 69: */ Not really sure why this comment was added, is it refering to 'container mode' mentioned in the comment above in another file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975330669 From azafari at openjdk.org Fri Feb 28 13:07:10 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:07:10 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 17:54:25 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/memoryFileTracker.hpp line 32: > >> 30: #include "nmt/nmtNativeCallStackStorage.hpp" >> 31: #include "nmt/vmatree.hpp" >> 32: #include "nmt/virtualMemoryTracker.hpp" > > Are you 100% sure we need it here? `VirtualMemorySnapshot` is used here which is defined in `virtualMemoryTracker.hpp`. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 59: > >> 57: if (_tracker == nullptr) return false; >> 58: new (_tracker) VirtualMemoryTracker(level == NMT_detail); >> 59: return _tracker->tree() != nullptr; > > We should check for `tree() != nullptr;` inside VirtualMemoryTracker constructor as assert? Then in Product build, the `tree == nullptr` ends up in a crash. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 135: > >> 133: VirtualMemorySummary::record_uncommitted_memory(-commit_delta, tag); >> 134: else >> 135: print_err("uncommit"); > > Missing braces. Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 213: > >> 211: log_info(nmt)("region in walker vmem, base: " INTPTR_FORMAT " size: %zu , %s, committed: %zu", >> 212: p2i(rgn.base()), rgn.size(), rgn.tag_name(), rgn.committed_size()); >> 213: if (!walker->do_allocation_site(&rgn)) > > Missing braces. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975376033 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975377752 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975380490 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975381241 From azafari at openjdk.org Fri Feb 28 13:12:17 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:12:17 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 18:11:26 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 225: > >> 223: >> 224: int compare_reserved_region_base(const ReservedMemoryRegion& r1, const ReservedMemoryRegion& r2) { >> 225: return r1.compare(r2); > > Why did we name it `compare_reserved_region_base`, not simply `compare_reserved_region` This function and also `compare_committed_region` are used as comparators for `SortedLinkedList` and have no use anymore here. They are removed. Thanks for catching this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975387868 From azafari at openjdk.org Fri Feb 28 13:18:08 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:18:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <_NgwaL7X0Wail8MgHyql0JSLLkPBbHgrnCuuhdDEpzo=.8a272cee-1077-4c68-a018-5df5c867cc68@github.com> On Fri, 28 Feb 2025 09:44:09 GMT, Johan Sj?len wrote: >> src/hotspot/share/nmt/memTracker.hpp line 142: >> >>> 140: if (addr != nullptr) { >>> 141: NmtVirtualMemoryLocker nvml; >>> 142: VirtualMemoryTracker::Instance::add_reserved_region((address)addr, size, stack, mem_tag); >> >> I do not like: >> >> `VirtualMemoryTracker::Instance::add_reserved_region` >> >> with the `Instance` being repeated over and over. >> >> I'd prefer `VirtualMemoryTracker::add_reserved_region` and have `Instance` be impl detail inside. > > The wordiness is a bit annoying. The reason that we do this is to separate the global static instance from the implementation, so that we can have many `VMT`s when testing (this is very useful). Do you have a concrete way we can refactor this such that we retain the possibility of having many VMTs and one static instance, whilst reducing the wordiness when using the code? Can this refactoring wait until after integration, as we have more classes following the same pattern that'd need to be refactored? The `HeapReserver` and `MemoryFileTracker` classes (in different parts of the code and different PRs) also use the same syntax for it. Here the same style is used to keep similarity in Hotspot code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975395435 From azafari at openjdk.org Fri Feb 28 13:26:12 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:26:12 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 18:06:50 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 114: > >> 112: committed = VirtualMemorySummary::as_snapshot()->by_type(tag)->committed(); >> 113: if (reserve_delta != 0) { >> 114: if (reserve_delta > 0) > > Missing braces. Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 118: > >> 116: else { >> 117: if ((size_t)-reserve_delta <= reserved) >> 118: VirtualMemorySummary::record_released_memory(-reserve_delta, tag); > > Missing braces. Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 129: > >> 127: } >> 128: else >> 129: print_err("commit"); > > Missing braces. Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 133: > >> 131: else { >> 132: if ((size_t)-commit_delta <= committed) >> 133: VirtualMemorySummary::record_uncommitted_memory(-commit_delta, tag); > > Missing braces. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975405233 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975400984 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975405522 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975405745 From azafari at openjdk.org Fri Feb 28 13:32:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:32:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 17:44:25 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/memReporter.cpp line 440: > >> 438: VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn, >> 439: [&](CommittedMemoryRegion& committed_rgn) { >> 440: if (committed_rgn.size() == reserved_rgn->size() && committed_rgn.call_stack()->equals(*stack)) { > > If we are calling here > > `equals()` > > anyhow, why not have CommittedMemoryRegion:equals() that checks both the size and the stack? This way we can simply have: > > `if (committed_rgn.equals(reserved_rgn)) > ` Done. But it is used only here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975413206 From azafari at openjdk.org Fri Feb 28 13:41:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:41:13 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <6Lyj3WWHS6YYyIk9gkcQ5SS5C0Pon4dGGSYjOZ7fAiM=.ddd71400-d85c-49d2-b76b-e399c6027e5d@github.com> On Thu, 27 Feb 2025 13:29:35 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/nmtTreap.hpp line 388: > >> 386: head = to_visit.pop(); >> 387: if (!f(head)) >> 388: return; > > Style: Always use braces in `if` statements. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975424820 From azafari at openjdk.org Fri Feb 28 13:41:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:41:15 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Fri, 28 Feb 2025 10:14:18 GMT, Johan Sj?len wrote: >> src/hotspot/share/nmt/vmatree.hpp line 73: >> >>> 71: assert(type < StateType::COUNT, "must be"); >>> 72: return statetype_strings[static_cast(type)]; >>> 73: } >> >> I don't like that we are hardcoding the size of this array and have COUNT be StateType. Can we do something like this?: >> >> >> enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0 }; >> >> private: >> static constexpr const char* const statetype_strings[] = {"released", "reserved", "only-committed", "committed"}; >> static constexpr int STATETYPE_COUNT = static_cast(sizeof(statetype_strings)/sizeof(char*)); >> >> public: >> NONCOPYABLE(VMATree); >> >> static const char* statetype_to_string(StateType type) { >> assert(static_cast(type) < STATETYPE_COUNT, "must be"); >> return statetype_strings[static_cast(type)]; >> } > > This is a fairly standard pattern in Hotspot, so personally I'm fine with keeping it as-is. > > Here's an incomplete list of pre-existing usages: > > ```c++ > // UL tag list > enum type { > __NO_TAG, > #define LOG_TAG(name) _##name, > LOG_TAG_LIST > #undef LOG_TAG > Count > }; > > > // enum for figuring positions and size of Symbol::_vm_symbols[] > enum class vmSymbolID : int { > // [FIRST_SID ... LAST_SID] is the iteration range for the *valid* symbols. > // NO_SID is used to indicate an invalid symbol. Some implementation code > // *may* read _vm_symbols[NO_SID], so it must be a valid array index. > NO_SID = 0, // exclusive lower limit > > #define VM_SYMBOL_ENUM(name, string) VM_SYMBOL_ENUM_NAME_(name), > VM_SYMBOLS_DO(VM_SYMBOL_ENUM, VM_ALIAS_IGNORE) > #undef VM_SYMBOL_ENUM > > SID_LIMIT, // exclusive upper limit > > #define VM_ALIAS_ENUM(name, def) VM_SYMBOL_ENUM_NAME_(name) = VM_SYMBOL_ENUM_NAME_(def), > VM_SYMBOLS_DO(VM_SYMBOL_IGNORE, VM_ALIAS_ENUM) > #undef VM_ALIAS_ENUM > > FIRST_SID = NO_SID + 1, // inclusive lower limit > LAST_SID = SID_LIMIT - 1, // inclusive upper limit > }; > > enum class InjectedFieldID : int { > ALL_INJECTED_FIELDS(DECLARE_INJECTED_FIELD_ENUM) > MAX_enum > }; > > enum class vmClassID : int { > #define DECLARE_VM_CLASS(name, symbol) _VM_CLASS_ENUM(name), _VM_CLASS_ENUM(symbol) = _VM_CLASS_ENUM(name), > VM_CLASSES_DO(DECLARE_VM_CLASS) > #undef DECLARE_VM_CLASS > > LIMIT, // exclusive upper limit > FIRST = 0, // inclusive upper limit > LAST = LIMIT - 1 // inclusive upper limit > }; > > enum class CodeBlobType { > MethodNonProfiled = 0, // Execution level 1 and 4 (non-profiled) nmethods (including native nmethods) > MethodProfiled = 1, // Execution level 2 and 3 (profiled) nmethods > NonNMethod = 2, // Non-nmethods like Buffers, Adapters and Runtime Stubs > All = 3, // All types (No code cache segmentation) > NumTypes = 4 // Number of CodeBlobTypes > }; There is coding style that the last enum member counts the number of them, like what we have `mt_number_of_tags` in `MemTag` enum. So, I renamed the last member to `st_number_of_states`. Would it be OK? Or preferred to use constant separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975423884 From azafari at openjdk.org Fri Feb 28 13:46:08 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:46:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 27 Feb 2025 13:44:48 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> removed UseFlagInPlace test. > > src/hotspot/share/nmt/regionsTree.hpp line 30: > >> 28: #include "nmt/nmtCommon.hpp" >> 29: #include "nmt/vmatree.hpp" >> 30: #include "nmt/virtualMemoryTracker.hpp" > > This doesn't seem used. However, you do not include the `nmt/nmtNativeCallStackStorage.hpp` header. Done. > src/hotspot/share/nmt/regionsTree.hpp line 90: > >> 88: return true; >> 89: }); >> 90: } > > Move to `cpp` file, wrap in `#ifdef ASSERT`. Done. > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 105: > >> 103: // " vms-committed: %zu", >> 104: // str, NMTUtil::tag_to_name(tag), (long)reserve_delta, (long)commit_delta, reserved, committed); >> 105: }; > > Any plan regarding this? Will be commented out after https://github.com/openjdk/jdk/pull/23771. Until then, the error messages will pollute the output and corrupt the jdk-image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975432017 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975429334 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975431804 From azafari at openjdk.org Fri Feb 28 13:55:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 28 Feb 2025 13:55:30 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: style, some cleanup, VMT and regionsTree circular dep resolved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/74e4872d..70209581 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=31-32 Stats: 329 lines in 16 files changed: 146 ins; 123 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From pchilanomate at openjdk.org Fri Feb 28 14:22:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 28 Feb 2025 14:22:58 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4] In-Reply-To: References: <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> Message-ID: On Fri, 28 Feb 2025 02:04:39 GMT, David Holmes wrote: >> When trying to get the JvmtiThreadState_lock to create the JvmtiThreadState object: >> >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x14ba342] Mutex::lock_contended(Thread*)+0x392 (interfaceSupport.inline.hpp:210) >> V [libjvm.so+0x14bbf7a] Mutex::lock()+0x9a (mutex.cpp:125) >> V [libjvm.so+0x120e9cb] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x31b (mutexLocker.hpp:196) >> V [libjvm.so+0x1212c08] JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x98 (jvmtiExport.cpp:424) >> V [libjvm.so+0x121e54a] JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x7a (jvmtiExport.cpp:1332) >> V [libjvm.so+0xed8728] InterpreterRuntime::at_safepoint(JavaThread*)+0x118 (interpreterRuntime.cpp:1165) > > Uggghhh - I see. So why isn't this caught at ` ~ThreadBlockInVMPreprocess()`? Sorry I'm struggling to see the complete code. We only allow suspension at `~ThreadBlockInVMPreprocess()` on very few cases where we know it's safe because there are no VM monitors held (the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization()). Otherwise the default is to not process suspend requests there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1975494213 From rrich at openjdk.org Fri Feb 28 15:27:05 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 28 Feb 2025 15:27:05 GMT Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization causes crash [v3] In-Reply-To: References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com> Message-ID: On Fri, 28 Feb 2025 12:11:05 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 645: >> >>> 643: methodHandle method(current, deopt_sender.interpreter_frame_method()); >>> 644: Bytecode_invoke cur(method, deopt_sender.interpreter_frame_bci()); >>> 645: if (!cur.is_invokedynamic() && MethodHandles::has_member_arg(cur.klass(), cur.name())) { >> >> I was confused with this new condition but I see is the same we have in `vframeArray::unpack_to_stack()`. > > +1 > I see there's also an assertion in `ConstantPool::klass_ref_index_at()`. It might be worth a little comment. Actually I think that there should be an abstraction that hides that detail. Probably `has_member_arg` should be a method of `Bytecode_invoke`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1975594243 From iklam at openjdk.org Fri Feb 28 16:04:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 28 Feb 2025 16:04:40 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" [v2] In-Reply-To: References: Message-ID: > Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. > > I verified with running all CDS tests and the assert is never triggered. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung comment - fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23836/files - new: https://git.openjdk.org/jdk/pull/23836/files/207efa30..414756e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23836&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23836&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23836.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23836/head:pull/23836 PR: https://git.openjdk.org/jdk/pull/23836 From ccheung at openjdk.org Fri Feb 28 16:10:02 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 16:10:02 GMT Subject: RFR: 8350916: Remove misleading warning "Cannot dump shared archive while using shared archive" [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 16:04:40 GMT, Ioi Lam wrote: >> Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments. >> >> I verified with running all CDS tests and the assert is never triggered. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comment - fixed typo Marked as reviewed by ccheung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23836#pullrequestreview-2651184623 From ccheung at openjdk.org Fri Feb 28 17:13:03 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 17:13:03 GMT Subject: Integrated: 8348028: Unable to run gtests with CDS enabled In-Reply-To: References: Message-ID: <8cTzMzXSWY3d09M03BgKaoCUTlMY6xNmyUIxZzG101A=.7f0c6ce9-243f-4558-a865-c8f77b03812f@github.com> On Tue, 25 Feb 2025 00:51:55 GMT, Calvin Cheung wrote: > A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`. > Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`. > > Testing: > > - run gtest with -Xshare:on on linux-x64 > - tier1 This pull request has now been integrated. Changeset: e98df71d Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/e98df71d9c5120fbb73a4c2f49863775fe5db781 Stats: 29 lines in 5 files changed: 12 ins; 14 del; 3 mod 8348028: Unable to run gtests with CDS enabled Reviewed-by: dholmes, iklam, ihse ------------- PR: https://git.openjdk.org/jdk/pull/23758 From ccheung at openjdk.org Fri Feb 28 17:13:02 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 17:13:02 GMT Subject: RFR: 8348028: Unable to run gtests with CDS enabled In-Reply-To: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com> References: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com> Message-ID: On Thu, 27 Feb 2025 12:42:35 GMT, David Holmes wrote: >>> Also, >>> >>> > That presumes you are dealing with a single variant JDK, not one that has both client and server. >>> >>> Is this even relevant anymore? Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed. >> >> Don't we still have support for combining every kind of VM (Except Zero) into the resulting JDK or am I mixing it up with something else? > >> Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed. > > It is still allowed. Whether anyone actually needs it, or uses it is a different matter. The point is you have to match the gtest variant with the jdk variant. > > EDIT: actually is it still allowed? Does the build system require only a single JVM variant be configured? If not how do the different variants actually get built? @dholmes-ora, @iklam, @magicus Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2691149815 From sgehwolf at openjdk.org Fri Feb 28 17:15:05 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 28 Feb 2025 17:15:05 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com> On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated comment OK. I had another look and the Docker test `TestMemoryWithSubgroups.java` does indeed cover this case for cg v1. Please update copyright years to 2025 and this should be good to go (FYI: I'll be away the next week). src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 80: > 78: * The method trims cgroup path from left, until the subgroup > 79: * component is found. The subsystem path will be set to > 80: * the _mount_point joined with the subgroup path. Thanks for the comment. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved. 2025 test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2: > 1: /* > 2: * Copyright (C) 2024, BELLSOFT. All rights reserved. 2025 test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > 1: /* > 2: * Copyright (c) 2024, BELLSOFT. All rights reserved. 2025 ------------- PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2651325697 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746247 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975747062 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748210 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748978 From sgehwolf at openjdk.org Fri Feb 28 17:15:06 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 28 Feb 2025 17:15:06 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: On Fri, 28 Feb 2025 12:19:53 GMT, Matthias Baesken wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comment > > src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2020, 2024, Red Hat Inc. > > Guess this must be 2025 now ? Same for other files ... yes indeed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746706 From matsaave at openjdk.org Fri Feb 28 18:49:00 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 28 Feb 2025 18:49:00 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 00:25:39 GMT, Calvin Cheung wrote: > This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. > Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: > > > [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: > [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST > > Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. > > Passed tiers 1 - 3 testing. Looks good overall but I had some comments. Are there any remaining uses of `is_dumping_invokedynamic()`? I see several cases were replaced and I'm wondering if it's even being used anymore. src/hotspot/share/cds/cdsConfig.cpp line 618: > 616: // Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic > 617: // and dynamic proxies. > 618: bool CDSConfig::is_dumping_method_handles() { This looks like it does the same check as `is_initing_classes_at_dump_time() ` and is very similar to `is_dumping_invokedynamic()`. Maybe you can combine these methods to avoid duplicate code? ------------- PR Review: https://git.openjdk.org/jdk/pull/23546#pullrequestreview-2651539318 PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1975869869 From gziemski at openjdk.org Fri Feb 28 19:54:08 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 28 Feb 2025 19:54:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: <_NgwaL7X0Wail8MgHyql0JSLLkPBbHgrnCuuhdDEpzo=.8a272cee-1077-4c68-a018-5df5c867cc68@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <_NgwaL7X0Wail8MgHyql0JSLLkPBbHgrnCuuhdDEpzo=.8a272cee-1077-4c68-a018-5df5c867cc68@github.com> Message-ID: On Fri, 28 Feb 2025 13:15:29 GMT, Afshin Zafari wrote: >> The wordiness is a bit annoying. The reason that we do this is to separate the global static instance from the implementation, so that we can have many `VMT`s when testing (this is very useful). Do you have a concrete way we can refactor this such that we retain the possibility of having many VMTs and one static instance, whilst reducing the wordiness when using the code? Can this refactoring wait until after integration, as we have more classes following the same pattern that'd need to be refactored? > > The `HeapReserver` and `MemoryFileTracker` classes (in different parts of the code and different PRs) also use the same syntax for it. Here the same style is used to keep similarity in Hotspot code. Right, I didn't like it before, and spoke out against it, and now it is spreading :-) Why do we want to have more than one VMT? If we truly do, then I'm not sure there is anything that could be done here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975940036 From gziemski at openjdk.org Fri Feb 28 19:58:10 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 28 Feb 2025 19:58:10 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Fri, 28 Feb 2025 13:37:32 GMT, Afshin Zafari wrote: >> This is a fairly standard pattern in Hotspot, so personally I'm fine with keeping it as-is. >> >> Here's an incomplete list of pre-existing usages: >> >> ```c++ >> // UL tag list >> enum type { >> __NO_TAG, >> #define LOG_TAG(name) _##name, >> LOG_TAG_LIST >> #undef LOG_TAG >> Count >> }; >> >> >> // enum for figuring positions and size of Symbol::_vm_symbols[] >> enum class vmSymbolID : int { >> // [FIRST_SID ... LAST_SID] is the iteration range for the *valid* symbols. >> // NO_SID is used to indicate an invalid symbol. Some implementation code >> // *may* read _vm_symbols[NO_SID], so it must be a valid array index. >> NO_SID = 0, // exclusive lower limit >> >> #define VM_SYMBOL_ENUM(name, string) VM_SYMBOL_ENUM_NAME_(name), >> VM_SYMBOLS_DO(VM_SYMBOL_ENUM, VM_ALIAS_IGNORE) >> #undef VM_SYMBOL_ENUM >> >> SID_LIMIT, // exclusive upper limit >> >> #define VM_ALIAS_ENUM(name, def) VM_SYMBOL_ENUM_NAME_(name) = VM_SYMBOL_ENUM_NAME_(def), >> VM_SYMBOLS_DO(VM_SYMBOL_IGNORE, VM_ALIAS_ENUM) >> #undef VM_ALIAS_ENUM >> >> FIRST_SID = NO_SID + 1, // inclusive lower limit >> LAST_SID = SID_LIMIT - 1, // inclusive upper limit >> }; >> >> enum class InjectedFieldID : int { >> ALL_INJECTED_FIELDS(DECLARE_INJECTED_FIELD_ENUM) >> MAX_enum >> }; >> >> enum class vmClassID : int { >> #define DECLARE_VM_CLASS(name, symbol) _VM_CLASS_ENUM(name), _VM_CLASS_ENUM(symbol) = _VM_CLASS_ENUM(name), >> VM_CLASSES_DO(DECLARE_VM_CLASS) >> #undef DECLARE_VM_CLASS >> >> LIMIT, // exclusive upper limit >> FIRST = 0, // inclusive upper limit >> LAST = LIMIT - 1 // inclusive upper limit >> }; >> >> enum class CodeBlobType { >> MethodNonProfiled = 0, // Execution level 1 and 4 (non-profiled) nmethods (including native nmethods) >> MethodProfiled = 1, // Execution level 2 and 3 (profiled) nmethods >> NonNMethod = 2, // Non-nmethods like Buffers, Adapters and Runtime Stubs >> All = 3, // All types (No code cache segmentation) >> NumTypes = 4 // Number of CodeBlobTypes >> }; > > There is coding style that the last enum member counts the number of them, like what we have `mt_number_of_tags` in `MemTag` enum. > So, I renamed the last member to `st_number_of_states`. Would it be OK? Or preferred to use constant separately. Just because we do something already in Hotspot, doesn't necessarily mean that we should repeat the pattern going forward. I flagged it and I really don't like it, if you guys are OK with it, I will let it be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1975943416 From schernyshev at openjdk.org Fri Feb 28 20:40:37 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 28 Feb 2025 20:40:37 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v17] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: updated copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/c9391dd4..bae78ff7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15-16 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Fri Feb 28 20:40:38 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 28 Feb 2025 20:40:38 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com> References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com> Message-ID: On Fri, 28 Feb 2025 17:08:19 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comment > > src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved. > > 2025 thanks. done. > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2: > >> 1: /* >> 2: * Copyright (C) 2024, BELLSOFT. All rights reserved. > > 2025 fixed. > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, BELLSOFT. All rights reserved. > > 2025 done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975981433 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980784 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980336 From schernyshev at openjdk.org Fri Feb 28 20:40:38 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 28 Feb 2025 20:40:38 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: On Fri, 28 Feb 2025 17:07:59 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2020, 2024, Red Hat Inc. >> >> Guess this must be 2025 now ? Same for other files ... > > yes indeed. indeed, updated the copyright headers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975983416 From schernyshev at openjdk.org Fri Feb 28 20:47:08 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 28 Feb 2025 20:47:08 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v16] In-Reply-To: References: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com> Message-ID: On Fri, 28 Feb 2025 12:27:13 GMT, Matthias Baesken wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comment > > test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69: > >> 67: /* >> 68: * Less common cases: Containers >> 69: */ > > Not really sure why this comment was added, is it refering to 'container mode' mentioned in the comment above in another file? It's because there are already "Common case: Containers" and "Common case: Host". The old test testCgPathSubstring() and the new test testCgPathToMovedPath() do not belong to "Common case: Host" that comes just before them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975991035 From ccheung at openjdk.org Fri Feb 28 23:04:38 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 23:04:38 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled [v2] In-Reply-To: References: Message-ID: <3G3hMuuSqosYSJLMLNmjMphiLJcGFfeJphResFwptrQ=.7273680e-5f31-490a-abb7-4e303c6c45b5@github.com> > This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled. > Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation: > > > [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: > [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST > > Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function. > > Passed tiers 1 - 3 testing. Calvin Cheung 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: - @matias9927 comments - Merge branch 'master' into 8348322-AOT-cache-InvokeDynamicLinking - @iklam comments - Ioi's suggestions - 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23546/files - new: https://git.openjdk.org/jdk/pull/23546/files/b108cbc2..c41728cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23546&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23546&range=00-01 Stats: 36901 lines in 1360 files changed: 20426 ins; 10832 del; 5643 mod Patch: https://git.openjdk.org/jdk/pull/23546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23546/head:pull/23546 PR: https://git.openjdk.org/jdk/pull/23546 From ccheung at openjdk.org Fri Feb 28 23:04:38 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 28 Feb 2025 23:04:38 GMT Subject: RFR: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 18:46:27 GMT, Matias Saavedra Silva wrote: > Looks good overall but I had some comments. Are there any remaining uses of `is_dumping_invokedynamic()`? I see several cases were replaced and I'm wondering if it's even being used anymore. Yes, it is still being used in several places. > src/hotspot/share/cds/cdsConfig.cpp line 618: > >> 616: // Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic >> 617: // and dynamic proxies. >> 618: bool CDSConfig::is_dumping_method_handles() { > > This looks like it does the same check as `is_initing_classes_at_dump_time() ` and is very similar to `is_dumping_invokedynamic()`. Maybe you can combine these methods to avoid duplicate code? I removed the `CDSConfig::is_initing_classes_at_dump_time()` since the conditions are the same as `CDSConfig::is_dumping_method_handles()`. All the calls to `CDSConfig::is_initing_classes_at_dump_time()` have been updated accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23546#issuecomment-2691685916 PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1976098169