From liach at openjdk.org Tue Apr 1 00:02:19 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 00:02:19 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. They are compiled by any test task, but they can still fail at run-time. That's why you see mostly fails-at-run fixes in the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2767676901 From gziemski at openjdk.org Tue Apr 1 00:52:35 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 00:52:35 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v6] In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 20:45:19 GMT, Stefan Karlsson wrote: > > [pass explicit mem_tag value, skip exec parameter when false](https://github.com/openjdk/jdk/pull/24189/commits/c224bfebab69e572aeacbffb86db51baa8ba8978) > > I think this went to the wrong PR. Ah, thanks I will reveert it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2767745095 From duke at openjdk.org Tue Apr 1 02:02:36 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 1 Apr 2025 02:02:36 GMT Subject: RFR: 8352569: NMT: mmap limits Message-ID: With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. ------------- Commit messages: - 8352569: NMT: mmap limits Changes: https://git.openjdk.org/jdk/pull/24343/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352569 Stats: 1575 lines in 20 files changed: 910 ins; 628 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/24343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24343/head:pull/24343 PR: https://git.openjdk.org/jdk/pull/24343 From fyang at openjdk.org Tue Apr 1 05:06:56 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 1 Apr 2025 05:06:56 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds Message-ID: Hi, please consider this small change. Some riscv extesions are in experimental status due to lack of hardware implementations. They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. To ensure they get some proper correctness test-coverage, this turns on some of them for debug builds. This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. Manually tested on the command line with fastdebug build using qemu-system (kernel-6.11). [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 ------------- Commit messages: - 8353344: RISC-V: Detect and enable several extensions for debug builds Changes: https://git.openjdk.org/jdk/pull/24344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353344 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24344/head:pull/24344 PR: https://git.openjdk.org/jdk/pull/24344 From jpai at openjdk.org Tue Apr 1 05:41:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 05:41:09 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> On Mon, 31 Mar 2025 02:43:45 GMT, tison wrote: >> Hello @tisonkun, is there an issue created for this? https://bugs.openjdk.org/browse/JDK-8304674 against which this PR is linked is for something else. The PR description too isn't clear what this change is about. > > @jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/ Hello @tisonkun, > How can I create an issue for this PR? I don't find some instructions :/ In general, the OpenJDK contribution guide has these details https://openjdk.org/guide/. Typically, depending on the change, you either raise an issue through https://bugreport.java.com/bugreport/ or you create a discussion in the relevant mailing list. A PR is usually created after there's some consensus about the necessity of the change. For the current PR, David notes that this change was previously discussed and it was decided not to pursue further. If you have further questions or need additional inputs, I recommend that you subscribe to the hotspot-runtime-dev mailing list https://mail.openjdk.org/mailman/listinfo/hotspot-runtime-dev and create a discussion there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2768151041 From dholmes at openjdk.org Tue Apr 1 05:45:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 05:45:42 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java Message-ID: This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. Thanks ------------- Commit messages: - 8353349: ProblemList runtime/cds/appcds/SignedJar.java Changes: https://git.openjdk.org/jdk/pull/24345/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353349 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24345/head:pull/24345 PR: https://git.openjdk.org/jdk/pull/24345 From iklam at openjdk.org Tue Apr 1 05:45:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 05:45:42 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 05:36:07 GMT, David Holmes wrote: > This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. > > Thanks LGTM. Thanks for fixing this David! ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24345#pullrequestreview-2731159957 From jpai at openjdk.org Tue Apr 1 05:45:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 05:45:43 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 05:36:07 GMT, David Holmes wrote: > This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. > > Thanks This looks reasonable and trivial to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24345#pullrequestreview-2731161153 From dholmes at openjdk.org Tue Apr 1 05:45:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 05:45:43 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 05:39:21 GMT, Ioi Lam wrote: >> This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. >> >> Thanks > > LGTM. Thanks for fixing this David! Thanks for the reviews @iklam and @jaikiran ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24345#issuecomment-2768154596 From dholmes at openjdk.org Tue Apr 1 05:45:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 05:45:43 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 05:36:07 GMT, David Holmes wrote: > This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. > > Thanks Interesting there is no rule to match this file to hotspot-dev. ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24345#issuecomment-2768157238 From dholmes at openjdk.org Tue Apr 1 05:45:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 05:45:43 GMT Subject: Integrated: 8353349: ProblemList runtime/cds/appcds/SignedJar.java In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 05:36:07 GMT, David Holmes wrote: > This failing test is causing a lot of noise in our CI in tiers 2 and 5, so adding it to the ProblemList until it can be resolved. > > Thanks This pull request has now been integrated. Changeset: 8b4e190b Author: David Holmes URL: https://git.openjdk.org/jdk/commit/8b4e190bc8aa5499f96dbe2de01cf34ddcdb67a7 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8353349: ProblemList runtime/cds/appcds/SignedJar.java Reviewed-by: iklam, jpai ------------- PR: https://git.openjdk.org/jdk/pull/24345 From stuefe at openjdk.org Tue Apr 1 06:33:27 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 1 Apr 2025 06:33:27 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Mon, 31 Mar 2025 15:41:27 GMT, Ioi Lam wrote: >> Please consider. >> >> This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I need this mechanism for some future GC work. >> >> Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag. >> >> It also adds a new, rather basic, gtest. >> >> Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that. >> >> ---- >> >> Testing: >> - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes >> - I ran all runtime/cds tests on Linux x64 >> - GHAs > > src/hotspot/share/cds/lambdaProxyClassDictionary.cpp line 93: > >> 91: while (k != nullptr) { >> 92: cl->do_klass(k); >> 93: k = k->next_link(); > > When do you plan to use this API? `k->next_link()` will change if `k` has been loaded in runtime, so you can no longer use it to find other archived lambda proxy classes. I will call this after the CDS archive has been mapped, at the same time as PrintSharedArchiveAndExit would have been called. But I would like this function to work at any time. But above all, it is very paramount that this technique finds me all classes that are in this archive and not loaded via the normal dynamic class loading path. I also need this method to work reliably also with any improvements ongoing (e.g. JEP 483). Is there a better way? Looking into the code, I see that this method (scanning classes via Klass::next_link) is also used to implement LambdaProxyClassArchive.find()/LambdaProxyClassDictionary::find_lambda_proxy_class. Which uses the linked list precomputed with AdjustLambdaProxyClassInfo. It uses Klass::next_link, but that is used by the CLDG to tie classes of the same loader together. How does this work? Would LambdaProxyClassArchive.find() (and thus LambdaMetaFactory.metafactory()) not have the same problem? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2022229593 From iklam at openjdk.org Tue Apr 1 06:38:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 06:38:07 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Tue, 1 Apr 2025 06:30:20 GMT, Thomas Stuefe wrote: >> src/hotspot/share/cds/lambdaProxyClassDictionary.cpp line 93: >> >>> 91: while (k != nullptr) { >>> 92: cl->do_klass(k); >>> 93: k = k->next_link(); >> >> When do you plan to use this API? `k->next_link()` will change if `k` has been loaded in runtime, so you can no longer use it to find other archived lambda proxy classes. > > I will call this after the CDS archive has been mapped, at the same time as PrintSharedArchiveAndExit would have been called. But I would like this function to work at any time. > > But above all, it is very paramount that this technique finds me all classes that are in this archive and not loaded via the normal dynamic class loading path. I also need this method to work reliably also with any improvements ongoing (e.g. JEP 483). Is there a better way? > > Looking into the code, I see that this method (scanning classes via Klass::next_link) is also used to implement LambdaProxyClassArchive.find()/LambdaProxyClassDictionary::find_lambda_proxy_class. Which uses the linked list precomputed with AdjustLambdaProxyClassInfo. It uses Klass::next_link, but that is used by the CLDG to tie classes of the same loader together. How does this work? Would LambdaProxyClassArchive.find() (and thus LambdaMetaFactory.metafactory()) not have the same problem? Once the lambda proxy class is loaded, it's removed from the LambdaProxyClassDictionary, so we won't find it (and try to load it again). This is intended. Did you file an RFE for that explains what you intend to do with such an iterator in the future? We should understand the requirements before making this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2022234466 From stuefe at openjdk.org Tue Apr 1 07:08:29 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 1 Apr 2025 07:08:29 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Tue, 1 Apr 2025 06:35:13 GMT, Ioi Lam wrote: >> I will call this after the CDS archive has been mapped, at the same time as PrintSharedArchiveAndExit would have been called. But I would like this function to work at any time. >> >> But above all, it is very paramount that this technique finds me all classes that are in this archive and not loaded via the normal dynamic class loading path. I also need this method to work reliably also with any improvements ongoing (e.g. JEP 483). Is there a better way? >> >> Looking into the code, I see that this method (scanning classes via Klass::next_link) is also used to implement LambdaProxyClassArchive.find()/LambdaProxyClassDictionary::find_lambda_proxy_class. Which uses the linked list precomputed with AdjustLambdaProxyClassInfo. It uses Klass::next_link, but that is used by the CLDG to tie classes of the same loader together. How does this work? Would LambdaProxyClassArchive.find() (and thus LambdaMetaFactory.metafactory()) not have the same problem? > > Once the lambda proxy class is loaded, it's removed from the LambdaProxyClassDictionary, so we won't find it (and try to load it again). This is intended. > > Did you file an RFE for that explains what you intend to do with such an iterator in the future? We should understand the requirements before making this change. No, not yet, though I have talked with many people about this, to positive feedback. I will put this in writing soon. The gist of this is: I have a prototype called "KLUT" (KlassLookupTable), which pre-computes a 32-bit token per Klass and puts that into a lookup table with the narrowKlass as index (remember, for COH, narrowKlass is really an index, 1 2 3 4 5). That token contains a condensed subset of information from Klass. The token is then used to get type information for oop iteration in GC. That avoids having to access Klass during GC, in fact, we don't even need to decode the nKlass. All of that drastically reduces cache misses during GC, since we don't have to pick type information from a very sparse Klass but load a 32-bit value from a very condensed table. It practically takes out type information loading as a source of cache misses from the equation. To get the fullest benefit from this optimization, I pre-generate these tokens on Class loading. I could calculate them on demand, too, but that would add another branch into the hot path of oop iteration. I would rather avoid that. So, I need to ensure these tokens are generated for every Klass for which I will find objects in the heap. Hence this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2022267672 From dholmes at openjdk.org Tue Apr 1 07:12:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 07:12:28 GMT Subject: RFR: 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 04:28:49 GMT, Calvin Cheung wrote: > go back 4 instead of 5 slashes and then checking for "/jre/lib"; But we got rid of the `jre` directory years ago. ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2768397856 From mbaesken at openjdk.org Tue Apr 1 07:18:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 1 Apr 2025 07:18:18 GMT Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v6] In-Reply-To: References: Message-ID: <2610j3DnhBsX3Wry9hBLV3tzsXknlWYtPWUUN9DkojU=.f569ed0d-324a-4984-95e2-b38d4052de77@github.com> On Fri, 28 Mar 2025 17:04:03 GMT, Joachim Kern wrote: >> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable. >> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`. >> >> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B). >> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test. >> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`. >> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH` >> >> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`. >> So my proposal is to skip this sub test for aix and musl. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > add symlink comment again, but without solaris Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24055#pullrequestreview-2731702957 From jsjolen at openjdk.org Tue Apr 1 07:41:12 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 1 Apr 2025 07:41:12 GMT Subject: RFR: 8352569: NMT: mmap limits In-Reply-To: References: Message-ID: <0xN9DcOsMDVQMhh2GPgC2YrteWJ4vS4nzHVesUJypFI=.bcff24b6-c72b-481a-849d-c42da6dac3ac@github.com> On Tue, 1 Apr 2025 01:57:59 GMT, Rui Li wrote: > With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. > > It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. Hi, This is such a large change, it's going to need a much larger description to go with it. Thanks, Johan ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2768462453 From jkern at openjdk.org Tue Apr 1 08:12:24 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 1 Apr 2025 08:12:24 GMT Subject: Integrated: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:47:44 GMT, Joachim Kern wrote: > The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable. > Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`. > > The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B). > The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test. > Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`. > Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH` > > Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`. > So my proposal is to skip this sub test for aix and musl. This pull request has now been integrated. Changeset: 196334fc Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/196334fc395c63e59167ccd85415d8e1d2bcb705 Stats: 59 lines in 1 file changed: 4 ins; 40 del; 15 mod 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle Reviewed-by: clanger, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/24055 From azafari at openjdk.org Tue Apr 1 08:30:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 1 Apr 2025 08:30:36 GMT Subject: Integrated: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari wrote: > With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. > Tests: > linux-x64-debug, gtest:NMT* and runtime/NMT* This pull request has now been integrated. Changeset: aff5aa72 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/aff5aa72bbf4ecea614339483581093a67efa265 Stats: 27 lines in 14 files changed: 6 ins; 1 del; 20 mod 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag Reviewed-by: jsjolen, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/23770 From azafari at openjdk.org Tue Apr 1 08:30:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 1 Apr 2025 08:30:36 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag [v5] In-Reply-To: <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com> References: <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com> Message-ID: On Fri, 7 Mar 2025 16:06:32 GMT, Afshin Zafari wrote: >> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. >> Tests: >> linux-x64-debug, gtest:NMT* and runtime/NMT* > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'origin/master' into _8350566_size_par_set_tag > - new fix. > - fixed build problem. > - ReservedSpace is accepted as param. > - applied also to VMT. > - 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag GHA failures are not relevant. Thanks for reviews @jdksjolen and @gerard-ziemski. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2768577688 From jkern at openjdk.org Tue Apr 1 09:23:32 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 1 Apr 2025 09:23:32 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH Message-ID: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. ------------- Commit messages: - JDK-8352935 Changes: https://git.openjdk.org/jdk/pull/24351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352935 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351 PR: https://git.openjdk.org/jdk/pull/24351 From varadam at openjdk.org Tue Apr 1 10:30:56 2025 From: varadam at openjdk.org (Varada M) Date: Tue, 1 Apr 2025 10:30:56 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: > AIX changes for attach API to support arbitrary length arguments and the streaming output support. > serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes > > tier1, tier2 and tier3 testing is successful with fastdebug level > > JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) Varada M has updated the pull request incrementally with one additional commit since the last revision: 8352392: AIX: implement attach API v2 and streaming output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24177/files - new: https://git.openjdk.org/jdk/pull/24177/files/d22f0ab9..234f6d17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=02-03 Stats: 20 lines in 2 files changed: 1 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177 PR: https://git.openjdk.org/jdk/pull/24177 From varadam at openjdk.org Tue Apr 1 10:35:20 2025 From: varadam at openjdk.org (Varada M) Date: Tue, 1 Apr 2025 10:35:20 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v3] In-Reply-To: References: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com> Message-ID: On Mon, 31 Mar 2025 10:16:31 GMT, Martin Doerr wrote: >> Varada M has updated the pull request incrementally with two additional commits since the last revision: >> >> - updated copyright header >> - removed StreamingOutputTest.java from problem list > > src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196: > >> 194: } >> 195: } >> 196: > > Same here. Hi Martin, I have added the indentation fix and comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2022594632 From coleenp at openjdk.org Tue Apr 1 11:59:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Apr 2025 11:59:19 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke wrote: >> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible. >> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter. >> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed. >> - Some small code shufflings. >> >> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs: >> without-OMT: 773.3 ms >> with-OMT: 797.28 ms >> >> That is still a regression of ~3% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Include objectMonitor.inline.hpp Sorry for the delay, the performance testing took a while. I ran the old and new DaCapo benchmarks on a version of the VM with quick_enter calling try_spin rather than try_lock to see if the try_spin had any negative effects without UseObjectMonitorTable. I ran on our standard linux-x64 and linux-aarch64 machines. It had no significant effect on performance except a 3.7 improvement for old DaCapo xalan on linux-aarch64. I think this should be checked in with RFEs for further improvements. I had a couple of cleanups in this area that I'm waiting for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2769116156 From mdoerr at openjdk.org Tue Apr 1 12:22:20 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 1 Apr 2025 12:22:20 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v3] In-Reply-To: References: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com> Message-ID: On Tue, 1 Apr 2025 10:32:55 GMT, Varada M wrote: >> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196: >> >>> 194: } >>> 195: } >>> 196: >> >> Same here. > > Hi Martin, I have added the indentation fix and comment Thanks! I think it's good. Let's wait for @JoKern65 's review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2022743745 From gziemski at openjdk.org Tue Apr 1 12:31:47 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 12:31:47 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v7] In-Reply-To: References: Message-ID: <7JUxQf4guO24CoTfkwY7kOaG3G4kiRAFoQszrI8Dax0=.f5620728-e8ec-4324-8dca-e4685faab363@github.com> > This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): > > proposed: > > time:72,642,827[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > existing code: > > time:73,085,446[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. > > The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). > > This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). > > To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: revert last checkin - wrong issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24189/files - new: https://git.openjdk.org/jdk/pull/24189/files/c224bfeb..962dd9fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=05-06 Stats: 30 lines in 16 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/24189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189 PR: https://git.openjdk.org/jdk/pull/24189 From gziemski at openjdk.org Tue Apr 1 12:38:14 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 12:38:14 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v7] In-Reply-To: <7JUxQf4guO24CoTfkwY7kOaG3G4kiRAFoQszrI8Dax0=.f5620728-e8ec-4324-8dca-e4685faab363@github.com> References: <7JUxQf4guO24CoTfkwY7kOaG3G4kiRAFoQszrI8Dax0=.f5620728-e8ec-4324-8dca-e4685faab363@github.com> Message-ID: <3Ch5fIr60AvQytwf7DJntzl29_hRSLa7dgVyxPJdTZI=.f0d53733-e073-4524-af57-e97c28614296@github.com> On Tue, 1 Apr 2025 12:31:47 GMT, Gerard Ziemski wrote: >> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): >> >> proposed: >> >> time:72,642,827[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> existing code: >> >> time:73,085,446[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. >> >> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). >> >> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). >> >> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > revert last checkin - wrong issue > I took a deeper look at the proposed patch and I'm still not convinced that this is a net positive cleanup. The added shared code now contains new branches to sort out the difference between malloc and realloc. > > FWIW, I poked around at the original code to see what it would look to go the other way. Push NMT-specific code deeper down so that the higher-level functions get clearer and maybe easier to maintain. If you want to take a look, I've a branch for that here: [master...stefank:jdk:24189_alternative](https://github.com/openjdk/jdk/compare/master...stefank:jdk:24189_alternative) Taking a look (very hopeful) ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769214952 From gziemski at openjdk.org Tue Apr 1 12:51:03 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 12:51:03 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: References: Message-ID: > This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): > > proposed: > > time:72,642,827[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > existing code: > > time:73,085,446[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. > > The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). > > This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). > > To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: revert last checkin - wrong issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24189/files - new: https://git.openjdk.org/jdk/pull/24189/files/962dd9fb..72603f67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=06-07 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189 PR: https://git.openjdk.org/jdk/pull/24189 From coleenp at openjdk.org Tue Apr 1 13:07:22 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Apr 2025 13:07:22 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: References: Message-ID: <_g5Sxy7_Kt63DRdcJzflGiFQILhrCuoTFlVZZYrO9zc=.7d43bd40-5691-497e-be9b-e3a7fad62d27@github.com> On Tue, 1 Apr 2025 12:51:03 GMT, Gerard Ziemski wrote: >> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): >> >> proposed: >> >> time:72,642,827[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> existing code: >> >> time:73,085,446[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. >> >> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). >> >> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). >> >> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > revert last checkin - wrong issue This looks really reasonable. The new names for the refactoring are good. Also I think I saw that you ran tier1 on this change. You should run tier1-4 at least. src/hotspot/share/nmt/nmtPreInit.hpp line 270: > 268: // *rc contains the return address. > 269: static bool handle_malloc(void** rc, size_t size) { > 270: size = MAX2((size_t)1, size); // malloc(0) Not this change, but why are these functions in the hpp file? They seem more appropriate in the cpp file. src/hotspot/share/runtime/os.cpp line 632: > 630: // Special handling for NMT preinit phase before arguments are parsed > 631: void* rc = nullptr; > 632: if (NMTPreInit::handle_malloc(&rc, size)) { So it looks like this was the only call to handle_malloc. Is it now unused since malloc and realloc() call this function? ------------- PR Review: https://git.openjdk.org/jdk/pull/24189#pullrequestreview-2732615079 PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769294583 PR Review Comment: https://git.openjdk.org/jdk/pull/24189#discussion_r2022814336 PR Review Comment: https://git.openjdk.org/jdk/pull/24189#discussion_r2022811525 From gziemski at openjdk.org Tue Apr 1 13:14:13 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 13:14:13 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: <_g5Sxy7_Kt63DRdcJzflGiFQILhrCuoTFlVZZYrO9zc=.7d43bd40-5691-497e-be9b-e3a7fad62d27@github.com> References: <_g5Sxy7_Kt63DRdcJzflGiFQILhrCuoTFlVZZYrO9zc=.7d43bd40-5691-497e-be9b-e3a7fad62d27@github.com> Message-ID: On Tue, 1 Apr 2025 13:04:45 GMT, Coleen Phillimore wrote: > Also I think I saw that you ran tier1 on this change. You should run tier1-4 at least. Absolutely, I usually run tier1-5, but even getting to tier1 was quite a challenge, so I stopped there for a moment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769315136 From gziemski at openjdk.org Tue Apr 1 13:26:22 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 13:26:22 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v7] In-Reply-To: <3Ch5fIr60AvQytwf7DJntzl29_hRSLa7dgVyxPJdTZI=.f0d53733-e073-4524-af57-e97c28614296@github.com> References: <7JUxQf4guO24CoTfkwY7kOaG3G4kiRAFoQszrI8Dax0=.f5620728-e8ec-4324-8dca-e4685faab363@github.com> <3Ch5fIr60AvQytwf7DJntzl29_hRSLa7dgVyxPJdTZI=.f0d53733-e073-4524-af57-e97c28614296@github.com> Message-ID: On Tue, 1 Apr 2025 12:35:11 GMT, Gerard Ziemski wrote: > I took a deeper look at the proposed patch and I'm still not convinced that this is a net positive cleanup. The added shared code now contains new branches to sort out the difference between malloc and realloc. > > FWIW, I poked around at the original code to see what it would look to go the other way. Push NMT-specific code deeper down so that the higher-level functions get clearer and maybe easier to maintain. If you want to take a look, I've a branch for that here: [master...stefank:jdk:24189_alternative](https://github.com/openjdk/jdk/compare/master...stefank:jdk:24189_alternative) I see what you were looking for - you have split and shuffled the code around into logical units. It is definitively an improvement over the existing code and I do like it, but it is not addressing at all the reason I personally started to look into this, which was to share as much code as possible between realloc and malloc (or just outright implement malloc in terms of realloc), so that any NMT interaction could be reduced to just one common path. Still, I think this is a definite improvement and I would personally take it. Thank you for all your work! Can we get this into a PR please? Also, one thing in your PR would be to change either: `realloc_impl` --> `realloc_inner` or: `malloc_inner` --> `malloc_impl` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769336050 From gziemski at openjdk.org Tue Apr 1 13:26:26 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 13:26:26 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: <_g5Sxy7_Kt63DRdcJzflGiFQILhrCuoTFlVZZYrO9zc=.7d43bd40-5691-497e-be9b-e3a7fad62d27@github.com> References: <_g5Sxy7_Kt63DRdcJzflGiFQILhrCuoTFlVZZYrO9zc=.7d43bd40-5691-497e-be9b-e3a7fad62d27@github.com> Message-ID: On Tue, 1 Apr 2025 13:03:34 GMT, Coleen Phillimore wrote: >> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: >> >> revert last checkin - wrong issue > > src/hotspot/share/nmt/nmtPreInit.hpp line 270: > >> 268: // *rc contains the return address. >> 269: static bool handle_malloc(void** rc, size_t size) { >> 270: size = MAX2((size_t)1, size); // malloc(0) > > Not this change, but why are these functions in the hpp file? They seem more appropriate in the cpp file. A good question, I was wondering the same. I personally don't know. > src/hotspot/share/runtime/os.cpp line 632: > >> 630: // Special handling for NMT preinit phase before arguments are parsed >> 631: void* rc = nullptr; >> 632: if (NMTPreInit::handle_malloc(&rc, size)) { > > So it looks like this was the only call to handle_malloc. Is it now unused since malloc and realloc() call this function? Correct, we would no longer need to use this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24189#discussion_r2022847441 PR Review Comment: https://git.openjdk.org/jdk/pull/24189#discussion_r2022845618 From gziemski at openjdk.org Tue Apr 1 13:31:26 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 13:31:26 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: References: Message-ID: <0JpXVQbwu2-DhRL8ZyGhq4sBYMv06mwRcrq7p7xj_d0=.b5dc371e-78c5-436c-ab64-fde1b2177666@github.com> On Tue, 1 Apr 2025 12:51:03 GMT, Gerard Ziemski wrote: >> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): >> >> proposed: >> >> time:72,642,827[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> existing code: >> >> time:73,085,446[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. >> >> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). >> >> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). >> >> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > revert last checkin - wrong issue Thank you for the review Coleen, unfortunately this looks like a dead end, since Johan and Stefan do not see this as an improvement. Stefan has suggested an alternate impl, which does clean up things nicely, even though it does not address at all my concerns and reasons for working on this fix. Is that correct? Johan, Stefan, you are NO on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769364553 From aboldtch at openjdk.org Tue Apr 1 14:38:52 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 1 Apr 2025 14:38:52 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke wrote: >> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible. >> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter. >> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed. >> - Some small code shufflings. >> >> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs: >> without-OMT: 773.3 ms >> with-OMT: 797.28 ms >> >> That is still a regression of ~3% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Include objectMonitor.inline.hpp If we have ran the performance evaluation, and adding the extra try_spin does not hurt other workloads / -UseObjectMonitorTable. I am fine with this change. As @coleenp mentions, a lot of the cache setter can be cleaned up in future RFEs. And eventually make it a property of C2 only. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24098#pullrequestreview-2732938165 From stefank at openjdk.org Tue Apr 1 15:43:19 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 1 Apr 2025 15:43:19 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v7] In-Reply-To: References: <7JUxQf4guO24CoTfkwY7kOaG3G4kiRAFoQszrI8Dax0=.f5620728-e8ec-4324-8dca-e4685faab363@github.com> <3Ch5fIr60AvQytwf7DJntzl29_hRSLa7dgVyxPJdTZI=.f0d53733-e073-4524-af57-e97c28614296@github.com> Message-ID: <4RWf3Sa05Edflf-vmW-WSfhb3e-83aO9W9KYVpBPYjQ=.7b1470ad-5e87-43a6-a43a-ac36a91a3f29@github.com> On Tue, 1 Apr 2025 13:18:37 GMT, Gerard Ziemski wrote: > > I took a deeper look at the proposed patch and I'm still not convinced that this is a net positive cleanup. The added shared code now contains new branches to sort out the difference between malloc and realloc. > > FWIW, I poked around at the original code to see what it would look to go the other way. Push NMT-specific code deeper down so that the higher-level functions get clearer and maybe easier to maintain. If you want to take a look, I've a branch for that here: [master...stefank:jdk:24189_alternative](https://github.com/openjdk/jdk/compare/master...stefank:jdk:24189_alternative) > > I see what you were looking for - you have split and shuffled the code around into logical units. It is definitively an improvement over the existing code and I do like it, but it is not addressing at all the reason I personally started to look into this, which was to share as much code as possible between realloc and malloc (or just outright implement malloc in terms of realloc), so that any NMT interaction could be reduced to just one common path. > > Still, I think this is a definite improvement and I would personally take it. > > Thank you for all your work! Can we get this into a PR please? Sure. But let's see what other people delving into this area think. > > Also, one thing in your PR would be to change either: > > `realloc_impl` --> `realloc_inner` > > or: > > `malloc_inner` --> `malloc_impl` Thanks for finding that. I went back-and-forth between the two names and ended up using both. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769787148 From stuefe at openjdk.org Tue Apr 1 15:43:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 1 Apr 2025 15:43:20 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: References: Message-ID: <-ZsN9fFcOfagHRCOeMKvwoMbS8P-8EyuaosKd6wb668=.242dae14-ded7-45b3-9683-675f7aeff36d@github.com> On Tue, 1 Apr 2025 12:51:03 GMT, Gerard Ziemski wrote: >> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): >> >> proposed: >> >> time:72,642,827[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> existing code: >> >> time:73,085,446[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. >> >> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). >> >> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). >> >> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > revert last checkin - wrong issue I have to think this through. I know that this code can be deceptively tricky, and looks deceptively simple, but a lot of thought has been put into the details of the existing implementation. Plus, this code is not well covered with regression tests. For those reasons alone, I'd rather avoid changes like these. They save 36 lines of code, but the simplicity here is really subjective, and the review work needed to be put into this is time we probably won't ever get back from these simplifications. Just my 5 cent. I am not against refactoring code, far from it, but there are oh so many places in the JVM that would benefit more from some cleanup love (e.g. hotspot arenas). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769796707 From rkennke at openjdk.org Tue Apr 1 15:51:27 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 1 Apr 2025 15:51:27 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 14:36:03 GMT, Axel Boldt-Christmas wrote: > If we have ran the performance evaluation, and adding the extra try_spin does not hurt other workloads / -UseObjectMonitorTable. I am fine with this change. > > As @coleenp mentions, a lot of the cache setter can be cleaned up in future RFEs. And eventually make it a property of C2 only. No more concerns about the setting of BasicLock cache in enter? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2769825016 From stefank at openjdk.org Tue Apr 1 15:52:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 1 Apr 2025 15:52:21 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: <0JpXVQbwu2-DhRL8ZyGhq4sBYMv06mwRcrq7p7xj_d0=.b5dc371e-78c5-436c-ab64-fde1b2177666@github.com> References: <0JpXVQbwu2-DhRL8ZyGhq4sBYMv06mwRcrq7p7xj_d0=.b5dc371e-78c5-436c-ab64-fde1b2177666@github.com> Message-ID: <0F2NSYixMIR8XWHCRoJOtBE4aoGnG8Rx_dCmoB3aack=.f10248e2-74b1-47dd-9839-8c7b12aee32c@github.com> On Tue, 1 Apr 2025 13:28:06 GMT, Gerard Ziemski wrote: > Thank you for the review Coleen, unfortunately this looks like a dead end, since Johan and Stefan do not see this as an improvement. Stefan has suggested an alternate impl, which does clean up things nicely, even though it does not address at all my concerns and reasons for working on this fix. > > Is that correct? Johan, Stefan, you are NO on this? Right. I don't think the goal of having 1 code path here is currently leading to a cleanup that makes the code easier to read or maintain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769830996 From gziemski at openjdk.org Tue Apr 1 15:59:50 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 15:59:50 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: References: Message-ID: <16V8WmH-RS7DYlJZ9Q_DaL5xvT8cmWhPiVOugNvhvMw=.4afcb119-23a2-482e-a161-a8a8c049043d@github.com> On Tue, 1 Apr 2025 12:51:03 GMT, Gerard Ziemski wrote: >> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): >> >> proposed: >> >> time:72,642,827[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> existing code: >> >> time:73,085,446[ns] >> [samples:807,804] [NMT headers:382,064] >> [malloc#:588,703] [realloc#:12,462] [free#:206,639] >> memory requested:57,274,288 bytes, allocated:69,004,800 bytes >> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] >> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. >> >> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). >> >> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). >> >> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > revert last checkin - wrong issue OK, closing this one. Hopefully, we can use Stefan's alternative to move forward here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2769850455 From shade at openjdk.org Tue Apr 1 15:59:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 1 Apr 2025 15:59:43 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Tue, 25 Mar 2025 09:15:38 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix (friendly reminder) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2769849090 From gziemski at openjdk.org Tue Apr 1 15:59:50 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 1 Apr 2025 15:59:50 GMT Subject: Withdrawn: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 10:57:41 GMT, Gerard Ziemski wrote: > This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786): > > proposed: > > time:72,642,827[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > existing code: > > time:73,085,446[ns] > [samples:807,804] [NMT headers:382,064] > [malloc#:588,703] [realloc#:12,462] [free#:206,639] > memory requested:57,274,288 bytes, allocated:69,004,800 bytes > malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%] > Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs. > > The performance is virtually the same where I sampled each test 30 times and took the best (the shortest). > > This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines). > > To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24189 From coleenp at openjdk.org Tue Apr 1 16:02:34 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Apr 2025 16:02:34 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 15:47:25 GMT, Roman Kennke wrote: > No more concerns about the setting of BasicLock cache in enter? No, I think the bug that I ran into wasn't this, so no more concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2769851176 From rkennke at openjdk.org Tue Apr 1 16:02:35 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 1 Apr 2025 16:02:35 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 15:57:20 GMT, Coleen Phillimore wrote: > > No more concerns about the setting of BasicLock cache in enter? > > No, I think the bug that I ran into wasn't this, so no more concerns. Ok, good. @xmas92 also had concerns about doing that BL caching in enter that sounded like he wanted to hold this part back for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2769858615 From iklam at openjdk.org Tue Apr 1 16:35:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 16:35:38 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2] In-Reply-To: References: Message-ID: > When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. > > In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Refactored CollectClassesForLinking for simplification - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Reverted some fixes in systemDictionaryShared.cpp that causes test failures - 8353014: Exclude AOT tooling classes from AOT cache ------------- Changes: https://git.openjdk.org/jdk/pull/24272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=01 Stats: 308 lines in 14 files changed: 224 ins; 49 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/24272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24272/head:pull/24272 PR: https://git.openjdk.org/jdk/pull/24272 From stuefe at openjdk.org Tue Apr 1 17:32:23 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 1 Apr 2025 17:32:23 GMT Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, so that we only have 1 code path [v8] In-Reply-To: <16V8WmH-RS7DYlJZ9Q_DaL5xvT8cmWhPiVOugNvhvMw=.4afcb119-23a2-482e-a161-a8a8c049043d@github.com> References: <16V8WmH-RS7DYlJZ9Q_DaL5xvT8cmWhPiVOugNvhvMw=.4afcb119-23a2-482e-a161-a8a8c049043d@github.com> Message-ID: <73Jr9k_aFbvZUc3UqJTdTzA7o1PU7c_P1DYoUBWNVXA=.8ce52cb3-e242-4943-be1f-9f148b1fd102@github.com> On Tue, 1 Apr 2025 15:57:02 GMT, Gerard Ziemski wrote: > OK, closing this one. Hopefully, we can use Stefan's alternative to move forward here. @gerard-ziemski you have done a lot of very good cleanups over the last years. Sorry for being negative on this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2770189927 From coleenp at openjdk.org Tue Apr 1 17:40:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Apr 2025 17:40:20 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Tue, 1 Apr 2025 07:03:39 GMT, Thomas Stuefe wrote: >> Once the lambda proxy class is loaded, it's removed from the LambdaProxyClassDictionary, so we won't find it (and try to load it again). This is intended. >> >> Did you file an RFE for that explains what you intend to do with such an iterator in the future? We should understand the requirements before making this change. > > No, not yet, though I have talked with many people about this, to positive feedback. I will put this in writing soon. > > The gist of this is: I have a prototype called "KLUT" (KlassLookupTable), which pre-computes a 32-bit token per Klass and puts that into a lookup table with the narrowKlass as index (remember, for COH, narrowKlass is really an index, 1 2 3 4 5). > > That token contains a condensed subset of information from Klass. The token is then used to get type information for oop iteration in GC. That avoids having to access Klass during GC, in fact, we don't even need to decode the nKlass. > > All of that drastically reduces cache misses during GC, since we don't have to pick type information from a very sparse Klass but load a 32-bit value from a very condensed table. It practically takes out type information loading as a source of cache misses from the equation. > > To get the fullest benefit from this optimization, I pre-generate these tokens on Class loading. I could calculate them on demand, too, but that would add another branch into the hot path of oop iteration. I would rather avoid that. > > So, I need to ensure these tokens are generated for every Klass for which I will find objects in the heap. Hence this PR. I'm confused by this. next_link is the next link in the ClassLoaderData klasses list. Why is this in LambdaProxyClassDictionary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2023379697 From iklam at openjdk.org Tue Apr 1 18:01:45 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 18:01:45 GMT Subject: RFR: 8353330: Test runtime/cds/appcds/SignedJar.java fails in CDSHeapVerifier Message-ID: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> Java core-lib changes in [JDK-8339280](https://bugs.openjdk.org/browse/JDK-8339280) for code-signing causes more java.lang.invoke classes to be initialized in the assembly phase. Static fields like `java/lang/invoke/MethodHandleImpl$ArrayAccessor::OBJECT_ARRAY_SETTER` are just cached MethodHandles whose object identity doesn't matter. So it's OK for them to be stored into the AOT cache. Therefore, I added them to the CDSHeapVerifier exclusion lists. ------------- Commit messages: - 8353330: Test runtime/cds/appcds/SignedJar.java fails in CDSHeapVerifier Changes: https://git.openjdk.org/jdk/pull/24363/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353330 Stats: 14 lines in 2 files changed: 11 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24363/head:pull/24363 PR: https://git.openjdk.org/jdk/pull/24363 From stuefe at openjdk.org Tue Apr 1 18:09:08 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 1 Apr 2025 18:09:08 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Tue, 1 Apr 2025 17:37:33 GMT, Coleen Phillimore wrote: >> No, not yet, though I have talked with many people about this, to positive feedback. I will put this in writing soon. >> >> The gist of this is: I have a prototype called "KLUT" (KlassLookupTable), which pre-computes a 32-bit token per Klass and puts that into a lookup table with the narrowKlass as index (remember, for COH, narrowKlass is really an index, 1 2 3 4 5). >> >> That token contains a condensed subset of information from Klass. The token is then used to get type information for oop iteration in GC. That avoids having to access Klass during GC, in fact, we don't even need to decode the nKlass. >> >> All of that drastically reduces cache misses during GC, since we don't have to pick type information from a very sparse Klass but load a 32-bit value from a very condensed table. It practically takes out type information loading as a source of cache misses from the equation. >> >> To get the fullest benefit from this optimization, I pre-generate these tokens on Class loading. I could calculate them on demand, too, but that would add another branch into the hot path of oop iteration. I would rather avoid that. >> >> So, I need to ensure these tokens are generated for every Klass for which I will find objects in the heap. Hence this PR. > > I'm confused by this. next_link is the next link in the ClassLoaderData klasses list. Why is this in LambdaProxyClassDictionary? This PR only moves code around, at least here. I am unsure why this code uses next_link. My understanding from reading the code and from Ioi's explanation is that LambdaProxyClassDictionary re-uses the next_link linking mechanism for linking CDS proxy classes together before they are loaded; so they are not yet part of the CLDG and this use does not conflict with the use of next_link in the CLDG. I may be wrong though and am happy to be corrected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2023425740 From iklam at openjdk.org Tue Apr 1 18:09:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 18:09:09 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: On Tue, 1 Apr 2025 18:01:01 GMT, Thomas Stuefe wrote: >> I'm confused by this. next_link is the next link in the ClassLoaderData klasses list. Why is this in LambdaProxyClassDictionary? > > This PR only moves code around, at least here. I am unsure why this code uses next_link. My understanding from reading the code and from Ioi's explanation is that LambdaProxyClassDictionary re-uses the next_link linking mechanism for linking CDS proxy classes together before they are loaded; so they are not yet part of the CLDG and this use does not conflict with the use of next_link in the CLDG. > > I may be wrong though and am happy to be corrected. If we want this PR to proceed we should restructure the CDS code to use a different mechanism to iterate over the unloaded proxy classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2023435083 From iklam at openjdk.org Tue Apr 1 18:09:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 1 Apr 2025 18:09:09 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> Message-ID: <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> On Tue, 1 Apr 2025 18:03:16 GMT, Ioi Lam wrote: >> This PR only moves code around, at least here. I am unsure why this code uses next_link. My understanding from reading the code and from Ioi's explanation is that LambdaProxyClassDictionary re-uses the next_link linking mechanism for linking CDS proxy classes together before they are loaded; so they are not yet part of the CLDG and this use does not conflict with the use of next_link in the CLDG. >> >> I may be wrong though and am happy to be corrected. > > If we want this PR to proceed we should restructure the CDS code to use a different mechanism to iterate over the unloaded proxy classes. However, I still don't understand why this API is necessary for "KLUT" -- why do you need to look at all the classes in the CDS archive, including those that are not yet loaded? Not all classes in the CDS archive are destined to be loaded. So of them are never referenced by the app so they are not loaded. Others can be substituted by JVMTI ClassFileLoadHook. So if you see some of these unloaded classes, what can you do with them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2023445400 From vlivanov at openjdk.org Tue Apr 1 18:45:18 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 1 Apr 2025 18:45:18 GMT Subject: RFR: 8353330: Test runtime/cds/appcds/SignedJar.java fails in CDSHeapVerifier In-Reply-To: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> References: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> Message-ID: On Tue, 1 Apr 2025 17:50:08 GMT, Ioi Lam wrote: > Java core-lib changes in [JDK-8339280](https://bugs.openjdk.org/browse/JDK-8339280) for code-signing causes more java.lang.invoke classes to be initialized in the assembly phase. > > Static fields like `java/lang/invoke/MethodHandleImpl$ArrayAccessor::OBJECT_ARRAY_SETTER` are just cached MethodHandles whose object identity doesn't matter. So it's OK for them to be stored into the AOT cache. Therefore, I added them to the CDSHeapVerifier exclusion lists. Looks good. > // [D] Simple caches whose value doesn't matter. Does the comment refer to "identity"? ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24363#pullrequestreview-2733736905 From duke at openjdk.org Tue Apr 1 19:23:56 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 1 Apr 2025 19:23:56 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: > ### Notes > > With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. > > It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. > > ### Implementation > > Mostly it keeps the existing MallocLimit implementation that was done in [JDK-8293313](https://bugs.openjdk.org/browse/JDK-8293313), which is to check whether limit has been exceeded whenever there is a new allocation event: > - For malloc, it's in [`Arena::grow`](https://github.com/openjdk/jdk/blob/07fd666d998cd8a485012eac4fab11b7e0f909d3/src/hotspot/share/memory/arena.cpp#L306) and [`os::malloc`](https://github.com/openjdk/jdk/blob/07fd666d998cd8a485012eac4fab11b7e0f909d3/src/hotspot/share/runtime/os.cpp#L646) (neither was changed in this pr). > - For mmap, nmt tracks reserved regions and committed regions. Committed regions is more of our interest since it's related to RSS. I found the places where new mmap regions are committed by tracking the usages of `VirtualMemorySummary::record_committed_memory`. There are two places: > - [`ReservedMemoryRegion::add_committed_region`](https://github.com/openjdk/jdk/blob/6891490892cc0405882658e067d587ffe5401a6d/src/hotspot/share/nmt/virtualMemoryTracker.cpp#L112), where new a mem region is committed > - [`ReservedMemoryRegion::set_mem_tag`](https://github.com/openjdk/jdk/blob/6891490892cc0405882658e067d587ffe5401a6d/src/hotspot/share/nmt/virtualMemoryTracker.cpp#L293), where it's possible to retag a committed mem region and hence [move committed memory](https://github.com/openjdk/jdk/blob/6891490892cc0405882658e067d587ffe5401a6d/src/hotspot/share/nmt/virtualMemoryTracker.cpp#L299) > > Except for renaming the original `malloc` related things to more generic `nMem`, this pr keeps the original implementation and passes additional type `NMemType::Malloc` / `NMemType::Mmap` , so that each function can differentiate between these two different mem types. Rui Li has updated the pull request incrementally with one additional commit since the last revision: Add headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24343/files - new: https://git.openjdk.org/jdk/pull/24343/files/78b74f71..ed903bd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24343&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24343&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24343/head:pull/24343 PR: https://git.openjdk.org/jdk/pull/24343 From aboldtch at openjdk.org Tue Apr 1 19:53:23 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 1 Apr 2025 19:53:23 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 16:00:10 GMT, Roman Kennke wrote: > > > No more concerns about the setting of BasicLock cache in enter? > > > > > > No, I think the bug that I ran into wasn't this, so no more concerns. > > Ok, good. @xmas92 also had concerns about doing that BL caching in enter that sounded like he wanted to hold this part back for now. I think there is a problem with quick_enter on 32bit x86. As it may fast lock successfully without clearing the cache, which iirc can be garbage (or read it as a monitor later). I would either make 32bit x86 return nullptr from `BasicLock::object_monitor_cache` or just add the `CacheSetter` / `if (UseObjectMonitorTable) { lock->clear_object_monitor_cache() }` in the `#ifndef _LP64` block. This is because the interpreter and C1 does not use `MacroAssembler::lightweight_lock` because of limited availability of registers and simply called into the VM. That is why the CacheSetter was introduced in quick enter. For all other platforms which uses `BasicLock::object_monitor_cache` have clear the cache in interpreter/ C1 and C2 (have not checked recently, but iirc Graal does the same thing as C2 here) Not sure what the state is w.r.t. 32bit x86 being deprecated for removal, but may just having `ObjectMonitor* BasicLock::object_monitor_cache()` return nullptr on 32 bit is the most straightforward solution here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2770526223 From duke at openjdk.org Tue Apr 1 20:42:41 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 1 Apr 2025 20:42:41 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - Change failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do by specifying failure mode with `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. `-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default. >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> # >> # >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers Added more description about the usages of the jvm arg as well as implementation. Let me know what other details we'd like to include. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2770629327 From mgronlun at openjdk.org Tue Apr 1 21:11:21 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 1 Apr 2025 21:11:21 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: <3lOQPNvVElTibFnLNf6vjmbuwFZu_CM9IacNGeEnNO8=.12846b87-2bf3-4803-9c50-e9a4db752525@github.com> On Tue, 25 Mar 2025 09:15:38 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix Changes requested by mgronlun (Reviewer). src/hotspot/share/runtime/objectMonitor.cpp line 2054: > 2052: } > 2053: > 2054: quick_notifyAll(current); When the regular versions end up also using the quick versions, a distinction has been lost in translation - is the only difference that the regular versions enter _thread_in_vm, whereas the quick versions enter _thread_in_java? If there is no real difference, consider eliminating the quick versions and referring directly to the regular versions. >From a JFR perspective, we need threads in state VM or Java for writing events that refer to artifacts; both states are equivalent for epoch management. You can also have threads in native writing JFR events, but only if the event fields are scalars, not foreign keys. However, the thread cannot capture a stack trace. src/hotspot/share/runtime/synchronizer.cpp line 378: > 376: DTRACE_MONITOR_PROBE(notify, mon, obj, current); > 377: } > 378: do { Is this loop included in the refactored version? I guess it is. ------------- PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2734014990 PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2023676611 PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2023657024 From mgronlun at openjdk.org Tue Apr 1 21:26:20 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 1 Apr 2025 21:26:20 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Tue, 25 Mar 2025 09:15:38 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2734077120 From mgronlun at openjdk.org Tue Apr 1 21:26:20 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 1 Apr 2025 21:26:20 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: <3lOQPNvVElTibFnLNf6vjmbuwFZu_CM9IacNGeEnNO8=.12846b87-2bf3-4803-9c50-e9a4db752525@github.com> References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> <3lOQPNvVElTibFnLNf6vjmbuwFZu_CM9IacNGeEnNO8=.12846b87-2bf3-4803-9c50-e9a4db752525@github.com> Message-ID: <_KfcThA0-6ZczW6XTYXmis-jIEY5l1hGyztVYnn7nkM=.eb4fbb37-b34a-4c8a-9ef7-9b6e99d5c1ec@github.com> On Tue, 1 Apr 2025 21:05:11 GMT, Markus Gr?nlund wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8352256-quick-notify-jfr >> - Review comment >> - Fix > > src/hotspot/share/runtime/objectMonitor.cpp line 2054: > >> 2052: } >> 2053: >> 2054: quick_notifyAll(current); > > From a JFR perspective, we need threads in state VM or Java for writing events that refer to artifacts; both states are equivalent for epoch management. You can also have threads in native writing JFR events, but only if the event fields are scalars, not foreign keys. However, the thread cannot capture a stack trace. A JavaThread in state VM or Java running the JFR commit code will not perform a transition or block for a safepoint. It is not waitfree (yet) however because of the JfrStacktrace_lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2023693404 From mgronlun at openjdk.org Tue Apr 1 21:30:27 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 1 Apr 2025 21:30:27 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: <_KfcThA0-6ZczW6XTYXmis-jIEY5l1hGyztVYnn7nkM=.eb4fbb37-b34a-4c8a-9ef7-9b6e99d5c1ec@github.com> References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> <3lOQPNvVElTibFnLNf6vjmbuwFZu_CM9IacNGeEnNO8=.12846b87-2bf3-4803-9c50-e9a4db752525@github.com> <_KfcThA0-6ZczW6XTYXmis-jIEY5l1hGyztVYnn7nkM=.eb4fbb37-b34a-4c8a-9ef7-9b6e99d5c1ec@github.com> Message-ID: On Tue, 1 Apr 2025 21:20:11 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 2054: >> >>> 2052: } >>> 2053: >>> 2054: quick_notifyAll(current); >> >> From a JFR perspective, we need threads in state VM or Java for writing events that refer to artifacts; both states are equivalent for epoch management. You can also have threads in native writing JFR events, but only if the event fields are scalars, not foreign keys. However, the thread cannot capture a stack trace. > > A JavaThread in state VM or Java running the JFR commit code will not perform a transition or block for a safepoint. It is not waitfree (yet) however because of the JfrStacktrace_lock. Are we keeping the NoSafepointVerifier in the quick entries? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2023700561 From amenkov at openjdk.org Tue Apr 1 21:32:35 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 1 Apr 2025 21:32:35 GMT Subject: RFR: 8353479: jcmd with streaming output breaks intendation Message-ID: `outputStream` implementations should call `update_position` from `write` to correctly handle indentation. The fix adds the call to `attachStream::write` testing: sanity tier1; in progress: tier2..4,hs-tier5-svc ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/24368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353479 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24368/head:pull/24368 PR: https://git.openjdk.org/jdk/pull/24368 From amenkov at openjdk.org Tue Apr 1 21:32:35 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 1 Apr 2025 21:32:35 GMT Subject: RFR: 8353479: jcmd with streaming output breaks intendation In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov wrote: > `outputStream` implementations should call `update_position` from `write` to correctly handle indentation. > The fix adds the call to `attachStream::write` > > testing: sanity tier1; > in progress: tier2..4,hs-tier5-svc Example of output with and without streaming output: $ JAVA_TOOL_OPTIONS=-Djdk.attach.allowStreamingOutput=true jcmd 31544 VM.native_memory Picked up JAVA_TOOL_OPTIONS: -Djdk.attach.allowStreamingOutput=true 31544: Native Memory Tracking: (Omitting categories weighting less than 1KB) Total: reserved=9953148KB, committed=407888KB malloc: 57776KB #293244, peak=75433KB #212390 mmap: reserved=9895372KB, committed=350112KB - Java Heap (reserved=8298496KB, committed=270336KB) (mmap: reserved=8298496KB, committed=270336KB, peak=520192KB) - Class (reserved=1048938KB, committed=2922KB) (classes #3716) ( instance classes #3406, array classes #310) (malloc=362KB #7060 ) (peak=364KB #7068) (mmap: reserved=1048576KB, committed=2560KB, at peak) ( Metadata: ) ( reserved=65536KB, committed=24384KB ) ( used=24223KB) ( waste=161KB =0.66%) ( Class space:) ( reserved=1048576KB, committed=2560KB ) ( used=2423KB) ( waste=137KB =5.36%) $ jcmd 31544 VM.native_memory 31544: Native Memory Tracking: (Omitting categories weighting less than 1KB) Total: reserved=9953152KB, committed=407892KB malloc: 57780KB #293282, peak=75433KB #212390 mmap: reserved=9895372KB, committed=350112KB - Java Heap (reserved=8298496KB, committed=270336KB) (mmap: reserved=8298496KB, committed=270336KB, peak=520192KB) - Class (reserved=1048938KB, committed=2922KB) (classes #3716) ( instance classes #3406, array classes #310) (malloc=362KB #7060) (peak=364KB #7068) (mmap: reserved=1048576KB, committed=2560KB, at peak) ( Metadata: ) ( reserved=65536KB, committed=24384KB) ( used=24223KB) ( waste=161KB =0.66%) ( Class space:) ( reserved=1048576KB, committed=2560KB) ( used=2423KB) ( waste=137KB =5.36%) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24368#issuecomment-2770724520 From dholmes at openjdk.org Tue Apr 1 22:32:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Apr 2025 22:32:12 GMT Subject: RFR: 8353330: Test runtime/cds/appcds/SignedJar.java fails in CDSHeapVerifier In-Reply-To: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> References: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> Message-ID: On Tue, 1 Apr 2025 17:50:08 GMT, Ioi Lam wrote: > Java core-lib changes in [JDK-8339280](https://bugs.openjdk.org/browse/JDK-8339280) for code-signing causes more java.lang.invoke classes to be initialized in the assembly phase. > > Static fields like `java/lang/invoke/MethodHandleImpl$ArrayAccessor::OBJECT_ARRAY_SETTER` are just cached MethodHandles whose object identity doesn't matter. So it's OK for them to be stored into the AOT cache. Therefore, I added them to the CDSHeapVerifier exclusion lists. Fix seems fine but I'm worried about how fragile this is. Any core-libs change might result in a change to the early loaded classes and break things again. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24363#pullrequestreview-2734172237 From liach at openjdk.org Wed Apr 2 00:37:09 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Apr 2025 00:37:09 GMT Subject: RFR: 8353330: Test runtime/cds/appcds/SignedJar.java fails in CDSHeapVerifier In-Reply-To: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> References: <0Uz5Vri_667FJ0wP63OykMlGhimTLC05kT4_PLmmtGo=.9e3c1d17-11cb-4eed-b68e-7fac4a39229e@github.com> Message-ID: On Tue, 1 Apr 2025 17:50:08 GMT, Ioi Lam wrote: > Java core-lib changes in [JDK-8339280](https://bugs.openjdk.org/browse/JDK-8339280) for code-signing causes more java.lang.invoke classes to be initialized in the assembly phase. > > Static fields like `java/lang/invoke/MethodHandleImpl$ArrayAccessor::OBJECT_ARRAY_SETTER` are just cached MethodHandles whose object identity doesn't matter. So it's OK for them to be stored into the AOT cache. Therefore, I added them to the CDSHeapVerifier exclusion lists. Surprised they aren't caught earlier - they are used for spreader and collector forms that can easily appear in asType adaptions in plain invoke. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24363#pullrequestreview-2734296995 From shade at openjdk.org Wed Apr 2 06:21:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Apr 2025 06:21:14 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Tue, 1 Apr 2025 21:24:01 GMT, Markus Gr?nlund wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8352256-quick-notify-jfr >> - Review comment >> - Fix > > Marked as reviewed by mgronlun (Reviewer). Thanks @mgronlun! @dholmes-ora, are you happy with our conclusions? > src/hotspot/share/runtime/synchronizer.cpp line 378: > >> 376: DTRACE_MONITOR_PROBE(notify, mon, obj, current); >> 377: } >> 378: do { > > Is this loop included in the refactored version? I guess it is. Yes, it is inside `notifyAll`. This loop used to run when `all = true` (= notifyAll), and there is a waiter in the wait set. This is the same thing that `notifyAll` is doing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2771445092 PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2024138607 From shade at openjdk.org Wed Apr 2 06:21:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Apr 2025 06:21:14 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> <3lOQPNvVElTibFnLNf6vjmbuwFZu_CM9IacNGeEnNO8=.12846b87-2bf3-4803-9c50-e9a4db752525@github.com> <_KfcThA0-6ZczW6XTYXmis-jIEY5l1hGyztVYnn7nkM=.eb4fbb37-b34a-4c8a-9ef7-9b6e99d5c1ec@github.com> Message-ID: On Tue, 1 Apr 2025 21:27:13 GMT, Markus Gr?nlund wrote: > Are we keeping the NoSafepointVerifier in the quick entries? Yes we do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2024139372 From shade at openjdk.org Wed Apr 2 07:29:25 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Apr 2025 07:29:25 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 Well, this apparently broke CDS archive generation / use in my multi-JVM builds. Looking for CDS archives in vicinity of currently launched libjvm.so is a feature that got unfortunately broken by this. Filed: https://bugs.openjdk.org/browse/JDK-8353504 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2771575425 From dholmes at openjdk.org Wed Apr 2 07:51:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Apr 2025 07:51:33 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:49:32 GMT, Axel Boldt-Christmas wrote: > Not sure what the state is w.r.t. 32bit x86 being deprecated for removal, It has been removed ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2771624475 From sspitsyn at openjdk.org Wed Apr 2 08:37:22 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Apr 2025 08:37:22 GMT Subject: RFR: 8353479: jcmd with streaming output breaks intendation In-Reply-To: References: Message-ID: <284gTOn3RoFPKIgLIzsrEPF5KGoJ2Ci98oW2pb9o7nU=.7a6d5b14-a058-4f51-8693-571c07d05d1d@github.com> On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov wrote: > `outputStream` implementations should call `update_position` from `write` to correctly handle indentation. > The fix adds the call to `attachStream::write` > > testing: sanity tier1; > in progress: tier2..4,hs-tier5-svc Looks okay to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24368#pullrequestreview-2735241312 From aboldtch at openjdk.org Wed Apr 2 08:53:20 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 2 Apr 2025 08:53:20 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 07:48:48 GMT, David Holmes wrote: > > Not sure what the state is w.r.t. 32bit x86 being deprecated for removal, > > It has been removed Alright if https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L69-L72 and https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1246-L1247 are dead / unreachable code (and/or if `#ifdef X86` means x86_64) then there is no issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2771864802 From jkern at openjdk.org Wed Apr 2 11:05:01 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 2 Apr 2025 11:05:01 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 10:30:56 GMT, Varada M wrote: >> AIX changes for attach API to support arbitrary length arguments and the streaming output support. >> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes >> >> tier1, tier2 and tier3 testing is successful with fastdebug level >> >> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8352392: AIX: implement attach API v2 and streaming output Hi Varada, I see that you've largely adapted the code to the POSIX version. Essentially, only the shutdown special handling remains. But the AIX special handling that you removed was introduced for some reason. Do you know why? Does this reasoning no longer apply? I have no idea and can't judge whether the different semantics have created holes in the code that could reappear under certain circumstances. Therefore, I would like an explanation from you as to why you can make this change now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2772207203 From stuefe at openjdk.org Wed Apr 2 12:16:03 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 2 Apr 2025 12:16:03 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> Message-ID: On Tue, 1 Apr 2025 18:05:57 GMT, Ioi Lam wrote: >> If we want this PR to proceed we should restructure the CDS code to use a different mechanism to iterate over the unloaded proxy classes. > > However, I still don't understand why this API is necessary for "KLUT" -- why do you need to look at all the classes in the CDS archive, including those that are not yet loaded? > > Not all classes in the CDS archive are destined to be loaded. So of them are never referenced by the app so they are not loaded. Others can be substituted by JVMTI ClassFileLoadHook. So if you see some of these unloaded classes, what can you do with them? KLUT changes some of the basic operations on oops; for example, oop->isObjArray() retrieves the class kind from the KLUT table, not the class. For that, the entry for that Klass must have been added to the KLUT table. For dynamic class loading, this is not a problem: before an oop is ever born, we need to load the class first, so there is always a path where the Klass is created, and that is where I populate the entry in the table. For CDS, this does not work. CDS uses methods on oops in the mapped heap regions before ever loading the associated class. For example, by calling oop->isObjArray() or similar. Traditionally this works because oop->isObjArray does not need much, just narrow Klass pointer decoding, which we set up beforehand. For KLUT, it does not work since the KLUT entry is not there yet. Example: in ArchiveHeapLoader::finish_initialization() (archiveHeapLoader.cpp:396). There are other examples. I can workaround this by reverting to dynamic initialization for the KLUT entry (if entry missing, calculate it and store it), but that is undesirable for real oop iteration during GCs. We execute that condition a bazillion times because a few classes need it on the CDS initialization path. Well, maybe branch prediction would be smart enough to minimize the negative effect of this additional branch. But it is somewhat baffling that such a simple thing as iterating all Klass structures in a CDS archive is so complex. Could one just iterate through the shared class space portion? Hop from Klass to Klass, as one would iterate through the heap? But I doubt that this always works either - there may be holes between Klass structures, or there may other things that live in there, too. About the "may never be loaded": That is fine. I rather unnecessarily calculate the KLUT token for a class that will never be used than to pay for "Is this entry initialized?" branch in every use of the KLUT table. The latter is worse, performance-wise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2024698540 From stuefe at openjdk.org Wed Apr 2 12:18:56 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 2 Apr 2025 12:18:56 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> Message-ID: <6-glFS0Q-RVAi4dz4Q0QcAIGaTqEps8NxgYz9wbY2rk=.9b091303-e379-4638-ac03-ef5b1a13ba74@github.com> On Wed, 2 Apr 2025 12:13:17 GMT, Thomas Stuefe wrote: > About the "may never be loaded": That is fine. I rather unnecessarily calculate the KLUT token for a class that will never be used than to pay for "Is this entry initialized?" branch in every use of the KLUT table. The latter is worse, performance-wise. Plus, the token is stored in the Klass, so it will have been calculated at dumptime, and so the only thing missing is copying the entry to its table position at runtime. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2024702813 From coleenp at openjdk.org Wed Apr 2 12:45:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Apr 2025 12:45:03 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke wrote: >> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible. >> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter. >> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed. >> - Some small code shufflings. >> >> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs: >> without-OMT: 773.3 ms >> with-OMT: 797.28 ms >> >> That is still a regression of ~3% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Include objectMonitor.inline.hpp So is the issue that the 32 bit x86 code doesn't clear the BasicLock::monitor_cache before going slow path? I don't see the arm and s390 code doing that either. So the bug is that the quick-enter code will find a stale monitor? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2772443092 From jsjolen at openjdk.org Wed Apr 2 12:45:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 2 Apr 2025 12:45:59 GMT Subject: RFR: 8353479: jcmd with streaming output breaks intendation In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov wrote: > `outputStream` implementations should call `update_position` from `write` to correctly handle indentation. > The fix adds the call to `attachStream::write` > > testing: sanity tier1; > in progress: tier2..4,hs-tier5-svc Thanks! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24368#pullrequestreview-2736139795 From aboldtch at openjdk.org Wed Apr 2 13:32:55 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 2 Apr 2025 13:32:55 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: <7JWZtTk43alJv1QDX_tRJhhjV8lfsAwiP1JVAxqNh7I=.90200d78-cda8-4116-afb9-413ae07b396e@github.com> On Wed, 2 Apr 2025 12:42:26 GMT, Coleen Phillimore wrote: > So is the issue that the 32 bit x86 code doesn't clear the BasicLock::monitor_cache before going slow path? I don't see the arm and s390 code doing that either. So the bug is that the quick-enter code will find a stale monitor? s390 does (this code is used by interpreter and c1) https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/s390/macroAssembler_s390.cpp#L6361-L6365 Arm32 is protected inside the runtime with preprocessor macros https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/share/runtime/basicLock.inline.hpp#L43-L55 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2772575230 From shade at openjdk.org Wed Apr 2 14:37:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Apr 2025 14:37:09 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 08:49:37 GMT, Axel Boldt-Christmas wrote: > https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp#L69-L72 > and This C1 code is on the chopping block with https://github.com/openjdk/jdk/pull/24301. > https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1246-L1247 > are dead / unreachable code (and/or if `#ifdef X86` means x86_64) then there is no issue. This code is already absent in mainline, removed during the template interpreter cleanups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2772763387 From ihse at openjdk.org Wed Apr 2 15:03:47 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 15:03:47 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. This seems reasonable to me. But there is so much old yucky stuff going on with the JDK bootstrapping issues, that I still get a bit nervous every time someone changes it. Do you know *why* we do this, i.e. modify LD_LIBRARY_PATH? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2772870911 From iklam at openjdk.org Wed Apr 2 15:49:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Apr 2025 15:49:00 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: <6-glFS0Q-RVAi4dz4Q0QcAIGaTqEps8NxgYz9wbY2rk=.9b091303-e379-4638-ac03-ef5b1a13ba74@github.com> References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> <6-glFS0Q-RVAi4dz4Q0QcAIGaTqEps8NxgY z9wbY2rk=.9b091303-e379-4638-ac03-ef5b1a13ba74@github.com> Message-ID: On Wed, 2 Apr 2025 12:16:10 GMT, Thomas Stuefe wrote: >> KLUT changes some of the basic operations on oops; for example, oop->isObjArray() retrieves the class kind from the KLUT table, not the class. For that, the entry for that Klass must have been added to the KLUT table. For dynamic class loading, this is not a problem: before an oop is ever born, we need to load the class first, so there is always a path where the Klass is created, and that is where I populate the entry in the table. >> >> For CDS, this does not work. CDS uses methods on oops in the mapped heap regions before ever loading the associated class. For example, by calling oop->isObjArray() or similar. Traditionally this works because oop->isObjArray does not need much, just narrow Klass pointer decoding, which we set up beforehand. For KLUT, it does not work since the KLUT entry is not there yet. >> >> Example: in ArchiveHeapLoader::finish_initialization() (archiveHeapLoader.cpp:396). There are other examples. >> >> I can workaround this by reverting to dynamic initialization for the KLUT entry (if entry missing, calculate it and store it), but that is undesirable for real oop iteration during GCs. We execute that condition a bazillion times because a few classes need it on the CDS initialization path. Well, maybe branch prediction would be smart enough to minimize the negative effect of this additional branch. But it is somewhat baffling that such a simple thing as iterating all Klass structures in a CDS archive is so complex. >> >> Could one just iterate through the shared class space portion? Hop from Klass to Klass, as one would iterate through the heap? But I doubt that this always works either - there may be holes between Klass structures, or there may other things that live in there, too. >> >> About the "may never be loaded": That is fine. I rather unnecessarily calculate the KLUT token for a class that will never be used than to pay for "Is this entry initialized?" branch in every use of the KLUT table. The latter is worse, performance-wise. > >> About the "may never be loaded": That is fine. I rather unnecessarily calculate the KLUT token for a class that will never be used than to pay for "Is this entry initialized?" branch in every use of the KLUT table. The latter is worse, performance-wise. > > Plus, the token is stored in the Klass, so it will have been calculated at dumptime, and so the only thing missing is copying the entry to its table position at runtime. There's only a small number of classes that have allocated instances in the CDS archive. I think it's better to build a table of these classes and create KLUT information for them. BTW, none of the classes in the `LambdaProxyClassDictionary` have allocated instances. $ LOG=-Xlog:cds+map=trace,cds+map+oops=trace:file=cds.oops.txt:none:filesize=0 $ java -Xshare:dump $LOG $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc 79 79 2456 $ java -Xshare:dump $LOG -XX:+AOTClassLinking $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc 172 172 6068 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2025121955 From rkennke at openjdk.org Wed Apr 2 16:00:15 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 2 Apr 2025 16:00:15 GMT Subject: Integrated: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: References: Message-ID: On Tue, 18 Mar 2025 12:41:44 GMT, Roman Kennke wrote: > - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible. > - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter. > - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed. > - Some small code shufflings. > > I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs: > without-OMT: 773.3 ms > with-OMT: 797.28 ms > > That is still a regression of ~3% This pull request has now been integrated. Changeset: 49cb7aaa Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/49cb7aaad903aa5209da9f4af4b484ff38c0fb8b Stats: 63 lines in 8 files changed: 37 ins; 6 del; 20 mod 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable Reviewed-by: coleenp, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/24098 From rkennke at openjdk.org Wed Apr 2 16:00:14 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 2 Apr 2025 16:00:14 GMT Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke wrote: >> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible. >> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter. >> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed. >> - Some small code shufflings. >> >> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs: >> without-OMT: 773.3 ms >> with-OMT: 797.28 ms >> >> That is still a regression of ~3% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Include objectMonitor.inline.hpp Ok, sounds like we're good, then. Let's ------------- PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2773044514 From gziemski at openjdk.org Wed Apr 2 19:06:51 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 2 Apr 2025 19:06:51 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v7] In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 14:57:04 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix the GHA failures. I'd love to see an abstract, non-implementation, way to describe all the cases, something like: pre: .................................. post: ...L1------------------------R1... L1=[S?,S1,R?] R1=[S1,S?,L?] where "." means empty region, "-" means reserved, "+" committed, Lx left edge metadata, Rx right edge metadata, S? invalid stack, Sx valid stack, etc... then once we are in agreement that we have all the cases covered, we provide an implementation for them. As far as the implementation is concerned, let's not optimize too early, i.e. no common code or sharing code: each case should stand on its own, without having to follow code above it, or below it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2773435319 PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2773447414 From lmesnik at openjdk.org Wed Apr 2 19:28:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 2 Apr 2025 19:28:54 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified In-Reply-To: References: Message-ID: <7KoKns719sUOD3sVDD4kVZzDURtGcqKyZcnupLTO-ck=.4e4bbbff-2f37-462d-b317-db27aa9a0ada@github.com> On Mon, 31 Mar 2025 16:31:47 GMT, Coleen Phillimore wrote: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. The fix looks good. Please ensure that you run nsk/jvmti tests. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24333#pullrequestreview-2737345773 From vlivanov at openjdk.org Wed Apr 2 21:23:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 2 Apr 2025 21:23:49 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2] In-Reply-To: References: Message-ID: <-X1lpKRyKx3cMLiAbJdrdioHT_4V_809CWEstVmRpSM=.f18c4328-ae90-4293-a136-5afee2974482@github.com> On Tue, 1 Apr 2025 16:35:38 GMT, Ioi Lam wrote: >> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. >> >> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Refactored CollectClassesForLinking for simplification > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Reverted some fixes in systemDictionaryShared.cpp that causes test failures > - 8353014: Exclude AOT tooling classes from AOT cache Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24272#pullrequestreview-2737627405 From coleenp at openjdk.org Wed Apr 2 22:52:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Apr 2025 22:52:03 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable Message-ID: This reverts commit 49cb7aaad903aa5209da9f4af4b484ff38c0fb8b. Testing in progress. ------------- Commit messages: - Revert "8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable" Changes: https://git.openjdk.org/jdk/pull/24396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353584 Stats: 63 lines in 8 files changed: 6 ins; 37 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24396/head:pull/24396 PR: https://git.openjdk.org/jdk/pull/24396 From rkennke at openjdk.org Wed Apr 2 23:09:48 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 2 Apr 2025 23:09:48 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 22:47:10 GMT, Coleen Phillimore wrote: > This reverts commit 49cb7aaad903aa5209da9f4af4b484ff38c0fb8b. > > Testing in progress. Marked as reviewed by rkennke (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24396#pullrequestreview-2737783433 From coleenp at openjdk.org Wed Apr 2 23:09:48 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Apr 2025 23:09:48 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: References: Message-ID: <2Kh_5vck1IXKzYcGyGeq0RY0BVL5hHwr4jA8faod8Wk=.70af5989-ae64-4e45-976c-03ece1eb926f@github.com> On Wed, 2 Apr 2025 22:47:10 GMT, Coleen Phillimore wrote: > This reverts commit 49cb7aaad903aa5209da9f4af4b484ff38c0fb8b. > > Testing in progress. FTR Roman, I don't see what the bug is but since it's tier1 our policy is to back out the change. Hopefully it's something simple. Thanks for the review. I'll wait for GHA to finish. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24396#issuecomment-2773923297 From rkennke at openjdk.org Wed Apr 2 23:33:48 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 2 Apr 2025 23:33:48 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: <2Kh_5vck1IXKzYcGyGeq0RY0BVL5hHwr4jA8faod8Wk=.70af5989-ae64-4e45-976c-03ece1eb926f@github.com> References: <2Kh_5vck1IXKzYcGyGeq0RY0BVL5hHwr4jA8faod8Wk=.70af5989-ae64-4e45-976c-03ece1eb926f@github.com> Message-ID: <0joaJsw-ZfDdUxAz2-xR943JvQHstoQajtDP8W6yhvA=.71301ec9-602b-414a-bdfb-2b46512b1190@github.com> On Wed, 2 Apr 2025 23:07:20 GMT, Coleen Phillimore wrote: > FTR Roman, I don't see what the bug is but since it's tier1 our policy is to back out the change. Hopefully it's something simple. Thanks for the review. I'll wait for GHA to finish. That's fine, no worries. I have a hunch what it might be. We should clear the BL cache in the deopt-path before calling into inflate_and_enter(), because we might be getting some stale cache entry from the interpreter frame. I'll try this out later (not sure when I get to it, though, I'll be traveling tomorrow). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24396#issuecomment-2773962651 From coleenp at openjdk.org Wed Apr 2 23:42:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Apr 2025 23:42:54 GMT Subject: Integrated: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: References: Message-ID: <7DjagkoiPkZ7JOcF8giLGrTUR_HWpem722OSmVxaDes=.77fa0120-596d-476f-8fec-dd46cadcbbb0@github.com> On Wed, 2 Apr 2025 22:47:10 GMT, Coleen Phillimore wrote: > This reverts commit 49cb7aaad903aa5209da9f4af4b484ff38c0fb8b. > > Testing in progress. This pull request has now been integrated. Changeset: e2e1598e Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e2e1598ecc19a8c39bc68c05d5982da1fec106ea Stats: 63 lines in 8 files changed: 6 ins; 37 del; 20 mod 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable Reviewed-by: rkennke ------------- PR: https://git.openjdk.org/jdk/pull/24396 From coleenp at openjdk.org Wed Apr 2 23:42:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Apr 2025 23:42:53 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: References: Message-ID: <7sYk2urESvxa9xdRtGeRETVBk_u3RMAFFfijnN0L5WA=.141ff1a1-0801-4aa4-aeb7-c89d3efe656f@github.com> On Wed, 2 Apr 2025 22:47:10 GMT, Coleen Phillimore wrote: > This reverts commit 49cb7aaad903aa5209da9f4af4b484ff38c0fb8b. > > Testing in progress. I'll have a look tomorrow too. I think it's gotten a stale ObjectMonitor too in the deopt path. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24396#issuecomment-2773970740 From rkennke at openjdk.org Wed Apr 2 23:54:54 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 2 Apr 2025 23:54:54 GMT Subject: RFR: 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable In-Reply-To: <7sYk2urESvxa9xdRtGeRETVBk_u3RMAFFfijnN0L5WA=.141ff1a1-0801-4aa4-aeb7-c89d3efe656f@github.com> References: <7sYk2urESvxa9xdRtGeRETVBk_u3RMAFFfijnN0L5WA=.141ff1a1-0801-4aa4-aeb7-c89d3efe656f@github.com> Message-ID: <7ZRQ1AuCo4p8l474LJ35JhWOxIyOhRHY8ZMHcq8Wruc=.37849682-9357-4779-ba2f-6966f2933b42@github.com> On Wed, 2 Apr 2025 23:37:22 GMT, Coleen Phillimore wrote: > I'll have a look tomorrow too. I think it's gotten a stale ObjectMonitor too in the deopt path. Thanks for reviewing. Please try something like: https://gist.github.com/rkennke/6c26f4d214fa8276a42199e2eeb90f14 (on top of the original change) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24396#issuecomment-2773993254 From iklam at openjdk.org Thu Apr 3 04:09:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 04:09:28 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output Message-ID: Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: const char* CDSConfig::input_static_archive_path(); const char* CDSConfig::input_dynamic_archive_path(); const char* CDSConfig::output_archive_path(); This PR also cleans up the code by: - renaming a few function to reflect what they actually do - moving more "config" management code into cdsConfig.cpp There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases ------------- Depends on: https://git.openjdk.org/jdk/pull/24272 Commit messages: - Minimized changes in ergo_init_classic_archive_paths() - Clean up CDS input/output path handling Changes: https://git.openjdk.org/jdk/pull/24401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353597 Stats: 304 lines in 15 files changed: 156 ins; 55 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/24401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401 PR: https://git.openjdk.org/jdk/pull/24401 From iklam at openjdk.org Thu Apr 3 04:09:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 04:09:29 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 04:00:59 GMT, Ioi Lam wrote: > Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. > > In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: > > > const char* CDSConfig::input_static_archive_path(); > const char* CDSConfig::input_dynamic_archive_path(); > const char* CDSConfig::output_archive_path(); > > > This PR also cleans up the code by: > - renaming a few function to reflect what they actually do > - moving more "config" management code into cdsConfig.cpp > > There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. > > However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases src/hotspot/share/cds/dynamicArchive.cpp line 499: > 497: } > 498: } > 499: Moved to `CDSConfig::prepare_for_dumping()` src/hotspot/share/cds/metaspaceShared.cpp line 795: > 793: assert(CDSConfig::is_dumping_archive(), "sanity"); > 794: CDSConfig::check_unsupported_dumping_module_options(); > 795: } Moved to `CDSConfig::prepare_for_dumping()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2026141716 PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2026142127 From ccheung at openjdk.org Thu Apr 3 04:52:27 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Apr 2025 04:52:27 GMT Subject: RFR: 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 [v2] In-Reply-To: References: Message-ID: > This change fixes two issues in `os::jvm_path()`: > > - go back 4 instead of 5 slashes and then checking for "/jre/lib"; > - fix the hardcoded "hotspot" sub-directory before the jvm library name. > > 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 three additional commits since the last revision: - @tstuefe and @dholmes-ora comments - Merge branch 'master' into 8171508-os-jvm_path - 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/04f09cc4..eb20233a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=00-01 Stats: 10506 lines in 190 files changed: 6408 ins; 3262 del; 836 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From ccheung at openjdk.org Thu Apr 3 04:55:47 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Apr 2025 04:55:47 GMT Subject: RFR: 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 06:25:34 GMT, Thomas Stuefe wrote: > Hi @calvinccheung, I thought we planned on removing altjvm handling altogether? See mail thread https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2017-April/023205.html I've pushed a commit which removes altjvm handling in JVM. There's small piece of code in the java launcher (java.c) which I didn't remove because: - there's an internal test which uses altjvm; - JVM won't start if -XXaltjvm is specified ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2774489408 From ccheung at openjdk.org Thu Apr 3 04:55:48 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Apr 2025 04:55:48 GMT Subject: RFR: 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 07:09:49 GMT, David Holmes wrote: > > go back 4 instead of 5 slashes and then checking for "/jre/lib"; > > But we got rid of the `jre` directory years ago. ?? I've removed the processing regarding the slashes and the `jre` directory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2774490773 From sspitsyn at openjdk.org Thu Apr 3 06:57:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Apr 2025 06:57:36 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v7] In-Reply-To: References: Message-ID: > 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: add workaround for post_dynamic_code_generated_while_holding_locks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23490/files - new: https://git.openjdk.org/jdk/pull/23490/files/d6c647a3..39e8d748 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=05-06 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 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 Thu Apr 3 07:23:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Apr 2025 07:23:00 GMT Subject: RFR: 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 04:52:27 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> 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 three additional commits since the last revision: > > - @tstuefe and @dholmes-ora comments > - Merge branch 'master' into 8171508-os-jvm_path > - 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474 This issue should be renamed "Remove -Dsun.java.launcher.is_altjvm option". That requires a CSR request to be filed. Once again for the record -XXaltjvm has nothing to do with the -Dsun.java.launcher.is_altjvm option. https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2017-April/023241.html Removal of -XXaltjvm would also need a CSR request. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2774715610 From varadam at openjdk.org Thu Apr 3 07:23:05 2025 From: varadam at openjdk.org (Varada M) Date: Thu, 3 Apr 2025 07:23:05 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 10:30:56 GMT, Varada M wrote: >> AIX changes for attach API to support arbitrary length arguments and the streaming output support. >> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes >> >> tier1, tier2 and tier3 testing is successful with fastdebug level >> >> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8352392: AIX: implement attach API v2 and streaming output With the Attach API protocol update to version 2, now support arbitrary-length arguments, and shared code has been added in attachListener.cpp ([read_request](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.cpp#L845), [write_fully](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.cpp#L908)) to handle this across platforms. As a result, the AIX code is no longer required. I also compared the older changes in the POSIX implementation and found them to be the same as AIX ------------- PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2774714653 From dholmes at openjdk.org Thu Apr 3 07:41:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Apr 2025 07:41:56 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Thu, 20 Mar 2025 08:39:54 GMT, Aleksey Shipilev wrote: > I clicked through the JFR event commit code, and I don't think there are safepoints, indefinite blocking, or state transitions. Can we rely on this, @egahlin, @mgronlun? I do not see a clear answer to this. Again just for clarity the quick versions are for use when you 100% guarantee the monitor is owned. They do not need to, and cannot, check the owner and potentially throw IMSE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2774756379 From dholmes at openjdk.org Thu Apr 3 07:52:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Apr 2025 07:52:54 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Yes this was related to JRE but was changed to JDK by JDK-8343040. It does appear to be trying to find the upper lib directory in: JAVA_HOME/bin given the JRE location. Hence it is meaningless (and potentially "dangerous"!) when given the JDK/JAVA_HOME location ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2774778621 From ihse at openjdk.org Thu Apr 3 09:01:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 3 Apr 2025 09:01:57 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739039686 From duke at openjdk.org Thu Apr 3 09:13:00 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:00 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:06:43 GMT, tison wrote: > Try to add clear type annotations. > > Please let me know how this patch can be properly reviewed >_< > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.org):_ > > Hi, > > This change was already proposed (by myself): > > https://bugs.openjdk.org/browse/JDK-8289253 > > but it cannot be done as it will break source compatibility. > > We will just have to live with this historical oddity. > > Cheers, David > > On 31/03/2025 12:46 pm, tison wrote: Thanks for your information. Then closed as won't do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2774993075 From duke at openjdk.org Thu Apr 3 09:13:01 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:01 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> References: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> Message-ID: On Tue, 1 Apr 2025 05:38:17 GMT, Jaikiran Pai wrote: >> @jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/ > > Hello @tisonkun, > >> How can I create an issue for this PR? I don't find some instructions :/ > > In general, the OpenJDK contribution guide has these details https://openjdk.org/guide/. Typically, depending on the change, you either raise an issue through https://bugreport.java.com/bugreport/ or you create a discussion in the relevant mailing list. A PR is usually created after there's some consensus about the necessity of the change. > > For the current PR, David notes that this change was previously discussed and it was decided not to pursue further. If you have further questions or need additional inputs, I recommend that you subscribe to the hotspot-runtime-dev mailing list https://mail.openjdk.org/mailman/listinfo/hotspot-runtime-dev and create a discussion there. @jaikiran Thank you! I'll use this info if I make any other patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2774993857 From duke at openjdk.org Thu Apr 3 09:13:01 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:01 GMT Subject: Withdrawn: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:06:43 GMT, tison wrote: > Try to add clear type annotations. > > Please let me know how this patch can be properly reviewed >_< This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21658 From mli at openjdk.org Thu Apr 3 09:58:59 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 3 Apr 2025 09:58:59 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 Good idea! Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24344#pullrequestreview-2739205997 From sspitsyn at openjdk.org Thu Apr 3 10:15:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Apr 2025 10:15: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> <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com> <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com> <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com> Message-ID: On Thu, 6 Mar 2025 00:39:53 GMT, Serguei Spitsyn wrote: >> I don't think we should block suspend requests in all cases of being `_thread_blocked`, but `get_jvmti_thread_state` is a special case. We either need to have a general suspension suppression mechanism (which I thought already existed - but may it was in old code), or we need to special-case the acquisition of the `Thread_State_lock`. > >> Let me see if I have the sequence of events correct: >> - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended >> - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended >> - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so > > This is almost right but let me add a couple of details. > A suspend request was processed/registered/accepted at the handshake/safepoint-safe point but physical suspension in the `ThreadSelfSuspensionHandshake` has not happened yet which created a problem. Also, the problem is not that the thread goes to post the event. Suspension and event posting are racy by design. The problem is that the `SingleStep` events for this thread are also enabled at the handshake/safepoint-safe point after the suspend request was processed/registered/accepted. > >> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it. > > I'm also thinking toward this direction. The best way to fix this would be to disallow processing/accepting new suspend requests in `MutexLocker mu(JvmtiThreadState_lock)` which is executed in context of `get_jvmti_thread_state()` call: > > inline JvmtiThreadState* JvmtiThreadState::state_for(JavaThread *thread, Handle thread_handle) { > // In a case of unmounted virtual thread the thread can be null. > JvmtiThreadState* state = thread_handle == nullptr ? thread->jvmti_thread_state() : > java_lang_Thread::jvmti_thread_state(thread_handle()); > if (state == nullptr) { > MutexLocker mu(JvmtiThreadState_lock); > . . . > > Unfortunately, it looks like it is tricky and risky to do. David, we had an internal Zoom meeting with Patricio and agreed on a couple of points (I hope, Patricio will fix me if needed). #1: The main (biggest) problem is the call to `JvmtiEventController::thread_started()` in the function `get_jvmti_thread_state()`. The function `JvmtiThreadState::state_for()` is called there if a mounted virtual thread is the current thread and any thread-filtered event is enabled globally. The function `JvmtiThreadState::state_for()` has this line: `MutexLocker mu(JvmtiThreadState_lock);` The `JvmtiThreadState_lock` allows safepointing. It is where a JVMTI suspend request for this thread has been processed/registered. The `SingleStep` events for this thread are also enabled after the suspend request was processed/registered. However, suspends are not allowed by this `MutexLocker`. This is very common code path for any thread-filtered event (e.g. the event can be enabled for a specific thread). #2: This PR fixes this exact issue with this update: JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread) { assert(thread == JavaThread::current(), "must be current thread"); if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { JvmtiEventController::thread_started(thread); + if (thread->is_suspended()) { + // suspend here if there is a suspend request + ThreadBlockInVM tbivm(thread); + } } . . . But we also agreed to add a tweak for the function `post_dynamic_code_generated_while_holding_locks()` to disallow suspension in this context. Then it will look like this: +JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) { assert(thread == JavaThread::current(), "must be current thread"); if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { JvmtiEventController::thread_started(thread); + if (allow_suspend && thread->is_suspended()) { + // suspend here if there is a suspend request + ThreadBlockInVM tbivm(thread, true /* allow suspend */); + } } . . . void JvmtiExport::post_dynamic_code_generated_while_holding_locks(const char* name, address code_begin, address code_end) { . . . JvmtiThreadState *state = get_jvmti_thread_state(thread, false /* allow_suspend */); . . . I have already pushed the minor tweak above. #3: We also agreed to investigate more case where a similar situation can occur withing a context/scope of all the`JvmtiExport::post_*` function calls. One interesting case was found: bool InstanceKlass::link_class_impl(TRAPS) { . . . if (Universe::is_fully_initialized()) { DeoptimizationScope deopt_scope; { // Now mark all code that assumes the class is not linked. // Set state under the Compile_lock also. MutexLocker ml(THREAD, Compile_lock); <== !!! set_init_state(linked); CodeCache::mark_dependents_on(&deopt_scope, this); } // Perform the deopt handshake outside Compile_lock. deopt_scope.deoptimize_marked(); } else { set_init_state(linked); } if (JvmtiExport::should_post_class_prepare()) { JvmtiExport::post_class_prepare(THREAD, this); <== !!! } } } return true; } It feels like more thoughts are needed here. I'm thinking it would be okay to file a separate bug for this additional investigation. Most likely we do not have a good test coverage for this, and so, no tests are failing but we may want to add it in the future. At the moment, I'm not sure of it is worth it or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2026660121 From fyang at openjdk.org Thu Apr 3 10:26:49 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 3 Apr 2025 10:26:49 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 09:55:51 GMT, Hamlin Li wrote: > Good idea! Thanks! Thanks for having a look :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24344#issuecomment-2775254702 From shade at openjdk.org Thu Apr 3 11:51:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 3 Apr 2025 11:51:06 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Thu, 3 Apr 2025 07:39:36 GMT, David Holmes wrote: > Again just for clarity the quick versions are for use when you 100% guarantee the monitor is owned. They do not need to, and cannot, check the owner and potentially throw IMSE. I don't think new quick versions do. We only `assert(check_owner(...))`, but I think that is "safe" in the sense we fail hard if monitor is not owned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2775502889 From jsjolen at openjdk.org Thu Apr 3 12:15:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 3 Apr 2025 12:15:41 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm Message-ID: Hi, The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) 2. Print the entirety of the log file produced if no missing messages are found 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. With these changes integrated, I hope to be able to find the actual culprit of this bug. I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. ------------- Commit messages: - Improvements to async UL gtests Changes: https://git.openjdk.org/jdk/pull/24411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352568 Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24411/head:pull/24411 PR: https://git.openjdk.org/jdk/pull/24411 From jsjolen at openjdk.org Thu Apr 3 12:15:42 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 3 Apr 2025 12:15:42 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 10:35:29 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. @MBaesken , @dholmes-ora Would you mind reviewing this change, please? Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24411#issuecomment-2775587788 From jkern at openjdk.org Thu Apr 3 12:50:57 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 3 Apr 2025 12:50:57 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: <-x81ydaT2ImEfbGOLisk3XiQDsbln91IUf3jDNA1NDk=.d035465a-cb77-4c88-99aa-f7fc171411d0@github.com> On Tue, 1 Apr 2025 10:30:56 GMT, Varada M wrote: >> AIX changes for attach API to support arbitrary length arguments and the streaming output support. >> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes >> >> tier1, tier2 and tier3 testing is successful with fastdebug level >> >> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8352392: AIX: implement attach API v2 and streaming output Reasonable change. ------------- Marked as reviewed by jkern (Committer). PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2739729179 From coleenp at openjdk.org Thu Apr 3 12:55:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Apr 2025 12:55:52 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> <6-glFS0Q-RVAi4dz4Q0QcAIGaTqEps8NxgY z9wbY2rk=.9b091303-e379-4638-ac03-ef5b1a13ba74@github.com> Message-ID: On Wed, 2 Apr 2025 15:46:16 GMT, Ioi Lam wrote: >>> About the "may never be loaded": That is fine. I rather unnecessarily calculate the KLUT token for a class that will never be used than to pay for "Is this entry initialized?" branch in every use of the KLUT table. The latter is worse, performance-wise. >> >> Plus, the token is stored in the Klass, so it will have been calculated at dumptime, and so the only thing missing is copying the entry to its table position at runtime. > > There's only a small number of classes that have allocated instances in the CDS archive. I think it's better to build a table of these classes and create KLUT information for them. > > BTW, none of the classes in the `LambdaProxyClassDictionary` have allocated instances. > > > $ LOG=-Xlog:cds+map=trace,cds+map+oops=trace:file=cds.oops.txt:none:filesize=0 > $ java -Xshare:dump $LOG > $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc > 79 79 2456 > $ java -Xshare:dump $LOG -XX:+AOTClassLinking > $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc > 172 172 6068 I wonder if you could generate the KLUT information when objects are allocated rather than eagerly when classes are loaded. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2026933676 From jpai at openjdk.org Thu Apr 3 12:59:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 12:59:49 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com> On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Hello @JoKern65, the change looks reasonable to me. Please give me a day or so to run this change against our CI. In the meantime, could you please update the copyright years on `java_md.c` and the `Test7029048.java` files? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739755041 From jkern at openjdk.org Thu Apr 3 13:09:10 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 3 Apr 2025 13:09:10 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v2] In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24351/files - new: https://git.openjdk.org/jdk/pull/24351/files/9d41d444..6f32ead9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351 PR: https://git.openjdk.org/jdk/pull/24351 From jpai at openjdk.org Thu Apr 3 13:19:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 13:19:50 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v2] In-Reply-To: References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: <1ZlVOX-syJsHCcWc4yTKeGaYofqbzGPSKOpTzq42xaU=.ff26b49e-397a-4012-aaad-b897adfaa8a2@github.com> On Thu, 3 Apr 2025 13:09:10 GMT, Joachim Kern wrote: >> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. >> >> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > copyright years Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739814339 From mbaesken at openjdk.org Thu Apr 3 13:24:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Apr 2025 13:24:59 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 12:10:29 GMT, Johan Sj?len wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> With these changes integrated, I hope to be able to find the actual culprit of this bug. >> >> I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. > > @MBaesken , @dholmes-ora > > Would you mind reviewing this change, please? Thank you. Hi @jdksjolen , I put your change into our build/test queue ; let's see what it does regarding the errors we saw on linuxaarch64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24411#issuecomment-2775773071 From mdoerr at openjdk.org Thu Apr 3 14:48:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 3 Apr 2025 14:48:01 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 10:30:56 GMT, Varada M wrote: >> AIX changes for attach API to support arbitrary length arguments and the streaming output support. >> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes >> >> tier1, tier2 and tier3 testing is successful with fastdebug level >> >> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8352392: AIX: implement attach API v2 and streaming output Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2740165191 From stuefe at openjdk.org Thu Apr 3 15:18:18 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 3 Apr 2025 15:18:18 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com> <3lS3nxyDtFVEFXTC_hsn2_AsZNCjVRfzMUjwfrdZp-c=.9850c38d-ba22-4519-af64-8869e7cc1eed@github.com> <6-glFS0Q-RVAi4dz4Q0QcAIGaTqEps8NxgY z9wbY2rk=.9b091303-e379-4638-ac03-ef5b1a13ba74@github.com> Message-ID: On Thu, 3 Apr 2025 12:51:40 GMT, Coleen Phillimore wrote: >> There's only a small number of classes that have allocated instances in the CDS archive. I think it's better to build a table of these classes and create KLUT information for them. >> >> BTW, none of the classes in the `LambdaProxyClassDictionary` have allocated instances. >> >> >> $ LOG=-Xlog:cds+map=trace,cds+map+oops=trace:file=cds.oops.txt:none:filesize=0 >> $ java -Xshare:dump $LOG >> $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc >> 79 79 2456 >> $ java -Xshare:dump $LOG -XX:+AOTClassLinking >> $ grep '@@ Object' cds.oops.txt | cut -b 44- | sed -e 's/ .*//g' | sort | uniq | wc >> 172 172 6068 > > I wonder if you could generate the KLUT information when objects are allocated rather than eagerly when classes are loaded. @coleenp Thank you. I think would even be worse; you'd pay at every allocation instead of at oop iteration time; the latter only pays when visiting liveset objects, ideally a tiny subset of those that had been allocated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2027235957 From iklam at openjdk.org Thu Apr 3 15:46:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 15:46:31 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: > Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. > > In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: > > > const char* CDSConfig::input_static_archive_path(); > const char* CDSConfig::input_dynamic_archive_path(); > const char* CDSConfig::output_archive_path(); > > > This PR also cleans up the code by: > - renaming a few function to reflect what they actually do > - moving more "config" management code into cdsConfig.cpp > > There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. > > However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: more clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24401/files - new: https://git.openjdk.org/jdk/pull/24401/files/9e17fedb..3ad42a3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401 PR: https://git.openjdk.org/jdk/pull/24401 From jrose at openjdk.org Thu Apr 3 16:54:55 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 3 Apr 2025 16:54:55 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2] In-Reply-To: References: Message-ID: <2ybtRH9vW_qhCKggV6-RpZGT6d8_-Xn6Zi6LYC1zpAo=.e6630b4d-c390-4299-ad3d-2fea2eb4f5ac@github.com> On Tue, 1 Apr 2025 16:35:38 GMT, Ioi Lam wrote: >> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. >> >> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Refactored CollectClassesForLinking for simplification > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Reverted some fixes in systemDictionaryShared.cpp that causes test failures > - 8353014: Exclude AOT tooling classes from AOT cache Maybe not for this upstream but for the next: I notice that the access to the static filter variable (in `FilterMark`) assumes single-threaded operation, which is true in the assembly phase. But there is no assertion that excludes multi-threaded use. This code will be more maintainable in the long run if there is an explicit assert of some sort that tries to detect if two threads are using the feature at the same time. Sketch: In debug builds only create a second static variable (like `FilterMark::_current_mark_user`) that tells which thread is using the static. Set it in the constructor; manage it LIFO, like the first static variable. And guard all reads and writes of the filter with asserts that check that the current thread is the right one. Set the extra debug variable (`FilterMark::_current_mark_user`) under a briefly locked mutex, for more race detection, but don't read it under a mutex. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2776404919 From coleenp at openjdk.org Thu Apr 3 17:32:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Apr 2025 17:32:53 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 16:31:47 GMT, Coleen Phillimore wrote: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. Thank you for reviewing Leonid. I ran the jvmti tests locally and in mach5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24333#issuecomment-2776484407 From pchilanomate at openjdk.org Thu Apr 3 17:57:51 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 3 Apr 2025 17:57:51 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> <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com> Message-ID: On Thu, 3 Apr 2025 10:10:44 GMT, Serguei Spitsyn wrote: >>> Let me see if I have the sequence of events correct: >>> - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended >>> - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended >>> - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so >> >> This is almost right but let me add a couple of details. >> A suspend request was processed/registered/accepted at the handshake/safepoint-safe point but physical suspension in the `ThreadSelfSuspensionHandshake` has not happened yet which created a problem. Also, the problem is not that the thread goes to post the event. Suspension and event posting are racy by design. The problem is that the `SingleStep` events for this thread are also enabled at the handshake/safepoint-safe point after the suspend request was processed/registered/accepted. >> >>> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it. >> >> I'm also thinking toward this direction. The best way to fix this would be to disallow processing/accepting new suspend requests in `MutexLocker mu(JvmtiThreadState_lock)` which is executed in context of `get_jvmti_thread_state()` call: >> >> inline JvmtiThreadState* JvmtiThreadState::state_for(JavaThread *thread, Handle thread_handle) { >> // In a case of unmounted virtual thread the thread can be null. >> JvmtiThreadState* state = thread_handle == nullptr ? thread->jvmti_thread_state() : >> java_lang_Thread::jvmti_thread_state(thread_handle()); >> if (state == nullptr) { >> MutexLocker mu(JvmtiThreadState_lock); >> . . . >> >> Unfortunately, it looks like it is tricky and risky to do. > > David, we had an internal Zoom meeting with Patricio and agreed on a couple of points (I hope, Patricio will fix me if needed). > #1: > The main (biggest) problem is the call to `JvmtiEventController::thread_started()` in the function `get_jvmti_thread_state()`. The function `JvmtiThreadState::state_for()` is called there if a mounted virtual thread is the current thread and any thread-filtered event is enabled globally. The function `JvmtiThreadState::state_for()` has this line: `MutexLocker mu(JvmtiThreadState_lock);` > > The `JvmtiThreadState_lock` allows safepointing. It is where a JVMTI suspend request for this thread has been processed/registered. The `SingleStep` events for this thread are also enabled after the suspend request was processed/registered. However, suspends are not allowed by this `MutexLocker`. > This is very common code path for any thread-filtered event (e.g. the event can be enabled for a specific thread). > > #2: > This PR fixes this exact issue with this update: > > JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread) { > assert(thread == JavaThread::current(), "must be current thread"); > if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { > JvmtiEventController::thread_started(thread); > + if (thread->is_suspended()) { > + // suspend here if there is a suspend request > + ThreadBlockInVM tbivm(thread); > + } > } > . . . > > > But we also agreed to add a tweak for the function `post_dynamic_code_generated_while_holding_locks()` to disallow suspension in this context. Then it will look like this: > > +JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) { > assert(thread == JavaThread::current(), "must be current thread"); > if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { > JvmtiEventController::thread_started(thread); > + if (allow_suspend && thread->is_suspended()) { > + // suspend here if there is a suspend request > + ThreadBlockInVM tbivm(thread, true /* allow suspend */); > + } > } > . . . > > void JvmtiExport::post_dynamic_code_generated_while_holding_locks(const char* name, > address code_begin, address code_end) > { > . . . > JvmtiThreadState *state = get_jvmti_thread_state(thread, false /* allow_suspend */); > . . . > > > I have already pushed the minor tweak above. > > #3: > We also agreed to investigate more case where a similar situation can occur within... Thanks for the summary Serguei. I would only add that IMO, given that it?s already clear there could be many suspend points before even reaching one of this `JvmtiExport::post_*` methods (like the one shown in #3), I would just address all these cases here too my moving the suspend check outside of the `thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr` conditional. But since this PR has already been blocked for too long I?m okay if we only want to address the specific suspend point in #1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2027494695 From lmesnik at openjdk.org Thu Apr 3 19:32:47 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Apr 2025 19:32:47 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 10:35:29 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. Changes looks reasonable. However it should be another issue, the bug is not fixed, thus should still be open and GK should continue to link bugs to it. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24411#pullrequestreview-2740937806 From lmesnik at openjdk.org Thu Apr 3 19:36:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Apr 2025 19:36:55 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 15:46:31 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. >> >> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: >> >> >> const char* CDSConfig::input_static_archive_path(); >> const char* CDSConfig::input_dynamic_archive_path(); >> const char* CDSConfig::output_archive_path(); >> >> >> This PR also cleans up the code by: >> - renaming a few function to reflect what they actually do >> - moving more "config" management code into cdsConfig.cpp >> >> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. >> >> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > more clean up Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 28: > 26: * @test > 27: * @summary "AOT" aliases for traditional CDS command-line options > 28: * @requires vm.cds & vm.compMode != "Xcomp" The test completely ignore external VM flags, so it should have `@requires vm.flagless ` and no Xcomp exclusion is required. ------------- PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2740946504 PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2027621201 From iklam at openjdk.org Thu Apr 3 20:31:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 20:31:50 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: References: Message-ID: > Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. > > In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: > > > const char* CDSConfig::input_static_archive_path(); > const char* CDSConfig::input_dynamic_archive_path(); > const char* CDSConfig::output_archive_path(); > > > This PR also cleans up the code by: > - renaming a few function to reflect what they actually do > - moving more "config" management code into cdsConfig.cpp > > There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. > > However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @lmesnik comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24401/files - new: https://git.openjdk.org/jdk/pull/24401/files/3ad42a3e..90b4b688 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401 PR: https://git.openjdk.org/jdk/pull/24401 From iklam at openjdk.org Thu Apr 3 21:10:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 21:10:51 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 19:33:12 GMT, Leonid Mesnik wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> more clean up > > test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 28: > >> 26: * @test >> 27: * @summary "AOT" aliases for traditional CDS command-line options >> 28: * @requires vm.cds & vm.compMode != "Xcomp" > > The test completely ignore external VM flags, so it should have > `@requires vm.flagless ` > and no Xcomp exclusion is required. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2027743880 From iklam at openjdk.org Thu Apr 3 21:43:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 21:43:56 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 15:56:02 GMT, Vladimir Kozlov wrote: > @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. > > I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: > > ``` > if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { > FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); > ... > if (AOTClassLinking && is_dumping_final_static_archive()) { > FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); > ``` > > First, I am not sure these conditions are correct. > > Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. > > May be also consider it is error if both conditions are true (we don't support updating archive yet). There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code. In the handling of such "AOT capability flags", I have been using the following pattern: In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default. if (!FLAG_IS_DEFAULT(AOTMode)) { // Using any form of the new AOTMode switch enables enhanced optimizations. FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true); } if (AOTClassLinking) { // If AOTClassLinking is specified, enable all AOT optimizations by default. FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true); } else { // AOTInvokeDynamicLinking depends on AOTClassLinking. FLAG_SET_ERGO(AOTInvokeDynamicLinking, false); } However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used. Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expressing the dependencies programmatically using accessor functions: bool CDSConfig::is_dumping_aot_linked_classes() { if (is_dumping_preimage_static_archive()) { return false; } else if (is_dumping_dynamic_archive()) { return is_using_full_module_graph() && AOTClassLinking; } else if (is_dumping_static_archive()) { return is_dumping_full_module_graph() && AOTClassLinking; } else { return false; } } bool CDSConfig::is_dumping_invokedynamic() { // Requires is_dumping_aot_linked_classes(). Otherwise the classes of some archived heap // objects used by the archive indy callsites may be replaced at runtime. return AOTInvokeDynamicLinking && is_dumping_aot_linked_classes() && is_dumping_heap(); } I would suggest doing something like this for storing AOT code: bool CDSConfig::is_dumping_aot_code() { return StoreAOTCode && is_dumping_final_static_archive() && is_dumping_aot_linked_classes(); } For loading AOT code, it's simpler. We can do a definite check immediately after the AOT cache has been mapped. This also makes the run-time check efficient (whereas the assembly-time checks can take their time). if (LoadAOTCode && cache has AOT code && vm options are compatible) { CDSConfig::_is_using_aot_code = true; } else { CDSConfig::_is_using_aot_code = false; } inline bool CDSConfig::is_using_aot_code() { return CDSConfig::_is_using_aot_code; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2776976568 From iklam at openjdk.org Thu Apr 3 21:55:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 21:55:35 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v3] In-Reply-To: References: Message-ID: > When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. > > In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Added single-thread-only assert for AOTClassFilter - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Refactored CollectClassesForLinking for simplification - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Reverted some fixes in systemDictionaryShared.cpp that causes test failures - 8353014: Exclude AOT tooling classes from AOT cache ------------- Changes: https://git.openjdk.org/jdk/pull/24272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=02 Stats: 286 lines in 14 files changed: 198 ins; 50 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/24272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24272/head:pull/24272 PR: https://git.openjdk.org/jdk/pull/24272 From iklam at openjdk.org Thu Apr 3 22:02:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 22:02:57 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2] In-Reply-To: <2ybtRH9vW_qhCKggV6-RpZGT6d8_-Xn6Zi6LYC1zpAo=.e6630b4d-c390-4299-ad3d-2fea2eb4f5ac@github.com> References: <2ybtRH9vW_qhCKggV6-RpZGT6d8_-Xn6Zi6LYC1zpAo=.e6630b4d-c390-4299-ad3d-2fea2eb4f5ac@github.com> Message-ID: <9hPCxiDhaLduMQPsdxS-6z6kjB-dHz_B0hB49223awg=.5ac3dcc9-9e95-4962-bd48-717a7d41ebe2@github.com> On Thu, 3 Apr 2025 16:52:17 GMT, John R Rose wrote: > Maybe not for this upstream but for the next: I notice that the access to the static filter variable (in `FilterMark`) assumes single-threaded operation, which is true in the assembly phase. But there is no assertion that excludes multi-threaded use. This code will be more maintainable in the long run if there is an explicit assert of some sort that tries to detect if two threads are using the feature at the same time. I changed the assert to use `Atomic::cmpxchg`. Do you think this will be thread safe? > Sketch: In debug builds only create a second static variable (like `FilterMark::_current_mark_user`) that tells which thread is using the static. Set it in the constructor; manage it LIFO, like the first static variable. And guard all reads and writes of the filter with asserts that check that the current thread is the right one. Set the extra debug variable (`FilterMark::_current_mark_user`) under a briefly locked mutex, for more race detection, but don't read it under a mutex. One complication is that the filter is actually used at the end of a training run (where we regenerate the MH holder classes), so there could potentially be lingering application threads that load classes currently. With this PR, all of such classes will be classified as "tooling" and will be excluded from the training run's output (the AOT configuration file), which is just fine. This is the reason I cannot assert against the current thread that consults the filter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2777071172 From lmesnik at openjdk.org Thu Apr 3 22:04:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Apr 2025 22:04:51 GMT Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: Message-ID: <8uj4dh0sl3_zxnm_p8mX24exwE5zSJ6A2Zur_2pAeuI=.090a11b0-2215-4d1f-afce-54aacbbccf5b@github.com> On Sat, 29 Mar 2025 07:53:37 GMT, Thomas Stuefe wrote: > Please consider. > > This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I need this mechanism for some future GC work. > > Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag. > > It also adds a new, rather basic, gtest. > > Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that. > > ---- > > Testing: > - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes > - I ran all runtime/cds tests on Linux x64 > - GHAs Changes requested by lmesnik (Reviewer). test/hotspot/gtest/cds/test_klass_iteration.cpp line 57: > 55: ASSERT_GT(cl_static._c, 0); > 56: > 57: SystemDictionaryShared::iterate_klasses_in_shared_archive(&cl_static, false); Shouldn't it be cl_dynamic here? Can it be zero or assertion is missed ? ------------- PR Review: https://git.openjdk.org/jdk/pull/24311#pullrequestreview-2741286330 PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2027805073 From kvn at openjdk.org Thu Apr 3 22:04:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 3 Apr 2025 22:04:54 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 21:40:48 GMT, Ioi Lam wrote: >> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. >> >> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: >> >> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { >> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); >> ... >> if (AOTClassLinking && is_dumping_final_static_archive()) { >> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); >> >> >> First, I am not sure these conditions are correct. >> >> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. >> >> May be also consider it is error if both conditions are true (we don't support updating archive yet). > >> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. >> >> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: >> >> ``` >> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { >> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); >> ... >> if (AOTClassLinking && is_dumping_final_static_archive()) { >> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); >> ``` >> >> First, I am not sure these conditions are correct. >> >> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. >> >> May be also consider it is error if both conditions are true (we don't support updating archive yet). > > There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code. > > In the handling of such "AOT capability flags", I have been using the following pattern: > > In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default. > > > if (!FLAG_IS_DEFAULT(AOTMode)) { > // Using any form of the new AOTMode switch enables enhanced optimizations. > FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true); > } > > if (AOTClassLinking) { > // If AOTClassLinking is specified, enable all AOT optimizations by default. > FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true); > } else { > // AOTInvokeDynamicLinking depends on AOTClassLinking. > FLAG_SET_ERGO(AOTInvokeDynamicLinking, false); > } > > > However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used. > > Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expres... Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`: MetaspaceShared::initialize_shared_spaces() { ... static_mapinfo->patch_heap_embedded_pointers(); ArchiveHeapLoader::finish_initialization(); Universe::load_archived_object_instances(); + AOTCodeCache::initialize(); The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)? Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2777090009 From lmesnik at openjdk.org Thu Apr 3 22:33:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Apr 2025 22:33:54 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: <2-HeVg85r7inlGOtGBknJ8Kf3S4fhPpZ6PkGaq0kYjo=.626c2128-0b48-42f9-a9cb-1623cce7aca5@github.com> On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers Test changes looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24343#pullrequestreview-2741348281 From ccheung at openjdk.org Thu Apr 3 22:39:07 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Apr 2025 22:39:07 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 07:20:34 GMT, David Holmes wrote: > This issue should be renamed "Remove -Dsun.java.launcher.is_altjvm option". That requires a CSR request to be filed. > I filed a draft CSR [JDK-8353678](https://bugs.openjdk.org/browse/JDK-8353678). > src/hotspot/os/linux/os_linux.cpp line 2778: > >> 2776: char* java_home_var = ::getenv("JAVA_HOME"); >> 2777: if (java_home_var != nullptr && java_home_var[0] != 0) { >> 2778: char* jrelib_p; > > Please remove jre from the name - there is no need to mention jre at all here. Fixed. Also removed the `-Dsun.java.launcher.is_altjvm=true` option from `gtestMain.cpp`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2777145342 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2027837506 From ccheung at openjdk.org Thu Apr 3 22:39:07 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Apr 2025 22:39:07 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: > This change fixes two issues in `os::jvm_path()`: > > - go back 4 instead of 5 slashes and then checking for "/jre/lib"; > - fix the hardcoded "hotspot" sub-directory before the jvm library name. > > Passed tiers 1 - 3 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/eb20233a..33a7ad26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=01-02 Stats: 18 lines in 4 files changed: 0 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From iklam at openjdk.org Thu Apr 3 23:59:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Apr 2025 23:59:29 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v4] In-Reply-To: References: Message-ID: > When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. > > In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Thread safety: AOTClassFilter::is_aot_tooling_class() can potentially be called by multiple threads concurrently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24272/files - new: https://git.openjdk.org/jdk/pull/24272/files/26fd4673..08a3ddf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=02-03 Stats: 43 lines in 2 files changed: 29 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24272/head:pull/24272 PR: https://git.openjdk.org/jdk/pull/24272 From iklam at openjdk.org Fri Apr 4 00:01:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 4 Apr 2025 00:01:50 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2] In-Reply-To: <9hPCxiDhaLduMQPsdxS-6z6kjB-dHz_B0hB49223awg=.5ac3dcc9-9e95-4962-bd48-717a7d41ebe2@github.com> References: <2ybtRH9vW_qhCKggV6-RpZGT6d8_-Xn6Zi6LYC1zpAo=.e6630b4d-c390-4299-ad3d-2fea2eb4f5ac@github.com> <9hPCxiDhaLduMQPsdxS-6z6kjB-dHz_B0hB49223awg=.5ac3dcc9-9e95-4962-bd48-717a7d41ebe2@github.com> Message-ID: <9yPLKVqZG-HfPgtxf6WxbI9WAR_uXIDbIFz583bEm44=.3e198a37-9294-4e0f-ac58-257f38496059@github.com> On Thu, 3 Apr 2025 21:59:46 GMT, Ioi Lam wrote: > > Maybe not for this upstream but for the next: I notice that the access to the static filter variable (in `FilterMark`) assumes single-threaded operation, which is true in the assembly phase. But there is no assertion that excludes multi-threaded use. This code will be more maintainable in the long run if there is an explicit assert of some sort that tries to detect if two threads are using the feature at the same time. > > I changed the assert to use `Atomic::cmpxchg`. Do you think this will be thread safe? > > > Sketch: In debug builds only create a second static variable (like `FilterMark::_current_mark_user`) that tells which thread is using the static. Set it in the constructor; manage it LIFO, like the first static variable. And guard all reads and writes of the filter with asserts that check that the current thread is the right one. Set the extra debug variable (`FilterMark::_current_mark_user`) under a briefly locked mutex, for more race detection, but don't read it under a mutex. > > One complication is that the filter is actually used at the end of a training run (where we regenerate the MH holder classes), so there could potentially be lingering application threads that load classes currently. With this PR, all of such classes will be classified as "tooling" and will be excluded from the training run's output (the AOT configuration file), which is just fine. > > This is the reason I cannot assert against the current thread that consults the filter. I realized that my older version of `AOTClassFilter::is_aot_tooling_class()` could have a race condition when reading `_current_mark`. I uploaded a version that prevents this with the `DumpTimeTable_lock`, which is already held when this function is called. I also use the same lock for the constructor/destructor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2777237881 From fyang at openjdk.org Fri Apr 4 00:07:56 2025 From: fyang at openjdk.org (Fei Yang) Date: Fri, 4 Apr 2025 00:07:56 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable them on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 @robehn : Do you want to take a look? This touch the hwprobe part :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24344#issuecomment-2777244230 From jpai at openjdk.org Fri Apr 4 01:33:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 4 Apr 2025 01:33:48 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v2] In-Reply-To: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com> Message-ID: On Thu, 3 Apr 2025 12:57:40 GMT, Jaikiran Pai wrote: > Please give me a day or so to run this change against our CI. tier1, tier2 and tier3 testing of this change went fine in our CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2777338708 From zgu at openjdk.org Fri Apr 4 01:37:23 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 4 Apr 2025 01:37:23 GMT Subject: RFR: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count Message-ID: It is a simple atomic counter for calculating hash table's load factor, only needs atomic guarantee. ------------- Commit messages: - 8353692: Relax memory constraint on updating ObjectMonitorTable's item count Changes: https://git.openjdk.org/jdk/pull/24432/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353692 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24432/head:pull/24432 PR: https://git.openjdk.org/jdk/pull/24432 From iklam at openjdk.org Fri Apr 4 02:49:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 4 Apr 2025 02:49:36 GMT Subject: RFR: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration Message-ID: This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. @iwanowww @shipilev could you review? ------------- Commit messages: - 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration Changes: https://git.openjdk.org/jdk/pull/24434/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24434&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353694 Stats: 145 lines in 5 files changed: 88 ins; 25 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/24434.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24434/head:pull/24434 PR: https://git.openjdk.org/jdk/pull/24434 From fjiang at openjdk.org Fri Apr 4 04:32:48 2025 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 4 Apr 2025 04:32:48 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable them on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 Looks fine. Thanks! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/24344#pullrequestreview-2741745872 From iklam at openjdk.org Fri Apr 4 06:21:49 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 4 Apr 2025 06:21:49 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive In-Reply-To: References: Message-ID: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin wrote: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation. Hi Timofei, thanks for fixing this. (Sorry I didn't notice this PR until now ...) I have a suggestion for further simplification. src/java.base/share/classes/jdk/internal/misc/CDS.java line 420: > 418: // class loader. Thus it is safe to delegate their loading to system class loader > 419: // (our parent) - this is what the default implementation of loadClass() will do. > 420: return (Class) DEFINE_CLASS.invoke(this, name, res); Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles. HashMap map = ....; JarFile jar = map.get(source) ... or open a new JarFile if not found byte[] buffer = read jar file for the given class name; call ClassLoader.defineClass(buffer, ...) src/java.base/share/classes/jdk/internal/misc/CDS.java line 446: > 444: protected Class findClass(String name) throws ClassNotFoundException { > 445: // Unregistered classes should be found in load(...), registered classes should be > 446: // handeled by parent loaders This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs). I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`). ------------- PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2741852934 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2028155863 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2028141440 From varadam at openjdk.org Fri Apr 4 06:43:55 2025 From: varadam at openjdk.org (Varada M) Date: Fri, 4 Apr 2025 06:43:55 GMT Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output [v4] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 10:30:56 GMT, Varada M wrote: >> AIX changes for attach API to support arbitrary length arguments and the streaming output support. >> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes >> >> tier1, tier2 and tier3 testing is successful with fastdebug level >> >> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8352392: AIX: implement attach API v2 and streaming output Thanks all, ------------- PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2777687525 From varadam at openjdk.org Fri Apr 4 06:43:56 2025 From: varadam at openjdk.org (Varada M) Date: Fri, 4 Apr 2025 06:43:56 GMT Subject: Integrated: 8352392: AIX: implement attach API v2 and streaming output In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 14:33:36 GMT, Varada M wrote: > AIX changes for attach API to support arbitrary length arguments and the streaming output support. > serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes > > tier1, tier2 and tier3 testing is successful with fastdebug level > > JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392) This pull request has now been integrated. Changeset: 41d4a0d7 Author: Varada M URL: https://git.openjdk.org/jdk/commit/41d4a0d7bdda2a96af1e7f549c05d99d68c040dc Stats: 283 lines in 3 files changed: 64 ins; 203 del; 16 mod 8352392: AIX: implement attach API v2 and streaming output Reviewed-by: mdoerr, jkern, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/24177 From dholmes at openjdk.org Fri Apr 4 06:45:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Apr 2025 06:45:49 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 10:35:29 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. >From a failure linking perspective it may be better to create a sub-task of the bug and use that for these enhancements. EDIT just saw Leonid requested the same. Thanks ------------- PR Review: https://git.openjdk.org/jdk/pull/24411#pullrequestreview-2741925948 From stuefe at openjdk.org Fri Apr 4 07:26:18 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Apr 2025 07:26:18 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers Message-ID: Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). Testing: I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. ------------- Commit messages: - not on 32-bit - Deprecate UseCompressedClassPointers Changes: https://git.openjdk.org/jdk/pull/24436/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350753 Stats: 8 lines in 3 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From mgronlun at openjdk.org Fri Apr 4 08:58:57 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 4 Apr 2025 08:58:57 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Thu, 20 Mar 2025 08:39:54 GMT, Aleksey Shipilev wrote: > > That said it is not clear to me that posting the event doesn't violate the requirements that the quick version must maintain: no safepoints, no blocking, no state transitions. ?? > > Huh, that's a good question. There is a `NoSafepointVerifier` at the beginning `ObjectSynchronizer::quick_notify`, so at least the mechanical runtime checks did not fail. I'll run `all` tests with monitor notification event enabled. > > I clicked through the JFR event commit code, and I don't think there are safepoints, indefinite blocking, or state transitions. Can we rely on this, @egahlin, @mgronlun? A JavaThread in state VM or Java running the JFR commit code will not perform a transition or block for a safepoint. It is not waitfree (yet) however because of the JfrStacktrace_lock. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2777993670 From mbaesken at openjdk.org Fri Apr 4 09:07:27 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Apr 2025 09:07:27 GMT Subject: RFR: 8353568: SEGV_BNDERR signal code adjust definition Message-ID: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . The idea was to add a static assert for SEGV_BNDERR sig-code. The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. ------------- Commit messages: - JDK-8353568 Changes: https://git.openjdk.org/jdk/pull/24441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353568 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24441/head:pull/24441 PR: https://git.openjdk.org/jdk/pull/24441 From mbaesken at openjdk.org Fri Apr 4 09:07:27 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Apr 2025 09:07:27 GMT Subject: RFR: 8353568: SEGV_BNDERR signal code adjust definition In-Reply-To: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> References: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> Message-ID: <9yIkE6vSpq3O5HKsbIG9DBjvtnEdoQ5XTMZfp0l931c=.5a0023d0-dd1c-4034-9936-e4be0ff733d2@github.com> On Fri, 4 Apr 2025 09:02:02 GMT, Matthias Baesken wrote: > There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . > > The idea was to add a static assert for SEGV_BNDERR sig-code. > The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. @tstuefe this is the PR for for suggestion regarding SEGV_BNDERR signal code handling. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24441#issuecomment-2778009079 From jkern at openjdk.org Fri Apr 4 09:22:10 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 4 Apr 2025 09:22:10 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v3] In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: Proposal from RealCLanger to further cleanup test Test7029048 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24351/files - new: https://git.openjdk.org/jdk/pull/24351/files/6f32ead9..4dc7da09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=01-02 Stats: 23 lines in 1 file changed: 2 ins; 16 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351 PR: https://git.openjdk.org/jdk/pull/24351 From clanger at openjdk.org Fri Apr 4 09:27:53 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Apr 2025 09:27:53 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v3] In-Reply-To: References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern wrote: >> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. >> >> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > Proposal from RealCLanger to further cleanup test Test7029048 Thanks for adding the additional test cleanups. Let's run it through our testing once more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2778062669 From jsjolen at openjdk.org Fri Apr 4 10:46:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 4 Apr 2025 10:46:53 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests In-Reply-To: References: Message-ID: <39PS4dMUsUPiFM-LU8MzhVzmIGZmgObVD2r5BAT4VwI=.74234b71-ddec-465d-8f2c-add5d835b367@github.com> On Fri, 4 Apr 2025 06:43:28 GMT, David Holmes wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> With these changes integrated, I hope to be able to find the actual culprit of this bug. >> >> I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. > > From a failure linking perspective it may be better to create a sub-task of the bug and use that for these enhancements. > > EDIT just saw Leonid requested the same. > > Thanks This PR now resolves a new ticket which relates-to the original bug. @dholmes-ora , is the subtask way of doing this preferred? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24411#issuecomment-2778287514 From mbaesken at openjdk.org Fri Apr 4 11:30:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Apr 2025 11:30:41 GMT Subject: RFR: 8353568: SEGV_BNDERR signal code adjust definition [v2] In-Reply-To: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> References: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> Message-ID: <3DSg6fSuRfMhuoOhtIuM_VaLJl6ALBG_FScrNqXFg1s=.eca745e2-110c-4b00-8157-baf2aa2447b2@github.com> > There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . > > The idea was to add a static assert for SEGV_BNDERR sig-code. > The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: fix STATIC_ASSERT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24441/files - new: https://git.openjdk.org/jdk/pull/24441/files/06c5cad8..0f7ee417 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24441&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24441&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24441/head:pull/24441 PR: https://git.openjdk.org/jdk/pull/24441 From tpushkin at openjdk.org Fri Apr 4 12:38:32 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 4 Apr 2025 12:38:32 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v2] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Test classpath case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/3be4c5f9..784c1a83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=00-01 Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From stuefe at openjdk.org Fri Apr 4 13:20:00 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Apr 2025 13:20:00 GMT Subject: RFR: 8353568: SEGV_BNDERR signal code adjust definition [v2] In-Reply-To: <3DSg6fSuRfMhuoOhtIuM_VaLJl6ALBG_FScrNqXFg1s=.eca745e2-110c-4b00-8157-baf2aa2447b2@github.com> References: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> <3DSg6fSuRfMhuoOhtIuM_VaLJl6ALBG_FScrNqXFg1s=.eca745e2-110c-4b00-8157-baf2aa2447b2@github.com> Message-ID: <1Rpp9FN0cHLmqwYOKitmxe7NjXHtmcd2L-BHNe1OdJ8=.b6fe6271-e9b4-4b3d-93b2-3a61016074a0@github.com> On Fri, 4 Apr 2025 11:30:41 GMT, Matthias Baesken wrote: >> There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . >> >> The idea was to add a static assert for SEGV_BNDERR sig-code. >> The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > fix STATIC_ASSERT Good and imho trivial. Thanks! ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24441#pullrequestreview-2742970930 From jsjolen at openjdk.org Fri Apr 4 13:48:54 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 4 Apr 2025 13:48:54 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 10:35:29 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. I managed to replicate the error by running the entire test group that this particular test was a part of. The current issue is truly in the log file, it's printed as a string of `?` for the most part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24411#issuecomment-2778778415 From jsjolen at openjdk.org Fri Apr 4 13:52:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 4 Apr 2025 13:52:28 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v2] In-Reply-To: References: Message-ID: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Do not use BufferUpdater ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24411/files - new: https://git.openjdk.org/jdk/pull/24411/files/5ef7fee1..57c3877a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24411&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24411&range=00-01 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24411/head:pull/24411 PR: https://git.openjdk.org/jdk/pull/24411 From lmesnik at openjdk.org Fri Apr 4 14:57:02 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 4 Apr 2025 14:57:02 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v2] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 13:52:28 GMT, Johan Sj?len wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> With these changes integrated, I hope to be able to find the actual culprit of this bug. >> >> I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Do not use BufferUpdater Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24411#pullrequestreview-2743294068 From tpushkin at openjdk.org Fri Apr 4 18:16:19 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 4 Apr 2025 18:16:19 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v3] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation. Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: - Make getResource concurrent-friendly - Don't use URLClassLoader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/784c1a83..5db07cef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=01-02 Stats: 57 lines in 2 files changed: 4 ins; 37 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Fri Apr 4 18:16:19 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 4 Apr 2025 18:16:19 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v3] In-Reply-To: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> References: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> Message-ID: On Fri, 4 Apr 2025 05:58:47 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: >> >> - Make getResource concurrent-friendly >> - Don't use URLClassLoader > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 446: > >> 444: protected Class findClass(String name) throws ClassNotFoundException { >> 445: // Unregistered classes should be found in load(...), registered classes should be >> 446: // handeled by parent loaders > > This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. > > We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs). > > I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`). Thank you for the review! > We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs). With this approach having multiple unregistered classes with the same name is not possible (JVM will not allow this for a single class loader) so if you are still planning to support this in the near future it would be better to go with the approach originally suggested in the issue: continue using multiple unregistered class loaders but record class loader ID in class list and create only one archiving class loader per recorded ID. But that would be a larger change since it requires class list format to be changed. > I am not sure if the current tests includes a case where a class name Foo exists both in the classpath as well as in a custom loader Pre-existing `ClassFromSystemModule` test seems to test the boot classpath case. I've also added a new test for the app classpath case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029248783 From tpushkin at openjdk.org Fri Apr 4 18:19:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 4 Apr 2025 18:19:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v3] In-Reply-To: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> References: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> Message-ID: On Fri, 4 Apr 2025 06:15:27 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: >> >> - Make getResource concurrent-friendly >> - Don't use URLClassLoader > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 420: > >> 418: // class loader. Thus it is safe to delegate their loading to system class loader >> 419: // (our parent) - this is what the default implementation of loadClass() will do. >> 420: return (Class) DEFINE_CLASS.invoke(this, name, res); > > Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles. > > > HashMap map = ....; > JarFile jar = map.get(source) ... or open a new JarFile if not found > byte[] buffer = read jar file for the given class name; > call ClassLoader.defineClass(buffer, ...) All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely. `URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029253444 From iklam at openjdk.org Fri Apr 4 21:14:53 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 4 Apr 2025 21:14:53 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v3] In-Reply-To: References: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> Message-ID: On Fri, 4 Apr 2025 18:17:14 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 420: >> >>> 418: // class loader. Thus it is safe to delegate their loading to system class loader >>> 419: // (our parent) - this is what the default implementation of loadClass() will do. >>> 420: return (Class) DEFINE_CLASS.invoke(this, name, res); >> >> Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles. >> >> >> HashMap map = ....; >> JarFile jar = map.get(source) ... or open a new JarFile if not found >> byte[] buffer = read jar file for the given class name; >> call ClassLoader.defineClass(buffer, ...) > > All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely. > > `URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1). I prefer the changes in your separate branch. URLClassPath is intended for sequential access. Adding the new method for random access could introduce extraneous requirements that might affect future evolution of URLClassPath. As the code for JarSource and Dir Source is quite small, I think it's acceptable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029438393 From iklam at openjdk.org Fri Apr 4 21:17:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 4 Apr 2025 21:17:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v3] In-Reply-To: References: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> Message-ID: On Fri, 4 Apr 2025 18:13:24 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 446: >> >>> 444: protected Class findClass(String name) throws ClassNotFoundException { >>> 445: // Unregistered classes should be found in load(...), registered classes should be >>> 446: // handeled by parent loaders >> >> This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. >> >> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs). >> >> I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`). > > Thank you for the review! > >> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs). > > With this approach having multiple unregistered classes with the same name is not possible (JVM will not allow this for a single class loader) so if you are still planning to support this in the near future it would be better to go with the approach originally suggested in the issue: continue using multiple unregistered class loaders but record class loader ID in class list and create only one archiving class loader per recorded ID. But that would be a larger change since it requires class list format to be changed. > >> I am not sure if the current tests includes a case where a class name Foo exists both in the classpath as well as in a custom loader > > Pre-existing `ClassFromSystemModule` test seems to test the boot classpath case. I've also added a new test for the app classpath case. We don't have immediate plans for supporting multiple classes of the same name. I suspect any future enhancements would be available only through new "AOT" workflow, where the training information, including the unregistered classes, would be encoded in the binary AOT configuration file. Therefore, these future enhancements will not affect this particular case (loading unregistered classes from the classlist text file). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029445262 From jrose at openjdk.org Fri Apr 4 22:32:03 2025 From: jrose at openjdk.org (John R Rose) Date: Fri, 4 Apr 2025 22:32:03 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v4] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 23:59:29 GMT, Ioi Lam wrote: >> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. >> >> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Thread safety: AOTClassFilter::is_aot_tooling_class() can potentially be called by multiple threads concurrently CAS is very good because it can easily detect the error condition of two writers colliding. But your final version is fine also; just use a tiny critical section and check pre- and post-states. It's good that you confined the API to one thread; it's more risky to do things that other threads may or may not overhear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2779828675 From aturbanov at openjdk.org Sat Apr 5 16:51:51 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 5 Apr 2025 16:51:51 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers test/hotspot/jtreg/runtime/NMT/NMemLimitTest.java line 272: > 270: testMultiLimit(LimitType.Malloc); > 271: testMultiLimit(LimitType.Mmap); > 272: } else if (args[0].equals("malloc-mmap-limit-mix-malloc-fatal")){ Suggestion: } else if (args[0].equals("malloc-mmap-limit-mix-malloc-fatal")) { test/hotspot/jtreg/runtime/NMT/NMemLimitTest.java line 274: > 272: } else if (args[0].equals("malloc-mmap-limit-mix-malloc-fatal")){ > 273: testMallocMMapLimitMixMMallocFatal(); > 274: } else if (args[0].equals("malloc-mmap-limit-mix-mmap-fatal")){ Suggestion: } else if (args[0].equals("malloc-mmap-limit-mix-mmap-fatal")) { test/hotspot/jtreg/runtime/NMT/NMemLimitTest.java line 276: > 274: } else if (args[0].equals("malloc-mmap-limit-mix-mmap-fatal")){ > 275: testMallocMMapLimitMixMMapFatal(); > 276: } else if (args[0].equals("malloc-mmap-limit-mix-neither-failed")){ Suggestion: } else if (args[0].equals("malloc-mmap-limit-mix-neither-failed")) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24343#discussion_r2029917625 PR Review Comment: https://git.openjdk.org/jdk/pull/24343#discussion_r2029917941 PR Review Comment: https://git.openjdk.org/jdk/pull/24343#discussion_r2029918104 From stuefe at openjdk.org Sun Apr 6 09:08:34 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 6 Apr 2025 09:08:34 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v2] In-Reply-To: References: Message-ID: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers - not on 32-bit - Deprecate UseCompressedClassPointers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/bb73be7d..71ee02a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=00-01 Stats: 12345 lines in 476 files changed: 8696 ins; 2786 del; 863 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From duke at openjdk.org Sun Apr 6 12:42:49 2025 From: duke at openjdk.org (ExE Boss) Date: Sun, 6 Apr 2025 12:42:49 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v2] In-Reply-To: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> References: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> Message-ID: <8I2t9F_TDMX554zXRH4tn0Em0pqx7o57_pyxK80_NpM=.1276a3cb-e4a9-4660-8dd0-5dda542aa34d@github.com> On Sun, 6 Apr 2025 09:08:34 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - not on 32-bit > - Deprecate UseCompressedClassPointers test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 65: > 63: // deprecated alias flags (see also aliased_jvm_flags): > 64: {"CreateMinidumpOnCrash", "false"}, > 65: {"UseCompressedClassPointers", "false"}, `UseCompressedClassPointers` is?not an?alias?flag: Suggestion: {"UseCompressedClassPointers", "false"}, // deprecated alias flags (see also aliased_jvm_flags): {"CreateMinidumpOnCrash", "false"}, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2030140764 From iklam at openjdk.org Sun Apr 6 21:30:49 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 6 Apr 2025 21:30:49 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 21:40:48 GMT, Ioi Lam wrote: >> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. >> >> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: >> >> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { >> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); >> ... >> if (AOTClassLinking && is_dumping_final_static_archive()) { >> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); >> >> >> First, I am not sure these conditions are correct. >> >> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. >> >> May be also consider it is error if both conditions are true (we don't support updating archive yet). > >> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. >> >> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: >> >> ``` >> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { >> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); >> ... >> if (AOTClassLinking && is_dumping_final_static_archive()) { >> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); >> ``` >> >> First, I am not sure these conditions are correct. >> >> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. >> >> May be also consider it is error if both conditions are true (we don't support updating archive yet). > > There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code. > > In the handling of such "AOT capability flags", I have been using the following pattern: > > In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default. > > > if (!FLAG_IS_DEFAULT(AOTMode)) { > // Using any form of the new AOTMode switch enables enhanced optimizations. > FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true); > } > > if (AOTClassLinking) { > // If AOTClassLinking is specified, enable all AOT optimizations by default. > FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true); > } else { > // AOTInvokeDynamicLinking depends on AOTClassLinking. > FLAG_SET_ERGO(AOTInvokeDynamicLinking, false); > } > > > However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used. > > Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expres... > Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`: > > ``` > MetaspaceShared::initialize_shared_spaces() { > ... > static_mapinfo->patch_heap_embedded_pointers(); > ArchiveHeapLoader::finish_initialization(); > Universe::load_archived_object_instances(); > + AOTCodeCache::initialize(); > ``` > > The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)? > > Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere. Yes, at this point all configuration related to AOT should be final. You can set the final values for the `Store|LoadAOTCode` flags here. `StoreAOTCode` should be true only if `CDSConfig::is_dumping_final_static_archive()` is true. `LoadAOTCode` should be true only if `CDSConfig::is_loading_archive()` is true and the archive contains AOT code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2781681413 From dholmes at openjdk.org Sun Apr 6 21:50:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Apr 2025 21:50:55 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v2] In-Reply-To: References: Message-ID: <71sd0I30eVERebvPJs3qrTCvLOOLKwxLAhBll7BukNU=.7f14cbb2-9fce-49fb-af6a-aef61b78b41c@github.com> On Fri, 4 Apr 2025 13:52:28 GMT, Johan Sj?len wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> With these changes integrated, I hope to be able to find the actual culprit of this bug. >> >> I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Do not use BufferUpdater I'm not following some of your changes sorry, and it is unclear whether these are intended to be permanent or temporary adjustments to the test in places. ?? test/hotspot/gtest/logging/test_asynclog.cpp line 81: > 79: > 80: // shrink async buffer. > 81: //AsyncLogWriter::BufferUpdater saver(1024); You have some comments that no longer apply once you comment this out. It is also unclear why you are commenting it out and not just deleting it. test/hotspot/gtest/logging/test_asynclog.cpp line 87: > 85: // write more messages than its capacity in burst > 86: for (size_t i = 0; i < (sz / str_size); ++i) { > 87: lm.debug("a lot of log..."); Shouldn't this be passing `str`? test/hotspot/gtest/logging/test_asynclog.cpp line 92: > 90: lm.debug("a lot of log..."); > 91: lm.debug("a lot of log..."); > 92: lm.debug("a lot of log..."); Shouldn't these be passing `str`? ------------- PR Review: https://git.openjdk.org/jdk/pull/24411#pullrequestreview-2745284593 PR Review Comment: https://git.openjdk.org/jdk/pull/24411#discussion_r2030279918 PR Review Comment: https://git.openjdk.org/jdk/pull/24411#discussion_r2030280254 PR Review Comment: https://git.openjdk.org/jdk/pull/24411#discussion_r2030280308 From dholmes at openjdk.org Sun Apr 6 22:07:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Apr 2025 22:07:55 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:39:07 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comment How does the gtest launcher work with these changes? There the libjvm.so is in a completely different place to the JDK. ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2781694742 From dholmes at openjdk.org Sun Apr 6 22:11:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Apr 2025 22:11:49 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: <4QkjjgfLBJ06780QOMOftcZVhyzmeiWt1eO_u_V_VQU=.3ee938b2-0792-4300-9562-be69064d9542@github.com> On Thu, 3 Apr 2025 22:39:07 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comment Also as discussed offline picking up JAVA_HOME from the environment is not the right thing to do in general. It only worked with -Dsun.java.launcher.is_altjvm because we ensured we set JAVA_HOME when using the property. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2781695926 From dholmes at openjdk.org Sun Apr 6 22:22:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Apr 2025 22:22:56 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Tue, 25 Mar 2025 09:15:38 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/objectMonitor.hpp line 388: > 386: void notifyAll(TRAPS); > 387: void quick_notify(TRAPS); > 388: void quick_notifyAll(TRAPS); These should not be declared with TRAPS as they don't throw exceptions (and must not!). These should simply take a `JavaThread* current` parameter. ------------- PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2745291465 PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2030287303 From ccheung at openjdk.org Sun Apr 6 23:55:01 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Sun, 6 Apr 2025 23:55:01 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: > This change fixes two issues in `os::jvm_path()`: > > - go back 4 instead of 5 slashes and then checking for "/jre/lib"; > - fix the hardcoded "hotspot" sub-directory before the jvm library name. > > Passed tiers 1 - 3 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: fix issues related to JAVA_HOME and gtest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/33a7ad26..2de1d3a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=02-03 Stats: 178 lines in 6 files changed: 69 ins; 47 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From ccheung at openjdk.org Sun Apr 6 23:57:48 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Sun, 6 Apr 2025 23:57:48 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: On Sun, 6 Apr 2025 22:05:31 GMT, David Holmes wrote: > How does the gtest launcher work with these changes? There the libjvm.so is in a completely different place to the JDK. ?? gtest launcher sets the `-XX:+ExecutingUnitTests` option. My updated fix is to capture the option in `Arguments::process_sun_java_launcher_properties()` so that the `os::jvm_path()` can check if the option is set before using `JAVA_HOME` setting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2781736288 From dholmes at openjdk.org Mon Apr 7 04:50:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 04:50:49 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: On Sun, 6 Apr 2025 23:55:01 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > fix issues related to JAVA_HOME and gtest Can you update the PR description to clarify what is now being done please Calvin. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2782007820 From dholmes at openjdk.org Mon Apr 7 06:08:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 06:08:56 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: On Sun, 6 Apr 2025 23:55:01 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > fix issues related to JAVA_HOME and gtest So basically now we have removed the `-Dsun.java.launcher.is_altjvm` option and replaced its use with gtest by the use of the `executing_unit_tests` functionality. Okay. A few minor requests. Thanks. src/hotspot/os/aix/os_aix.cpp line 1309: > 1307: assert(rp != nullptr, "error in realpath(): maybe the 'path' argument is too long?"); > 1308: > 1309: if(Arguments::executing_unit_tests()) { Suggestion: if (Arguments::executing_unit_tests()) { src/hotspot/os/linux/os_linux.cpp line 2775: > 2773: } > 2774: > 2775: if (Arguments::executing_unit_tests()) { Suggestion: // If executing unit tests we require JAVA_HOME to point to the real JDK. if (Arguments::executing_unit_tests()) { src/hotspot/os/linux/os_linux.cpp line 2802: > 2800: // Use current module name "libjvm.so" > 2801: len = (int)strlen(buf); > 2802: snprintf(buf + len, buflen-len, "/%s/libjvm%s", Suggestion: snprintf(buf + len, buflen - len, "/%s/libjvm%s", src/hotspot/os/linux/os_linux.cpp line 2808: > 2806: } > 2807: > 2808: // determine if this is a legacy image or modules image Delete the comment on the next line about the jre subdirectory please. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24310#pullrequestreview-2741876785 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2030459810 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2030453863 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2030458706 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2030456402 From dholmes at openjdk.org Mon Apr 7 06:08:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 06:08:58 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 05:02:03 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix issues related to JAVA_HOME and gtest > > src/hotspot/os/linux/os_linux.cpp line 2808: > >> 2806: } >> 2807: >> 2808: // determine if this is a legacy image or modules image > > Delete the comment on the next line about the jre subdirectory please. This applies in all versions of the file of course, where it exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2030509864 From dholmes at openjdk.org Mon Apr 7 06:08:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 06:08:57 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:39:07 GMT, Calvin Cheung wrote: >> This change fixes two issues in `os::jvm_path()`: >> >> - go back 4 instead of 5 slashes and then checking for "/jre/lib"; >> - fix the hardcoded "hotspot" sub-directory before the jvm library name. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comment src/hotspot/os/aix/os_aix.cpp line 1326: > 1324: } > 1325: > 1326: // modules image doesn't have "jre" subdirectory Delete comment please ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2028155906 From rehn at openjdk.org Mon Apr 7 06:13:53 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 7 Apr 2025 06:13:53 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable them on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 Ok, sure, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24344#pullrequestreview-2745614347 From dholmes at openjdk.org Mon Apr 7 06:26:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 06:26:54 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v2] In-Reply-To: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> References: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> Message-ID: <_mfYDSSNg3qOCLp7CIm7wZPRaZXJUl3UN35ZKrr7rG0=.4a39db4d-f89a-436b-b816-833317928dd3@github.com> On Sun, 6 Apr 2025 09:08:34 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - not on 32-bit > - Deprecate UseCompressedClassPointers Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/arguments.cpp line 532: > 530: { "CreateMinidumpOnCrash", JDK_Version::jdk(9), JDK_Version::undefined(), JDK_Version::undefined() }, > 531: #ifdef _LP64 > 532: // Note: on 32-bit, the option is not available; therefore a deprecation notice makes no sense. No need for the comment - the ifdef tells you this is something only for 64-bit src/hotspot/share/runtime/arguments.cpp line 533: > 531: #ifdef _LP64 > 532: // Note: on 32-bit, the option is not available; therefore a deprecation notice makes no sense. > 533: { "UseCompressedClassPointers", JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::undefined() }, This is in the wrong section - this is not an aliased flag ------------- PR Review: https://git.openjdk.org/jdk/pull/24436#pullrequestreview-2745627858 PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2030522933 PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2030524880 From jsjolen at openjdk.org Mon Apr 7 06:29:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 7 Apr 2025 06:29:50 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v2] In-Reply-To: <71sd0I30eVERebvPJs3qrTCvLOOLKwxLAhBll7BukNU=.7f14cbb2-9fce-49fb-af6a-aef61b78b41c@github.com> References: <71sd0I30eVERebvPJs3qrTCvLOOLKwxLAhBll7BukNU=.7f14cbb2-9fce-49fb-af6a-aef61b78b41c@github.com> Message-ID: On Sun, 6 Apr 2025 21:45:04 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Do not use BufferUpdater > > test/hotspot/gtest/logging/test_asynclog.cpp line 81: > >> 79: >> 80: // shrink async buffer. >> 81: //AsyncLogWriter::BufferUpdater saver(1024); > > You have some comments that no longer apply once you comment this out. It is also unclear why you are commenting it out and not just deleting it. Hi, the TL;DR is that that was a mistake. The long reason is: I wanted to try skipping the buffer and so I committed and pushed it to make it accessible on my build computer, but I forgot that it's up for a PR. That's actually the reason for all the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24411#discussion_r2030530924 From dholmes at openjdk.org Mon Apr 7 06:53:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Apr 2025 06:53:51 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 16:31:47 GMT, Coleen Phillimore wrote: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. Functional changes look fine - some minor requests regarding comments. I'm struggling a bit with the test logic. src/hotspot/share/classfile/klassFactory.cpp line 79: > 77: ClassFileStream* stream = new ClassFileStream(ptr, > 78: pointer_delta_as_int(end_ptr, ptr), > 79: cfs->source(), false, /* from_class_file_load_hook */ true); Can you comment what the `false` means as well please - looks odd to only document one of the boolean parameters. src/hotspot/share/classfile/klassFactory.cpp line 158: > 156: stream = new ClassFileStream(ptr, > 157: pointer_delta_as_int(end_ptr, ptr), > 158: stream->source(), false, /* from_class_file_load_hook */ true); Can you comment what the `false` means as well please - looks odd to only document one of the boolean parameters. test/hotspot/jtreg/runtime/modules/PatchModule/PatchModuleJavaBaseVerify.java line 27: > 25: * @test > 26: * @bug 8351654 > 27: * @summary Make sure --patch-module for java.base verifies the classfile. ?? But in this scenario the injected class is not verified. test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 25: > 23: > 24: /* > 25: * @test Verifier should verify ClassFileLoadHook bytes even if on bootclasspath Suggestion: * @test * @summary Verifier should verify ClassFileLoadHook bytes even if on bootclasspath test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 71: > 69: @Override > 70: public byte[] transform(Module module, ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { > 71: //System.out.println("Maybe transforming module class " + className); Suggestion: Delete the commented out line test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 103: > 101: if (DEBUG) Files.write(Path.of("bad.class"), bytes); > 102: } catch (Throwable e) { > 103: System.out.println(e); Suggestion: Delete the println here as it will just complicate debugging a failure. test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 176: > 174: // Now load the class for the VerifyError. > 175: System.out.println("1 hour is " + Duration.ofHours(1).getSeconds() + " seconds"); > 176: if (!verifyErrorThrown) { I'm a bit confused about the logic here - are there three possibilities: 1. the load threw VerifyError and will be caught below 2. Another part of the code (where?) threw VerifyError, caught it and set `verifyErrorThrown` to true 3. No verification error occurred at all. How do we trigger case 1 versus case 2? ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24333#pullrequestreview-2745656854 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030541130 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030541367 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030543647 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030545472 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030547091 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030557496 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2030559140 From mbaesken at openjdk.org Mon Apr 7 07:17:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 7 Apr 2025 07:17:56 GMT Subject: RFR: 8353568: SEGV_BNDERR signal code adjust definition [v2] In-Reply-To: <3DSg6fSuRfMhuoOhtIuM_VaLJl6ALBG_FScrNqXFg1s=.eca745e2-110c-4b00-8157-baf2aa2447b2@github.com> References: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> <3DSg6fSuRfMhuoOhtIuM_VaLJl6ALBG_FScrNqXFg1s=.eca745e2-110c-4b00-8157-baf2aa2447b2@github.com> Message-ID: On Fri, 4 Apr 2025 11:30:41 GMT, Matthias Baesken wrote: >> There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . >> >> The idea was to add a static assert for SEGV_BNDERR sig-code. >> The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > fix STATIC_ASSERT Thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24441#issuecomment-2782251832 From mbaesken at openjdk.org Mon Apr 7 07:17:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 7 Apr 2025 07:17:57 GMT Subject: Integrated: 8353568: SEGV_BNDERR signal code adjust definition In-Reply-To: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> References: <0TwpctBtyPosJC6snGnGqSXPH7Ff0LEHpPwMpTml5fQ=.80899a85-7f76-4166-83c3-047f7968a1de@github.com> Message-ID: On Fri, 4 Apr 2025 09:02:02 GMT, Matthias Baesken wrote: > There was a remark from Thomas Stuefe in https://github.com/openjdk/jdk24u/pull/175 . > > The idea was to add a static assert for SEGV_BNDERR sig-code. > The static assert will alert us if we build on a newer Linux version and turns out we were wrong with our assumed number. This pull request has now been integrated. Changeset: 6abf4e6d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6abf4e6d4d9f948b8ae51aec731b94ba7acd022e Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8353568: SEGV_BNDERR signal code adjust definition Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/24441 From fyang at openjdk.org Mon Apr 7 07:23:54 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 7 Apr 2025 07:23:54 GMT Subject: Integrated: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable them on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 This pull request has now been integrated. Changeset: d1e91fcd Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/d1e91fcd620ce7e5527363dfa44543872f419c73 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod 8353344: RISC-V: Detect and enable several extensions for debug builds Reviewed-by: mli, fjiang, rehn ------------- PR: https://git.openjdk.org/jdk/pull/24344 From fyang at openjdk.org Mon Apr 7 07:23:53 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 7 Apr 2025 07:23:53 GMT Subject: RFR: 8353344: RISC-V: Detect and enable several extensions for debug builds In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 04:56:01 GMT, Fei Yang wrote: > Hi, please consider this small change. > Support for some riscv extesions is in experimental status due to lack of hardware implementations. > They won't be auto enabled at startup even through they could be detected through linux hwprobe syscall. > And it's not that convenient to enable them on the command line and easy to snip away when doing regression test. > To ensure they get some proper correctness test coverage, this turns on some of them for debug builds. > This follows the order of linux hwprobe syscall macro definitions [1]. I can consider adding more if this makes sense. > Manually tested on the command line with fastdebug build using qemu-system (running kernel-6.11). > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zbkb > bool UseZbkb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvbb > bool UseZvbb = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zvkn > bool UseZvkn = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > ubuntu at ubuntu:~/jdk$ java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version | grep Zfa > bool UseZfa = true {ARCH experimental} {default} > openjdk version "25-internal" 2025-09-16 > OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.ubuntu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.ubuntu.jdk, mixed mode, sharing) > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L46-L82 Thanks for the review! Let's ------------- PR Comment: https://git.openjdk.org/jdk/pull/24344#issuecomment-2782266502 From tpushkin at openjdk.org Mon Apr 7 07:46:52 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 7 Apr 2025 07:46:52 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: References: Message-ID: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Don't use URLClassPath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/5db07cef..16a2f951 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=02-03 Stats: 150 lines in 4 files changed: 62 ins; 67 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From fyang at openjdk.org Mon Apr 7 07:52:59 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 7 Apr 2025 07:52:59 GMT Subject: RFR: 8353829: RISC-V: Auto-enable several more extensions for debug builds Message-ID: Hi, Please consider this followup change after https://bugs.openjdk.org/browse/JDK-8353344. This adds detection and enablement of two more extensions: Ztso and Zacas. Testing: hs:tier1-hs:tier3 tested with qemu-system equipmented with these extensions. ------------- Commit messages: - 8353829: RISC-V: Auto-enable several more extensions for debug builds Changes: https://git.openjdk.org/jdk/pull/24478/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24478&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353829 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24478.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24478/head:pull/24478 PR: https://git.openjdk.org/jdk/pull/24478 From shade at openjdk.org Mon Apr 7 08:04:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 7 Apr 2025 08:04:08 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v3] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Sun, 6 Apr 2025 22:20:11 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8352256-quick-notify-jfr >> - Review comment >> - Fix > > src/hotspot/share/runtime/objectMonitor.hpp line 388: > >> 386: void notifyAll(TRAPS); >> 387: void quick_notify(TRAPS); >> 388: void quick_notifyAll(TRAPS); > > These should not be declared with TRAPS as they don't throw exceptions (and must not!). These should simply take a `JavaThread* current` parameter. Makes sense, fixed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2030668190 From shade at openjdk.org Mon Apr 7 08:04:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 7 Apr 2025 08:04:07 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v4] In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: > Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Do explicit thread - Merge branch 'master' into JDK-8352256-quick-notify-jfr - Merge branch 'master' into JDK-8352256-quick-notify-jfr - Review comment - Fix ------------- Changes: https://git.openjdk.org/jdk/pull/24097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24097&range=03 Stats: 21 lines in 3 files changed: 14 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24097.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24097/head:pull/24097 PR: https://git.openjdk.org/jdk/pull/24097 From kevinw at openjdk.org Mon Apr 7 09:28:38 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 7 Apr 2025 09:28:38 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p Message-ID: This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. It has always done a manual "root plus pid plus extension" on the default filename only, and should move to using Argument::copy_expand_pid() like we do with other such filenames. We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). ------------- Commit messages: - 8353727: HeapDumpPath doesn't expand %p Changes: https://git.openjdk.org/jdk/pull/24482/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353727 Stats: 73 lines in 2 files changed: 26 ins; 23 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/24482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482 PR: https://git.openjdk.org/jdk/pull/24482 From stuefe at openjdk.org Mon Apr 7 09:57:44 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 7 Apr 2025 09:57:44 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v3] In-Reply-To: References: Message-ID: > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe 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: - move line - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers - not on 32-bit - Deprecate UseCompressedClassPointers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/71ee02a8..729d2963 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=01-02 Stats: 2508 lines in 29 files changed: 1260 ins; 1131 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From stuefe at openjdk.org Mon Apr 7 09:57:47 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 7 Apr 2025 09:57:47 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v2] In-Reply-To: <_mfYDSSNg3qOCLp7CIm7wZPRaZXJUl3UN35ZKrr7rG0=.4a39db4d-f89a-436b-b816-833317928dd3@github.com> References: <1uW3KxxtB5tWftgzAyfRqoIPbbQkQ1a5OBJ5VAR3SZQ=.aa5b542c-5eb6-45cf-bd9f-b143c91fee1f@github.com> <_mfYDSSNg3qOCLp7CIm7wZPRaZXJUl3UN35ZKrr7rG0=.4a39db4d-f89a-436b-b816-833317928dd3@github.com> Message-ID: <3lcsZZSNPp_dGze2o36aHuUx50RxCwxBwgonPpfXc6A=.0fee5f9d-6965-4518-b2b0-639d7aeaf2be@github.com> On Mon, 7 Apr 2025 06:19:37 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - not on 32-bit >> - Deprecate UseCompressedClassPointers > > src/hotspot/share/runtime/arguments.cpp line 532: > >> 530: { "CreateMinidumpOnCrash", JDK_Version::jdk(9), JDK_Version::undefined(), JDK_Version::undefined() }, >> 531: #ifdef _LP64 >> 532: // Note: on 32-bit, the option is not available; therefore a deprecation notice makes no sense. > > No need for the comment - the ifdef tells you this is something only for 64-bit I initially thought a casual reader may interpret the ifdef as "the option is still accepted on 32-bit" - to know otherwise, one has to read globals.hpp. But I am fine with removing the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2030892614 From stuefe at openjdk.org Mon Apr 7 10:02:19 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 7 Apr 2025 10:02:19 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: move line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/729d2963..5afdff50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From tpushkin at openjdk.org Mon Apr 7 11:39:52 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 7 Apr 2025 11:39:52 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: References: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com> Message-ID: On Fri, 4 Apr 2025 21:11:52 GMT, Ioi Lam wrote: >> All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely. >> >> `URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1). > > I prefer the changes in your separate branch. URLClassPath is intended for sequential access. Adding the new method for random access could introduce extraneous requirements that might affect future evolution of URLClassPath. As the code for JarSource and Dir Source is quite small, I think it's acceptable. Agree, I've brought it here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031053093 From coleenp at openjdk.org Mon Apr 7 12:18:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Apr 2025 12:18:52 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 10:02:19 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > move line test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 62: > 60: {"AllowRedefinitionToAddDeleteMethods", "true"}, > 61: {"LockingMode", "1"}, > 62: {"UseCompressedClassPointers", "false"}, If you run this test on an arm32, will it fail because UseCompressedClassPointers is unrecognized there? Does this need to be conditional on 64 bit platforms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2031115368 From clanger at openjdk.org Mon Apr 7 12:18:56 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 7 Apr 2025 12:18:56 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v3] In-Reply-To: References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern wrote: >> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. >> >> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > Proposal from RealCLanger to further cleanup test Test7029048 No regressions spotted, even after the test cleanup. LGTM. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2746610204 From zgu at openjdk.org Mon Apr 7 12:35:53 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Apr 2025 12:35:53 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls wrote: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). @kevinjwalls I have [JDK-8349083](https://bugs.openjdk.org/browse/JDK-8349083) to address similar issues. AFAICT, there are 3 separate code to handle filename expansion and logging has the most complete support, It will be nice to unify them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2783181347 From azafari at openjdk.org Mon Apr 7 12:37:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 7 Apr 2025 12:37:30 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes. New check_tree impl and visualization. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/9874c56f..f66ca19b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=06-07 Stats: 257 lines in 2 files changed: 205 ins; 4 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Mon Apr 7 12:44:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 7 Apr 2025 12:44:06 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:37:30 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes. New check_tree impl and visualization. Dear Reviewers, In the `test_vmatree.cpp` at test `NMTVMATreeTest.SeparateStacksForCommitAndReserve`, the nodes in the tree and their metadata are visualized in commented lines. A new data-structure is also introduced to use the info in the visualization for checking (using the `check_tree` function) the actual and expected values in a tree. The structure and the visulazation are made similar as much as possible. One can use the comments first to analyze the test-case and then use the structure and the function to check expected results. Or, the structure alone can be used both as illustration and checking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2783204779 From azafari at openjdk.org Mon Apr 7 12:53:52 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 7 Apr 2025 12:53:52 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v7] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 14:42:22 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the GHA failures. > > src/hotspot/share/nmt/vmatree.cpp line 68: > >> 66: stB.in.set_commit_stack(metadata.stack_idx); >> 67: stA.out.set_reserve_stack(NativeCallStackStorage::invalid); >> 68: stB.in.set_reserve_stack(NativeCallStackStorage::invalid); > > Set these as `metadata.stack_idx` to fix the test case below. Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 847: > >> 845: tree.commit_mapping(0, 100, call_stack_1); >> 846: expected(tree, 0, -1, si_1, __LINE__); >> 847: } > > Should have both reserve and commit as `si_1`. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031174410 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031174149 From jkern at openjdk.org Mon Apr 7 12:53:55 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 7 Apr 2025 12:53:55 GMT Subject: Integrated: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: <99CT0RitnWPbJEJgRb6KLx3J030x1c8CGp7wnX0kxLY=.9065328e-6445-489f-9937-46fbb4c3eff0@github.com> On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. This pull request has now been integrated. Changeset: 9128ec61 Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/9128ec61df430a2eb352f58ec9799d332f7b1a10 Stats: 31 lines in 3 files changed: 2 ins; 20 del; 9 mod 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH Reviewed-by: clanger, ihse, jpai ------------- PR: https://git.openjdk.org/jdk/pull/24351 From coleenp at openjdk.org Mon Apr 7 12:58:12 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Apr 2025 12:58:12 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v2] In-Reply-To: References: Message-ID: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with four additional commits since the last revision: - Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Fix test comment and add comments for parameters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24333/files - new: https://git.openjdk.org/jdk/pull/24333/files/6e59012c..3c17e148 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24333&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24333&range=00-01 Stats: 11 lines in 3 files changed: 5 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24333/head:pull/24333 PR: https://git.openjdk.org/jdk/pull/24333 From gziemski at openjdk.org Mon Apr 7 13:07:55 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 7 Apr 2025 13:07:55 GMT Subject: Integrated: 8341095: Possible overflow in os::Posix::print_uptime_info In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 20:08:16 GMT, Gerard Ziemski wrote: > This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file. > > There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone. This pull request has now been integrated. Changeset: 77fff61b Author: Gerard Ziemski URL: https://git.openjdk.org/jdk/commit/77fff61b864054b0029ee5d38f6293534db10ce1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8341095: Possible overflow in os::Posix::print_uptime_info Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24140 From coleenp at openjdk.org Mon Apr 7 13:26:13 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Apr 2025 13:26:13 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v3] In-Reply-To: References: Message-ID: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Rewrote the test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24333/files - new: https://git.openjdk.org/jdk/pull/24333/files/3c17e148..03914585 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24333&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24333&range=01-02 Stats: 46 lines in 1 file changed: 15 ins; 24 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24333/head:pull/24333 PR: https://git.openjdk.org/jdk/pull/24333 From coleenp at openjdk.org Mon Apr 7 13:26:14 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Apr 2025 13:26:14 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v3] In-Reply-To: References: Message-ID: <4isuAr9cWMstf6sHS5LmdQAb6NAxAmKCcglI1H-Zb6U=.659906dc-07c8-4fdd-ad40-0af260ad903d@github.com> On Mon, 7 Apr 2025 06:37:29 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Rewrote the test. > > test/hotspot/jtreg/runtime/modules/PatchModule/PatchModuleJavaBaseVerify.java line 27: > >> 25: * @test >> 26: * @bug 8351654 >> 27: * @summary Make sure --patch-module for java.base verifies the classfile. > > ?? But in this scenario the injected class is not verified. Fixed. > test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 176: > >> 174: // Now load the class for the VerifyError. >> 175: System.out.println("1 hour is " + Duration.ofHours(1).getSeconds() + " seconds"); >> 176: if (!verifyErrorThrown) { > > I'm a bit confused about the logic here - are there three possibilities: > 1. the load threw VerifyError and will be caught below > 2. Another part of the code (where?) threw VerifyError, caught it and set `verifyErrorThrown` to true > 3. No verification error occurred at all. > > How do we trigger case 1 versus case 2? VerifyError for case 2 is thrown during preinit when we redefine the class, so it's caught and set to a boolean to run the original class, since the redefinition exception was caught. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2031235153 PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2031187366 From coleenp at openjdk.org Mon Apr 7 13:26:14 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Apr 2025 13:26:14 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v3] In-Reply-To: <4isuAr9cWMstf6sHS5LmdQAb6NAxAmKCcglI1H-Zb6U=.659906dc-07c8-4fdd-ad40-0af260ad903d@github.com> References: <4isuAr9cWMstf6sHS5LmdQAb6NAxAmKCcglI1H-Zb6U=.659906dc-07c8-4fdd-ad40-0af260ad903d@github.com> Message-ID: On Mon, 7 Apr 2025 12:57:48 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 176: >> >>> 174: // Now load the class for the VerifyError. >>> 175: System.out.println("1 hour is " + Duration.ofHours(1).getSeconds() + " seconds"); >>> 176: if (!verifyErrorThrown) { >> >> I'm a bit confused about the logic here - are there three possibilities: >> 1. the load threw VerifyError and will be caught below >> 2. Another part of the code (where?) threw VerifyError, caught it and set `verifyErrorThrown` to true >> 3. No verification error occurred at all. >> >> How do we trigger case 1 versus case 2? > > VerifyError for case 2 is thrown during preinit when we redefine the class, so it's caught and set to a boolean to run the original class, since the redefinition exception was caught. Yes, this was a bit confusing. The submitted test did the retransform in the preinit. I moved it to the main code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24333#discussion_r2031233088 From jsjolen at openjdk.org Mon Apr 7 13:57:55 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 7 Apr 2025 13:57:55 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers I'd prefer it if we can expand the name to `NativeMemoryLimit` and not use abbreviations so much. Some names (`_glob`, `_cat`) are pre-existing, but they should also be expanded to `_global` and `_categories`. I'm still working on reviewing this. It's hard to review through Github. As GH can't recognise that the file has been moved, I can't see what's old and what's new code. src/hotspot/share/nmt/nMemLimit.hpp line 45: > 43: }; > 44: > 45: struct nMemlimit { Style: Same NamingStyle as for classes, please. src/hotspot/share/nmt/nMemLimit.hpp line 51: > 49: > 50: // forward declaration > 51: class outputStream; Style: Remove the `// forward declaration` comment, and move it up right after the includes. ------------- PR Review: https://git.openjdk.org/jdk/pull/24343#pullrequestreview-2746892523 PR Review Comment: https://git.openjdk.org/jdk/pull/24343#discussion_r2031290534 PR Review Comment: https://git.openjdk.org/jdk/pull/24343#discussion_r2031282923 From kevinw at openjdk.org Mon Apr 7 15:01:34 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 7 Apr 2025 15:01:34 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:32:52 GMT, Zhengyu Gu wrote: > @kevinjwalls I have [JDK-8349083](https://bugs.openjdk.org/browse/JDK-8349083) to address similar issues. > > AFAICT, there are 3 separate code to handle filename expansion and logging has the most complete support, It will be nice to unify them. Hi, thanks for the pointer. Yes, we have some duplication in this area... This change is quite small, and removes one duplicate, the manual "base+pid+extension" creation of the filename in HeapDumper. I am looking at the other PR, maybe we can make them share more in future... ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2783639159 From gziemski at openjdk.org Mon Apr 7 16:01:50 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 7 Apr 2025 16:01:50 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:37:30 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes. New check_tree impl and visualization. I really like the way we now visualize the cases. One thing I'd prefer is to actually have the "pre" and "post" cases spelled out explicitly, which I did (and aligned the visual snapshots where needed) NIce! test/hotspot/gtest/nmt/test_vmatree.cpp line 862: > 860: tree.commit_mapping(25, 25, call_stack_2, true); // commit at the middle of the region > 861: // Pre: post of previous > 862: // Post: .........0---------25*********50--------100......... // Pre: .........0------------------------------100......... // Post: .........0---------25*********50--------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 876: > 874: tree.commit_mapping(0, 20, call_stack_2, true); // commit at the begin of the region > 875: // Pre: post of previous > 876: // Post: .........0********20---------25********50--------100......... // Pre: .........0---------------25*********50--------100......... // Post: .........0********20-----25*********50--------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 890: > 888: tree.commit_mapping(80, 20, call_stack_2, true); // commit at the end of the region > 889: // Pre: post of previous > 890: // Post: .........0********20---------25********50--------80********100......... // Pre: .........0********20-----25*********50------------------100......... // Post: .........0********20-----25*********50--------80********100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 920: > 918: tree.commit_mapping(20, 20, call_stack_2, true); > 919: // Pre: post of previous > 920: // Post: .........0---------20********40-------100......... // Pre: .........0----------------------------100......... // Post: .........0---------20********40-------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 937: > 935: tree.commit_mapping(10, 20, call_stack_3); > 936: // Pre: post of previous > 937: // Post: .........0---------10********30********40-------100......... // Pre: .........0---------20**************40-------100......... // Post: .........0---10*********30*********40-------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 954: > 952: tree.commit_mapping(30, 20, call_stack_4); > 953: // Pre: post of previous > 954: // Post: .........0---------10********30********50-------100......... // Pre: .........0---------10********30*********40------------------100......... // Post: .........0---------10********30********************50-------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 975: > 973: > 974: tree.uncommit_mapping(0, 5, call_stack_2); > 975: // Pre: .........0********10--------20********40-------100......... // Pre: .........0***********10--------20********40-------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 980: > 978: // - si_1 si_1 si_1 si_1 - > 979: // - si_2 - si_2 - - > 980: // Post: .........0--------5********10--------20********40-------100......... // Post: .........0-----5*****10--------20********40-------100......... test/hotspot/gtest/nmt/test_vmatree.cpp line 994: > 992: tree.uncommit_mapping(20, 10, call_stack_2); > 993: // Pre: post of previous > 994: // Post: .........0--------5********10--------30********40-------100......... // Pre: .........0-----5*****10--------20****************40-------100......... // Post: .........0-----5*****10----------------30********40-------100......... ------------- Changes requested by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2747343623 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031552088 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031552929 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031553434 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031554000 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031554533 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031554915 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031555378 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031556001 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031556524 From iklam at openjdk.org Mon Apr 7 16:18:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 7 Apr 2025 16:18:59 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> References: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> Message-ID: On Mon, 7 Apr 2025 07:46:52 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Don't use URLClassPath src/hotspot/share/cds/classListParser.cpp line 534: > 532: GrowableArray specified_interfaces = get_specified_interfaces(); > 533: > 534: const char* source_path = ClassLoader::uri_to_path(_source); Is `ClassLoader::uri_to_path` necessary? I think `_source` is already a file path. src/hotspot/share/cds/unregisteredClasses.cpp line 87: > 85: CHECK_NULL); > 86: assert(result.get_type() == T_OBJECT, "just checking"); > 87: obj = result.get_oop(); There's no need to put the above code in its own scope. Maybe do the following instead? return InstanceKlass::cast(java_lang_Class::as_Klass(result.get_oop())); src/java.base/share/classes/jdk/internal/misc/CDS.java line 444: > 442: protected Class findClass(String name) throws ClassNotFoundException { > 443: // Unregistered classes should be found in load(...), registered classes should be > 444: // handeled by parent loaders Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`. "java/lang/Object id: 0", "CustomLoadee id: 1 super: 0 source: .", ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031561175 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031573550 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031586035 From eosterlund at openjdk.org Mon Apr 7 16:59:49 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Apr 2025 16:59:49 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers What problem does this feature solve? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2784005934 From heidinga at openjdk.org Mon Apr 7 17:01:56 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 7 Apr 2025 17:01:56 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: References: Message-ID: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com> On Thu, 3 Apr 2025 20:31:50 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. >> >> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: >> >> >> const char* CDSConfig::input_static_archive_path(); >> const char* CDSConfig::input_dynamic_archive_path(); >> const char* CDSConfig::output_archive_path(); >> >> >> This PR also cleans up the code by: >> - renaming a few function to reflect what they actually do >> - moving more "config" management code into cdsConfig.cpp >> >> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. >> >> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @lmesnik comments src/hotspot/share/cds/cdsConfig.cpp line 598: > 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive > 597: > 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info." Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2031644463 From ccheung at openjdk.org Mon Apr 7 17:48:50 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 7 Apr 2025 17:48:50 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: <2c_oWLyRbQqqXTM7RzuIEhxBSPDBhpYBakPwz9IJDd0=.e077f01e-226b-4323-8501-46788bfdf1a2@github.com> On Mon, 7 Apr 2025 04:48:04 GMT, David Holmes wrote: > Can you update the PR description to clarify what is now being done please Calvin. Updated PR description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2784115313 From gziemski at openjdk.org Mon Apr 7 17:49:50 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 7 Apr 2025 17:49:50 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:37:30 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes. New check_tree impl and visualization. I like the way we visualize the case, though I'd prefer to spell out both the "pre" and "post" every time (and have them aligned). ------------- Changes requested by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2747612787 From ccheung at openjdk.org Mon Apr 7 17:56:31 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 7 Apr 2025 17:56:31 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: > The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. > > Passed tiers 1 - 3 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/2de1d3a6..e107e569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=03-04 Stats: 19 lines in 4 files changed: 4 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From ccheung at openjdk.org Mon Apr 7 17:56:31 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 7 Apr 2025 17:56:31 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v4] In-Reply-To: References: Message-ID: <11WDK5XYDlLXO1_1R-Laq44DKjFGHsHI3xq3iNUOCaU=.0bb8d14d-afbe-4946-bcac-6ea46ff5e1c8@github.com> On Mon, 7 Apr 2025 05:06:56 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix issues related to JAVA_HOME and gtest > > src/hotspot/os/aix/os_aix.cpp line 1309: > >> 1307: assert(rp != nullptr, "error in realpath(): maybe the 'path' argument is too long?"); >> 1308: >> 1309: if(Arguments::executing_unit_tests()) { > > Suggestion: > > if (Arguments::executing_unit_tests()) { Fixed. > src/hotspot/os/linux/os_linux.cpp line 2775: > >> 2773: } >> 2774: >> 2775: if (Arguments::executing_unit_tests()) { > > Suggestion: > > // If executing unit tests we require JAVA_HOME to point to the real JDK. > if (Arguments::executing_unit_tests()) { Fixed. > src/hotspot/os/linux/os_linux.cpp line 2802: > >> 2800: // Use current module name "libjvm.so" >> 2801: len = (int)strlen(buf); >> 2802: snprintf(buf + len, buflen-len, "/%s/libjvm%s", > > Suggestion: > > snprintf(buf + len, buflen - len, "/%s/libjvm%s", Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2031726619 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2031726138 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2031726434 From ccheung at openjdk.org Mon Apr 7 17:56:32 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 7 Apr 2025 17:56:32 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v3] In-Reply-To: References: Message-ID: <5ZRNs4nCS10sGtLADi0luTJThjefGTPuFQ9JFQfPr2E=.20d3db4d-54c1-40fc-b367-434221f19362@github.com> On Fri, 4 Apr 2025 06:15:29 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora comment > > src/hotspot/os/aix/os_aix.cpp line 1326: > >> 1324: } >> 1325: >> 1326: // modules image doesn't have "jre" subdirectory > > Delete comment please Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2031726017 From ccheung at openjdk.org Mon Apr 7 17:56:32 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 7 Apr 2025 17:56:32 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 06:06:35 GMT, David Holmes wrote: >> src/hotspot/os/linux/os_linux.cpp line 2808: >> >>> 2806: } >>> 2807: >>> 2808: // determine if this is a legacy image or modules image >> >> Delete the comment on the next line about the jre subdirectory please. > > This applies in all versions of the file of course, where it exists. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2031726308 From gziemski at openjdk.org Mon Apr 7 17:58:01 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 7 Apr 2025 17:58:01 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:37:30 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes. New check_tree impl and visualization. Changes requested by gziemski (Reviewer). test/hotspot/gtest/nmt/test_vmatree.cpp line 790: > 788: } > 789: > 790: sprintf(for_this_node, "test at line: %d, for node: %d", line_no, et.nodes[i]); I see `warning: 'sprintf' is deprecated:...use snprintf(3) instead` on macOS when I try to run the gtest locally. ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2747629382 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031728184 From gziemski at openjdk.org Mon Apr 7 20:32:12 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 7 Apr 2025 20:32:12 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: <8CKKaaiKtgpyYxLpkZ_lAqPjJdKatkUQgHOX5dWivWM=.bd2c21c9-c2d0-437f-83ca-c7b207b3c3dd@github.com> On Mon, 7 Apr 2025 12:37:30 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes. New check_tree impl and visualization. test/hotspot/gtest/nmt/test_vmatree.cpp line 1005: > 1003: {-1 , -1 , si_2 , -1 , si_2 , -1 , -1 }}; > 1004: check_tree(tree, et2, __LINE__); > 1005: } If I add this operation here, instead of an expected NOP, I get `SIGSEGV`: tree.uncommit_mapping(20, 30, call_stack_2); // Pre: .........0-----5*****10----------------30********40-------100......... // Post: .........0-----5*****10-----------------------------------100......... // mtNone mtTest mtTest mtTest mtTest mtTest mtNone // Rl Rs C Rs C Rs Rl // - si_1 si_1 si_1 si_1 si_1 - // - - si_2 - si_2 - - ExpectedTree<6> et3 = {{ 0, 5, 10, 100 }, {mtNone, mtTest, mtTest, mtTest, mtNone}, {Rl , Rs , C , Rs , Rl }, {-1 , si_1 , si_1 , si_1 , -1 }, {-1 , -1 , si_2 , -1 , -1 }}; check_tree(tree, et3, __LINE__); signaled: SIGSEGV # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000010548f42c, pid=7015, tid=259 # # JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-adhoc.gerard.jdk) # Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.gerard.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # V [libjvm.dylib+0x2ab42c] void check_tree<6>(VMATree&, ExpectedTree<6> const&, int)+0x558 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2031963006 From duke at openjdk.org Mon Apr 7 21:20:15 2025 From: duke at openjdk.org (Rui Li) Date: Mon, 7 Apr 2025 21:20:15 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: <6TjX4j3a3VjV7IoU_NgWgcf2l3Cyotumy6GnKYvXvKA=.2737ffd9-41a8-4a06-8360-ddd9fd52fad8@github.com> On Mon, 7 Apr 2025 16:56:57 GMT, Erik ?sterlund wrote: > What problem does this feature solve? To provide mmap limitation in native memory. Was working on a separate JBS: https://bugs.openjdk.org/browse/JDK-8350860. Found that only malloc has this memory limitation function and it'd be useful to have the counterpart for mmap since gc also gets its memory from mmap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2784649567 From cjplummer at openjdk.org Tue Apr 8 01:41:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 8 Apr 2025 01:41:39 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls wrote: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). src/hotspot/share/services/heapDumper.cpp line 2772: > 2770: > 2771: // Set base path (name or directory, default or custom, without seq no), doing %p substitution. > 2772: const char *path_src = (HeapDumpPath && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name; Should be `HeapDumpPath != nullptr`. src/hotspot/share/services/heapDumper.cpp line 2792: > 2790: // Path is a directory. Append the default name, with %p substitution. Use my_path temporarily. > 2791: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN)) { > 2792: warning("Cannot create heap dump file. HeapDumpPath is too long."); What is going to be the end result of this? A truncated file name? test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 101: > 99: File dump = new File(heapdumpFilename); > 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath()); > 101: I think you can remove this empty line, especially since you don't have one in the similar code below. test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 113: > 111: TestHeapDumpOnOutOfMemoryError.class.getName(), type); > 112: > 113: Process proc = pb.start(); No need differ from the above code here. You can just use OutputAnalyzer.pid() to get the pid in the code below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032238479 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032243030 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032233983 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032234654 From sspitsyn at openjdk.org Tue Apr 8 03:20:17 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 8 Apr 2025 03:20:17 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v8] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge - review: add workaround for post_dynamic_code_generated_while_holding_locks - Merge - Merge - review: move suspend point from post_single_step() to get_jvmti_thread_state() - 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/39e8d748..cdb47686 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=06-07 Stats: 37504 lines in 960 files changed: 23787 ins; 10997 del; 2720 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 stuefe at openjdk.org Tue Apr 8 05:23:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 05:23:20 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: <32aeQpqUwH1StPhCmkwzaXWkBd6WJF4jCe_C1vRr1B0=.66a5807f-597a-41ee-9c82-ac19d184a928@github.com> On Mon, 7 Apr 2025 12:15:59 GMT, Coleen Phillimore wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> move line > > test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 62: > >> 60: {"AllowRedefinitionToAddDeleteMethods", "true"}, >> 61: {"LockingMode", "1"}, >> 62: {"UseCompressedClassPointers", "false"}, > > If you run this test on an arm32, will it fail because UseCompressedClassPointers is unrecognized there? Does this need to be conditional on 64 bit platforms? You are right, I fixed the test. I had tested the JVM on arm32 manually, but did not run this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2032397834 From stuefe at openjdk.org Tue Apr 8 05:23:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 05:23:20 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: References: Message-ID: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe 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: - Test fix for 32-bit - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers - move line - move line - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers - not on 32-bit - Deprecate UseCompressedClassPointers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/5afdff50..1ee16bfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=03-04 Stats: 3538 lines in 111 files changed: 2640 ins; 543 del; 355 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From eosterlund at openjdk.org Tue Apr 8 05:41:22 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 8 Apr 2025 05:41:22 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: <6TjX4j3a3VjV7IoU_NgWgcf2l3Cyotumy6GnKYvXvKA=.2737ffd9-41a8-4a06-8360-ddd9fd52fad8@github.com> References: <6TjX4j3a3VjV7IoU_NgWgcf2l3Cyotumy6GnKYvXvKA=.2737ffd9-41a8-4a06-8360-ddd9fd52fad8@github.com> Message-ID: On Mon, 7 Apr 2025 21:17:51 GMT, Rui Li wrote: > > What problem does this feature solve? > > > > To provide mmap limitation in native memory. Was working on a separate JBS: https://bugs.openjdk.org/browse/JDK-8350860. Found that only malloc has this memory limitation function and it'd be useful to have the counterpart for mmap since gc also gets its memory from mmap. I understand that the feature limits how much memory the JVM is allowed to map. What I'm asking is what the intended use case is for limiting the amount of mapped memory. The JBS entry you linked seems to talk about writing tests that check that the JVM didn't use more native memory than X. If the intended use case is to be able to write tests that check no more than X native memory is used, then adding a native memory limit that makes the JVM bail if exceeded (as you have done), is one possible way of getting there. An alternative would seemingly be to run the test with NMT, and instead measure how much native memory was used, and assert in the test (as opposed to in the JVM) that the measured value is not larger than X. This makes me wonder if we want to introduce such a limit, if it is not needed in order to write the intended tests. Or perhaps there is further motivation that you did not mention? The reason I'm apprehensive is that I don't know if I want to be dealing with new surprising error modes where memory artificially can't be mapped even though memory is available, if it isn't super important. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2785278210 From stuefe at openjdk.org Tue Apr 8 06:12:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 06:12:16 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 17:56:31 GMT, Calvin Cheung wrote: >> The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? ------------- PR Review: https://git.openjdk.org/jdk/pull/24310#pullrequestreview-2748768608 From stuefe at openjdk.org Tue Apr 8 07:33:17 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 07:33:17 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers I appreciate the effort, but don't think this is a good approach we should take. Pity you did not ping us before. There are several reasons why this is less helpful than you may be thinking, and more complex as well. And there is an alternative approach that is in the work (see bottom). Difficulty: Tracking mmap space is more difficult than tracking mmap memory. Simply counting size on commit/uncommit won't do, since memory regions can overlap, and they do sometimes (e.g. Metaspace). You can uncommit/commit partially uncommitted/ committed ranges. With NMT we have an alternative version of the MemTracker planned that will use a binary tree - similar to an interval tree - that can give more precision here; but I am not convinced this is a good way to limit RSS. Accuracy: Assuming that the purpose of this mmap limit is to limit RSS usage by the JVM, tracking committed space to limit RSS is not really useful outside of simple examples. NMT tracks committed memory, not live memory. That is a really big blenish of NMT mmap tracking. See https://bugs.openjdk.org/browse/JDK-8249666 (that bug keeps slipping down the prio list, but it is not terribly complex to do). NMT committed memory tracking is mostly an okayish approximation of RSS since the JVM tends to commit what it plans to use shortly. But it can be really wildly off, e.g. when specifying -Xmx=-Xms. In addition to that, NMT mmap tracking only accounts a small subset of mmaps int the JVM. It will not work for RSS increases caused by other sources (e.g. untracked mmaps from JDK/third-party libs like natty/system libs), thread stacks, third-party C-heap usage etc. ---- Alternative: 23/24 I worked on a prototype for RSS limiting that works by simply observing RSS; see https://github.com/openjdk/jdk/pull/16938. A small low-cost thread polling RSS at regular intervals, similar to how we trim the C-heap. The advantage of this is that it is independent of all shortcomings NMT has, and it reacts to the real, live memory increase, not whatever NMT is counting as committed. Unfortunately I did not have time to continue work on this. I may find the time this year, maybe before 25 deadline. Lets see. The PR was mostly done at that point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2785505673 From dholmes at openjdk.org Tue Apr 8 07:49:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Apr 2025 07:49:20 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v4] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Mon, 7 Apr 2025 08:04:07 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Do explicit thread > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix Looks good - thanks for the updates. Lets see how this works in practice. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2749010051 From dholmes at openjdk.org Tue Apr 8 07:55:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Apr 2025 07:55:22 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 06:09:28 GMT, Thomas Stuefe wrote: > Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? AIX has a different dll lookup mechanism, but otherwise these should be pretty much identical. Windows also only really differs in the lookup mechanism. Maybe new RFE to refactor these and share some code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2785557312 From azafari at openjdk.org Tue Apr 8 08:15:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Apr 2025 08:15:29 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 17:54:33 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes. New check_tree impl and visualization. > > test/hotspot/gtest/nmt/test_vmatree.cpp line 790: > >> 788: } >> 789: >> 790: sprintf(for_this_node, "test at line: %d, for node: %d", line_no, et.nodes[i]); > > I see `warning: 'sprintf' is deprecated:...use snprintf(3) instead` on macOS when I try to run the gtest locally. Good catch. Forgotten to do so. Changed to `snprintf` now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032648220 From shade at openjdk.org Tue Apr 8 08:15:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 8 Apr 2025 08:15:41 GMT Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path [v4] In-Reply-To: References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Mon, 7 Apr 2025 08:04:07 GMT, Aleksey Shipilev wrote: >> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Do explicit thread > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Merge branch 'master' into JDK-8352256-quick-notify-jfr > - Review comment > - Fix Thanks for reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2785606816 From shade at openjdk.org Tue Apr 8 08:15:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 8 Apr 2025 08:15:41 GMT Subject: Integrated: 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com> Message-ID: On Tue, 18 Mar 2025 11:42:39 GMT, Aleksey Shipilev wrote: > Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` This pull request has now been integrated. Changeset: ea07e719 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/ea07e719ca255d0da1966118c464ee23f4dc44da Stats: 21 lines in 3 files changed: 14 ins; 4 del; 3 mod 8352256: ObjectSynchronizer::quick_notify misses JFR event notification path Reviewed-by: dholmes, coleenp, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/24097 From dholmes at openjdk.org Tue Apr 8 08:16:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Apr 2025 08:16:19 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v3] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 13:26:13 GMT, Coleen Phillimore wrote: >> This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rewrote the test. Thanks for the test update that seems a lot clearer now. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24333#pullrequestreview-2749085397 From stuefe at openjdk.org Tue Apr 8 08:19:18 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 08:19:18 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 07:52:19 GMT, David Holmes wrote: > > Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? > > AIX has a different dll lookup mechanism, but otherwise these should be pretty much identical. Windows also only really differs in the lookup mechanism. Maybe new RFE to refactor these and share some code? Okay. The code could also be simpler if it were to use stringStream, spanned over the caller-provided buffer. No character counting and truncation handling needed then (but we would need to add truncation detection to stringStream, but that is really easy). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2785617995 From azafari at openjdk.org Tue Apr 8 08:28:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Apr 2025 08:28:09 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v9] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Pre conditions are also visualized. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/f66ca19b..517b1348 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=07-08 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Tue Apr 8 08:28:16 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Apr 2025 08:28:16 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 15:55:20 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes. New check_tree impl and visualization. > > test/hotspot/gtest/nmt/test_vmatree.cpp line 862: > >> 860: tree.commit_mapping(25, 25, call_stack_2, true); // commit at the middle of the region >> 861: // Pre: post of previous >> 862: // Post: .........0---------25*********50--------100......... > > // Pre: .........0------------------------------100......... > // Post: .........0---------25*********50--------100......... Done > test/hotspot/gtest/nmt/test_vmatree.cpp line 876: > >> 874: tree.commit_mapping(0, 20, call_stack_2, true); // commit at the begin of the region >> 875: // Pre: post of previous >> 876: // Post: .........0********20---------25********50--------100......... > > // Pre: .........0---------------25*********50--------100......... > // Post: .........0********20-----25*********50--------100......... Done > test/hotspot/gtest/nmt/test_vmatree.cpp line 890: > >> 888: tree.commit_mapping(80, 20, call_stack_2, true); // commit at the end of the region >> 889: // Pre: post of previous >> 890: // Post: .........0********20---------25********50--------80********100......... > > // Pre: .........0********20-----25*********50------------------100......... > // Post: .........0********20-----25*********50--------80********100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 920: > >> 918: tree.commit_mapping(20, 20, call_stack_2, true); >> 919: // Pre: post of previous >> 920: // Post: .........0---------20********40-------100......... > > // Pre: .........0----------------------------100......... > // Post: .........0---------20********40-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 937: > >> 935: tree.commit_mapping(10, 20, call_stack_3); >> 936: // Pre: post of previous >> 937: // Post: .........0---------10********30********40-------100......... > > // Pre: .........0---------20**************40-------100......... > // Post: .........0---10*********30*********40-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 954: > >> 952: tree.commit_mapping(30, 20, call_stack_4); >> 953: // Pre: post of previous >> 954: // Post: .........0---------10********30********50-------100......... > > // Pre: .........0---------10********30*********40------------------100......... > // Post: .........0---------10********30********************50-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 975: > >> 973: >> 974: tree.uncommit_mapping(0, 5, call_stack_2); >> 975: // Pre: .........0********10--------20********40-------100......... > > // Pre: .........0***********10--------20********40-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 980: > >> 978: // - si_1 si_1 si_1 si_1 - >> 979: // - si_2 - si_2 - - >> 980: // Post: .........0--------5********10--------20********40-------100......... > > // Post: .........0-----5*****10--------20********40-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 994: > >> 992: tree.uncommit_mapping(20, 10, call_stack_2); >> 993: // Pre: post of previous >> 994: // Post: .........0--------5********10--------30********40-------100......... > > // Pre: .........0-----5*****10--------20****************40-------100......... > // Post: .........0-----5*****10----------------30********40-------100......... Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 1005: > >> 1003: {-1 , -1 , si_2 , -1 , si_2 , -1 , -1 }}; >> 1004: check_tree(tree, et2, __LINE__); >> 1005: } > > If I add this operation here, I get `SIGSEGV`: > > > tree.uncommit_mapping(20, 30, call_stack_2); > // Pre: .........0-----5*****10----------------30********40-------100......... > // Post: .........0-----5*****10-----------------------------------100......... > // mtNone mtTest mtTest mtTest mtTest mtTest mtNone > // Rl Rs C Rs C Rs Rl > // - si_1 si_1 si_1 si_1 si_1 - > // - - si_2 - si_2 - - > ExpectedTree<6> et3 = {{ 0, 5, 10, 100 }, > {mtNone, mtTest, mtTest, mtTest, mtNone}, > {Rl , Rs , C , Rs , Rl }, > {-1 , si_1 , si_1 , si_1 , -1 }, > {-1 , -1 , si_2 , -1 , -1 }}; > check_tree(tree, et3, __LINE__); > > > > > signaled: SIGSEGV > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x000000010548f42c, pid=7015, tid=259 > # > # JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-adhoc.gerard.jdk) > # Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.gerard.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # V [libjvm.dylib+0x2ab42c] void check_tree<6>(VMATree&, ExpectedTree<6> const&, int)+0x558 The template parameter `N` to `ExpectedTree` is the number of nodes. In this code, `6` is passed as `N` but `4` nodes (`0, 5, 10, 100`) are provided. The `ExpectedTree<4> et3 = ...` should fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032660708 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032661050 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032661256 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032661728 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032661978 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032662309 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032662770 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032662999 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032663255 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2032667619 From kevinw at openjdk.org Tue Apr 8 09:02:13 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Apr 2025 09:02:13 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 01:37:21 GMT, Chris Plummer wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > src/hotspot/share/services/heapDumper.cpp line 2792: > >> 2790: // Path is a directory. Append the default name, with %p substitution. Use my_path temporarily. >> 2791: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN)) { >> 2792: warning("Cannot create heap dump file. HeapDumpPath is too long."); > > What is going to be the end result of this? A truncated file name? Yes the other warnings return - thanks. They all return without incrementing dump_seq, so will hit the same failure each time. Setting a HeapDumpPath near to 4k in length is not an efficient thing to do! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032733570 From rehn at openjdk.org Tue Apr 8 09:49:16 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 8 Apr 2025 09:49:16 GMT Subject: RFR: 8353829: RISC-V: Auto-enable several more extensions for debug builds In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 07:45:33 GMT, Fei Yang wrote: > Hi, > Please consider this followup change after https://bugs.openjdk.org/browse/JDK-8353344. > This adds detection and enablement of two more extensions: Ztso and Zacas. > Testing: hs:tier1-hs:tier3 tested with qemu-system equipmented with these extensions. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24478#pullrequestreview-2749360731 From fjiang at openjdk.org Tue Apr 8 10:00:26 2025 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 8 Apr 2025 10:00:26 GMT Subject: RFR: 8353829: RISC-V: Auto-enable several more extensions for debug builds In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 07:45:33 GMT, Fei Yang wrote: > Hi, > Please consider this followup change after https://bugs.openjdk.org/browse/JDK-8353344. > This adds detection and enablement of two more extensions: Ztso and Zacas. > Testing: hs:tier1-hs:tier3 tested with qemu-system equipmented with these extensions. Looks good! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/24478#pullrequestreview-2749390660 From tpushkin at openjdk.org Tue Apr 8 11:36:13 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 8 Apr 2025 11:36:13 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: References: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> Message-ID: On Mon, 7 Apr 2025 16:00:27 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use URLClassPath > > src/hotspot/share/cds/classListParser.cpp line 534: > >> 532: GrowableArray specified_interfaces = get_specified_interfaces(); >> 533: >> 534: const char* source_path = ClassLoader::uri_to_path(_source); > > Is `ClassLoader::uri_to_path` necessary? I think `_source` is already a file path. `_source` is a URL with `file:`removed from the beginning of it, so yes, this is necessary. For example, if a class resides in a directory called "my dir" its `_source` will be "my%20dir" ? `uri_to_path` will replace "%20" with " ". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2032994904 From kevinw at openjdk.org Tue Apr 8 11:43:20 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Apr 2025 11:43:20 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - length checking update - Chris feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24482/files - new: https://git.openjdk.org/jdk/pull/24482/files/ab82116e..c32e4ca4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=00-01 Stats: 23 lines in 2 files changed: 1 ins; 15 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482 PR: https://git.openjdk.org/jdk/pull/24482 From kevinw at openjdk.org Tue Apr 8 11:47:20 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Apr 2025 11:47:20 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - length checking update > - Chris feedback Updated. Additionally, the total_length check at line 2760 is wrong now. But it is also redundant, we use copy_expand_pid to do our length checks on expansion. Use max_digit_chars to reduce buffer length in those copy_expand_pid calls, to leave room for possible later sequence numbers (this is very conservative). On longer path lengths, worth noting that using MAXPATHLEN (4k) is higher than outputStream::print_cr allows. This means we can get through all of HeapDumper::dump_heap(bool oome) and call HeapDumper::dump() which uses: 2606 out->print_cr("Dumping heap to %s ...", path); ..and will show a VM warning like "outputStream::do_vsnprintf output truncated" Again, very very long HeapDumpPaths are not efficient. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786165819 From tpushkin at openjdk.org Tue Apr 8 11:49:12 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 8 Apr 2025 11:49:12 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: References: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> Message-ID: On Mon, 7 Apr 2025 16:15:47 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use URLClassPath > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 444: > >> 442: protected Class findClass(String name) throws ClassNotFoundException { >> 443: // Unregistered classes should be found in load(...), registered classes should be >> 444: // handeled by parent loaders > > Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`. > > > "java/lang/Object id: 0", > "CustomLoadee id: 1 super: 0 source: .", `UnregisteredClassLoader::loadClass` will be called, i.e. the default implementation from `ClassLoader::loadClass`, which will first try to delegate to parent. The delegation chain will reach the boot loader which will find `java.lang.Object` and thus `UnregisteredClassLoader::findClass()` won't be called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033015572 From stuefe at openjdk.org Tue Apr 8 11:54:21 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 11:54:21 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:44:52 GMT, Kevin Walls wrote: > Updated. Additionally, the total_length check at line 2760 is wrong now. But it is also redundant, we use copy_expand_pid to do our length checks on expansion. Use max_digit_chars to reduce buffer length in those copy_expand_pid calls, to leave room for possible later sequence numbers (this is very conservative). > > On longer path lengths, worth noting that using MAXPATHLEN (4k) is higher than outputStream::print_cr allows. This means we can get through all of HeapDumper::dump_heap(bool oome) and call HeapDumper::dump() which uses: 2606 out->print_cr("Dumping heap to %s ...", path); ..and will show a VM warning like "outputStream::do_vsnprintf output truncated" > > Again, very very long HeapDumpPaths are not efficient. 8-) I keep thinking that such a coding can benefit from using stringStream; it makes most of the associated buffer counting etc obsolete, supports dynamic buffers, or optionally can be laid over a fixed-sized buffer and then handles truncation. It does not yet provide a way to report truncation, but that can be added really easily. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786180952 From tpushkin at openjdk.org Tue Apr 8 12:09:59 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 8 Apr 2025 12:09:59 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: Message-ID: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary scoping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/16a2f951..dff524c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=03-04 Stats: 19 lines in 1 file changed: 0 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From kevinw at openjdk.org Tue Apr 8 12:12:11 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Apr 2025 12:12:11 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:51:18 GMT, Thomas Stuefe wrote: > I keep thinking that such a coding can benefit from using stringStream; it makes most of the associated buffer counting etc obsolete, supports dynamic buffers, or optionally can be laid over a fixed-sized buffer and then handles truncation. It does not yet provide a way to report truncation, but that can be added really easily. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786226321 From jsjolen at openjdk.org Tue Apr 8 12:41:13 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 8 Apr 2025 12:41:13 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v3] In-Reply-To: References: Message-ID: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Do not use BufferUpdater ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24411/files - new: https://git.openjdk.org/jdk/pull/24411/files/57c3877a..e4dc5eb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24411&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24411&range=01-02 Stats: 17 lines in 2 files changed: 0 ins; 12 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24411/head:pull/24411 PR: https://git.openjdk.org/jdk/pull/24411 From jsjolen at openjdk.org Tue Apr 8 12:41:16 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 8 Apr 2025 12:41:16 GMT Subject: RFR: 8353718: Improve droppingMessage test in async UL tests [v2] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 13:52:28 GMT, Johan Sj?len wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> With these changes integrated, I hope to be able to find the actual culprit of this bug. >> >> I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Do not use BufferUpdater I'm closing this as I managed to reproduce the issue and now have a full bug fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24411#issuecomment-2786299117 From jsjolen at openjdk.org Tue Apr 8 12:41:18 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 8 Apr 2025 12:41:18 GMT Subject: Withdrawn: 8353718: Improve droppingMessage test in async UL tests In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 10:35:29 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only. It's currently unclear why this occurs. To figure out why, I've extended the test to do emit more diagnostic information if it fails. > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > With these changes integrated, I hope to be able to find the actual culprit of this bug. > > I have attempted to reproduce this bug on both mainline and with this patch, but I have been unable to do so. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24411 From stuefe at openjdk.org Tue Apr 8 13:16:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 13:16:20 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - length checking update > - Chris feedback src/hotspot/share/services/heapDumper.cpp line 2779: > 2777: } > 2778: // Then add the default name, with %p substitution. Use my_path temporarily. > 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) { IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow. This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this: print_expand_pid(outputStream* sink, const char* input); and in there print to sink, with print or putc. This would never truncate. Then use it like this: outputStream st(caller buffer, caller buffer size) if (have HeapDumpPath) { Arguments::print_expand_pid(st, HeapDumpPath); if (st->was_truncated()) return with warning // now st->base() ist der expanded heap path. Test if its a directory etc } // append file name Arguments::print_expand_pid(st, dump_file_name); if (st->was_truncated()) return with warning Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033167264 From coleenp at openjdk.org Tue Apr 8 13:16:24 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Apr 2025 13:16:24 GMT Subject: Integrated: 8351654: Agent transformer bytecodes should be verified In-Reply-To: References: Message-ID: <_pdW8oRZkYApYdgN4rk2oMp3Jc2JhR5_SMZF0_WO1kk=.a325a722-0c17-49e1-821a-fe36688637c3@github.com> On Mon, 31 Mar 2025 16:31:47 GMT, Coleen Phillimore wrote: > This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. > Tested with tier1-4. This pull request has now been integrated. Changeset: 250437e5 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/250437e557c56ba66a74ab759cfd1071a510e184 Stats: 300 lines in 7 files changed: 291 ins; 0 del; 9 mod 8351654: Agent transformer bytecodes should be verified Reviewed-by: dholmes, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24333 From coleenp at openjdk.org Tue Apr 8 13:16:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Apr 2025 13:16:23 GMT Subject: RFR: 8351654: Agent transformer bytecodes should be verified [v3] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 13:26:13 GMT, Coleen Phillimore wrote: >> This change enables verification for classes provided with the JVMTI ClassFileLoadHook. The test was adapted from the one sent by the submitter @rjernst. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rewrote the test. Thanks for the review and discussions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24333#issuecomment-2786392634 From kevinw at openjdk.org Tue Apr 8 13:50:19 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Apr 2025 13:50:19 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 13:13:25 GMT, Thomas Stuefe wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - length checking update >> - Chris feedback > > src/hotspot/share/services/heapDumper.cpp line 2779: > >> 2777: } >> 2778: // Then add the default name, with %p substitution. Use my_path temporarily. >> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) { > > IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow. > > This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this: > > print_expand_pid(outputStream* sink, const char* input); > > > and in there print to sink, with print or putc. This would never truncate. Then use it like this: > > > outputStream st(caller buffer, caller buffer size) > if (have HeapDumpPath) { > Arguments::print_expand_pid(st, HeapDumpPath); > if (st->was_truncated()) return with warning > // now st->base() ist der expanded heap path. Test if its a directory etc > } > // append file name > Arguments::print_expand_pid(st, dump_file_name); > if (st->was_truncated()) return with warning > > > Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now. Thankfully copy_expand_pid does handle multiple %p replacements. It seems good to use that to check the buffer length, partly for that reason, as just knowing a max number of digits wasn't so flexible if many %p were present. Thanks for the other ideas! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033234374 From stuefe at openjdk.org Tue Apr 8 15:28:25 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 15:28:25 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 13:47:10 GMT, Kevin Walls wrote: >> src/hotspot/share/services/heapDumper.cpp line 2779: >> >>> 2777: } >>> 2778: // Then add the default name, with %p substitution. Use my_path temporarily. >>> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) { >> >> IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow. >> >> This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this: >> >> print_expand_pid(outputStream* sink, const char* input); >> >> >> and in there print to sink, with print or putc. This would never truncate. Then use it like this: >> >> >> outputStream st(caller buffer, caller buffer size) >> if (have HeapDumpPath) { >> Arguments::print_expand_pid(st, HeapDumpPath); >> if (st->was_truncated()) return with warning >> // now st->base() ist der expanded heap path. Test if its a directory etc >> } >> // append file name >> Arguments::print_expand_pid(st, dump_file_name); >> if (st->was_truncated()) return with warning >> >> >> Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now. > > Thankfully copy_expand_pid does handle multiple %p replacements. It seems good to use that to check the buffer length, partly for that reason, as just knowing a max number of digits wasn't so flexible if many %p were present. > > Thanks for the other ideas! Ah okay, it checks for overflow. Okay, please disregard half of what I have written :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033452540 From kvn at openjdk.org Tue Apr 8 16:00:21 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 8 Apr 2025 16:00:21 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com> References: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com> Message-ID: On Mon, 7 Apr 2025 16:54:37 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @lmesnik comments > > src/hotspot/share/cds/cdsConfig.cpp line 598: > >> 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive >> 597: >> 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info." > > Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`. I am using `-Xlog:aot+codecache` in AOT code caching. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033524434 From iklam at openjdk.org Tue Apr 8 16:29:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 8 Apr 2025 16:29:21 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: References: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com> Message-ID: On Tue, 8 Apr 2025 15:57:46 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/cds/cdsConfig.cpp line 598: >> >>> 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive >>> 597: >>> 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info." >> >> Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction > > Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`. > I am using `-Xlog:aot+codecache` in AOT code caching. I created [JDK-8354055 - Change "cds" logging tag to "aot"](https://bugs.openjdk.org/browse/JDK-8354055). There are documentation/compatibility issues so we need to do some planning. This particular block of code is moved from dynamicArchive.cpp to cdsConfig.cpp and I kept the logging tag the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033582112 From heidinga at openjdk.org Tue Apr 8 16:56:17 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 8 Apr 2025 16:56:17 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: References: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com> Message-ID: On Tue, 8 Apr 2025 16:26:28 GMT, Ioi Lam wrote: >> Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`. >> I am using `-Xlog:aot+codecache` in AOT code caching. > > I created [JDK-8354055 - Change "cds" logging tag to "aot"](https://bugs.openjdk.org/browse/JDK-8354055). There are documentation/compatibility issues so we need to do some planning. > > This particular block of code is moved from dynamicArchive.cpp to cdsConfig.cpp and I kept the logging tag the same. Thanks @iklam. I agree with the approach of doing this in a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033640450 From kvn at openjdk.org Tue Apr 8 17:28:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 8 Apr 2025 17:28:26 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3] In-Reply-To: References: Message-ID: <2ZMtE0qPWzJ1jSC31oFURQ2b7w3l7d8CJsXgmWauyiY=.e4a74cdf-d76a-4862-8966-eb26a0b57dac@github.com> On Thu, 3 Apr 2025 20:31:50 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. >> >> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: >> >> >> const char* CDSConfig::input_static_archive_path(); >> const char* CDSConfig::input_dynamic_archive_path(); >> const char* CDSConfig::output_archive_path(); >> >> >> This PR also cleans up the code by: >> - renaming a few function to reflect what they actually do >> - moving more "config" management code into cdsConfig.cpp >> >> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. >> >> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @lmesnik comments Looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2750854771 From coleenp at openjdk.org Tue Apr 8 17:36:25 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Apr 2025 17:36:25 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> References: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> Message-ID: On Tue, 8 Apr 2025 05:23:20 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe 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: > > - Test fix for 32-bit > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - move line > - move line > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - not on 32-bit > - Deprecate UseCompressedClassPointers Looks good modulo the whitespace errors. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24436#pullrequestreview-2750873268 From iklam at openjdk.org Tue Apr 8 17:40:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 8 Apr 2025 17:40:17 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Tue, 8 Apr 2025 12:09:59 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary scoping Changes requested by iklam (Reviewer). src/java.base/share/classes/jdk/internal/misc/CDS.java line 438: > 436: // class loader. Thus it is safe to delegate their loading to system class loader > 437: // (our parent) - this is what the default implementation of loadClass() will do. > 438: return defineClass(name, bytes, 0, bytes.length); I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify? // defineClass() will internally invoke loadClass() to load supertypes of this unregistered class. // Any supertype S with the name SN must have already been loaded (enforced by the order // of classes in the classlist). In addition: // - if S is an unregistered class, S must have already been have been defined by the current class // loader, and will be found by `this.findLoadedClass(SN)` // - if S is not an unregistered class, S must have already been defined by the built-in boot, // platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false) // See the implementation of ClassLoader::loadClass() for details. // // Therefore, we should resolve all supertypes to the expected ones as specified by the // super: and interfaces: attributes in the classlist. This // invariance is validated by the C++ function ClassListParser::load_class_from_source() assert getParent() == getSystemClassLoader(); return defineClass(name, bytes, 0, bytes.length); ------------- PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2750817568 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033724629 From iklam at openjdk.org Tue Apr 8 17:40:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 8 Apr 2025 17:40:18 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4] In-Reply-To: References: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com> Message-ID: <59RkPepnIk-FSEkX13j1-H60yc6q_B-JEmV-Fa6BKUQ=.01d7e227-3873-4805-8c41-fa1aab1a3713@github.com> On Tue, 8 Apr 2025 11:46:27 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 444: >> >>> 442: protected Class findClass(String name) throws ClassNotFoundException { >>> 443: // Unregistered classes should be found in load(...), registered classes should be >>> 444: // handeled by parent loaders >> >> Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`. >> >> >> "java/lang/Object id: 0", >> "CustomLoadee id: 1 super: 0 source: .", > > `UnregisteredClassLoader::loadClass` will be called, i.e. the default implementation from `ClassLoader::loadClass`, which will first try to delegate to parent. The delegation chain will reach the boot loader which will find `java.lang.Object` and thus `UnregisteredClassLoader::findClass()` won't be called. I think the findClass() method can be deleted as it's identical to the one in URLClassLoader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033685869 From rkennke at openjdk.org Tue Apr 8 18:47:22 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 18:47:22 GMT Subject: RFR: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 01:32:48 GMT, Zhengyu Gu wrote: > It is a simple atomic counter for tracking hash table's load factor, only needs atomic guarantee. Makes sense! Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24432#pullrequestreview-2751087594 From gziemski at openjdk.org Tue Apr 8 19:22:23 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 8 Apr 2025 19:22:23 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v9] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 08:28:09 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Pre conditions are also visualized. Changes requested by gziemski (Reviewer). test/hotspot/gtest/nmt/test_vmatree.cpp line 975: > 973: > 974: tree.uncommit_mapping(0, 5, call_stack_2); > 975: // Pre: .........0********10--------20********40-------100......... I think this one got lost, still could use reformatting: `// Pre: .........0*****************10--------20********40-------100.........` ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2751160750 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2033883257 From rkennke at openjdk.org Tue Apr 8 19:37:29 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 19:37:29 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option Message-ID: As title says. ------------- Commit messages: - 8350457: Support Compact Object Headers as product option Changes: https://git.openjdk.org/jdk/pull/24522/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350457 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24522/head:pull/24522 PR: https://git.openjdk.org/jdk/pull/24522 From iklam at openjdk.org Tue Apr 8 21:11:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 8 Apr 2025 21:11:42 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v5] In-Reply-To: References: Message-ID: > When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. > > In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Thread safety: AOTClassFilter::is_aot_tooling_class() can potentially be called by multiple threads concurrently - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Added single-thread-only assert for AOTClassFilter - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Refactored CollectClassesForLinking for simplification - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Reverted some fixes in systemDictionaryShared.cpp that causes test failures - 8353014: Exclude AOT tooling classes from AOT cache ------------- Changes: https://git.openjdk.org/jdk/pull/24272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=04 Stats: 328 lines in 14 files changed: 244 ins; 49 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/24272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24272/head:pull/24272 PR: https://git.openjdk.org/jdk/pull/24272 From vlivanov at openjdk.org Tue Apr 8 21:22:22 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 8 Apr 2025 21:22:22 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v5] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 21:11:42 GMT, Ioi Lam wrote: >> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. >> >> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Thread safety: AOTClassFilter::is_aot_tooling_class() can potentially be called by multiple threads concurrently > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Added single-thread-only assert for AOTClassFilter > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Refactored CollectClassesForLinking for simplification > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Reverted some fixes in systemDictionaryShared.cpp that causes test failures > - 8353014: Exclude AOT tooling classes from AOT cache Marked as reviewed by vlivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24272#pullrequestreview-2751426214 From duke at openjdk.org Tue Apr 8 22:12:31 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 8 Apr 2025 22:12:31 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> References: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> Message-ID: On Tue, 8 Apr 2025 05:23:20 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe 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: > > - Test fix for 32-bit > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - move line > - move line > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - not on 32-bit > - Deprecate UseCompressedClassPointers test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 108: > 106: OutputAnalyzer output = CommandLineOptionTest.startVMWithOptions(optionNames, expectedValues); > 107: output.reportDiagnosticSummary(); > 108: Suggestion: output.reportDiagnosticSummary(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2034103108 From dholmes at openjdk.org Tue Apr 8 23:02:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Apr 2025 23:02:33 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> <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com> Message-ID: On Thu, 3 Apr 2025 17:55:16 GMT, Patricio Chilano Mateo wrote: >> David, we had an internal Zoom meeting with Patricio and agreed on a couple of points (I hope, Patricio will fix me if needed). >> #1: >> The main (biggest) problem is the call to `JvmtiEventController::thread_started()` in the function `get_jvmti_thread_state()`. The function `JvmtiThreadState::state_for()` is called there if a mounted virtual thread is the current thread and any thread-filtered event is enabled globally. The function `JvmtiThreadState::state_for()` has this line: `MutexLocker mu(JvmtiThreadState_lock);` >> >> The `JvmtiThreadState_lock` allows safepointing. It is where a JVMTI suspend request for this thread has been processed/registered. The `SingleStep` events for this thread are also enabled after the suspend request was processed/registered. However, suspends are not allowed by this `MutexLocker`. >> This is very common code path for any thread-filtered event (e.g. the event can be enabled for a specific thread). >> >> #2: >> This PR fixes this exact issue with this update: >> >> JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread) { >> assert(thread == JavaThread::current(), "must be current thread"); >> if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { >> JvmtiEventController::thread_started(thread); >> + if (thread->is_suspended()) { >> + // suspend here if there is a suspend request >> + ThreadBlockInVM tbivm(thread); >> + } >> } >> . . . >> >> >> But we also agreed to add a tweak for the function `post_dynamic_code_generated_while_holding_locks()` to disallow suspension in this context. Then it will look like this: >> >> +JvmtiThreadState* JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) { >> assert(thread == JavaThread::current(), "must be current thread"); >> if (thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr) { >> JvmtiEventController::thread_started(thread); >> + if (allow_suspend && thread->is_suspended()) { >> + // suspend here if there is a suspend request >> + ThreadBlockInVM tbivm(thread, true /* allow suspend */); >> + } >> } >> . . . >> >> void JvmtiExport::post_dynamic_code_generated_while_holding_locks(const char* name, >> address code_begin, address code_end) >> { >> . . . >> JvmtiThreadState *state = get_jvmti_thread_state(thread, false /* allow_suspend */); >> . . . >> >> >> I have already pushed the minor tweak above.... > > Thanks for the summary Serguei. I would only add that IMO, given that it?s already clear there could be many suspend points before even reaching one of this `JvmtiExport::post_*` methods (like the one shown in #3), I would just address all these cases here too my moving the suspend check outside of the `thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr` conditional. But since this PR has already been blocked for too long I?m okay if we only want to address the specific suspend point in #1. I thought we already guarded/handled suspension whilst acquiring a mutex, as a general case. ??? Now I am getting really confused about the state of the world. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034142625 From dholmes at openjdk.org Tue Apr 8 23:26:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Apr 2025 23:26:28 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v8] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 03:20:17 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge > - review: add workaround for post_dynamic_code_generated_while_holding_locks > - Merge > - Merge > - review: move suspend point from post_single_step() to get_jvmti_thread_state() > - 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 Okay as a point fix what has been proposed seems reasonable. I would like some addtional comments please. But I would really like to see some high-level design documents for all the interactions here because I can't get complete sense of the big picture here. It seems we are forever playing whack-a-mole when it comes to virtual threads and JVMTI. Thanks 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: } We need some kind of comment before `thread_started` to make it clear why we need to check suspension only on this path. Something like: // Within thread_started we could block on a VM mutex which would allow this thread to be marked as suspended, // so in some cases we need to honor that suspend request before procedding. src/hotspot/share/prims/jvmtiExport.hpp line 312: > 310: // is enabled globally then it is created. > 311: // Otherwise, the thread->jvmti_thread_state() is returned. > 312: static JvmtiThreadState* get_jvmti_thread_state(JavaThread *thread, bool allow_suspend = true); Please add a detailed comment on what the `allow_suspend` parameter means and when it should be true and false. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2751600747 PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034158938 PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034159526 From lmesnik at openjdk.org Wed Apr 9 00:06:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 9 Apr 2025 00:06:41 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - length checking update > - Chris feedback Marked as reviewed by lmesnik (Reviewer). test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 100: > 98: output.shouldContain("Dumping heap to " + type + ".hprof"); > 99: File dump = new File(heapdumpFilename); > 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath()); I. think you could just update the test to use heapdumpFilename = type + ".%p.hprof"; we don't need test twice, it is quite expensive. test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 115: > 113: output.stdoutShouldNotBeEmpty(); > 114: String actualHeapdumpFilename = type + "." + output.pid() + ".hprof"; > 115: output.shouldContain("Dumping heap to " + actualHeapdumpFilename); This better to be something like expectedlHeapdumpFilename and "Expected heap dump file". Not very important, but make log cleaner. ------------- PR Review: https://git.openjdk.org/jdk/pull/24482#pullrequestreview-2751644078 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034187020 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034189152 From iklam at openjdk.org Wed Apr 9 01:18:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 01:18:47 GMT Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache [v5] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 16:04:29 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache >> - Thread safety: AOTClassFilter::is_aot_tooling_class() can potentially be called by multiple threads concurrently >> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache >> - Added single-thread-only assert for AOTClassFilter >> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache >> - Refactored CollectClassesForLinking for simplification >> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache >> - Reverted some fixes in systemDictionaryShared.cpp that causes test failures >> - 8353014: Exclude AOT tooling classes from AOT cache > > Seems fine. Thanks @vnkozlov @iwanowww @rose00 for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2788035165 From iklam at openjdk.org Wed Apr 9 01:18:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 01:18:48 GMT Subject: Integrated: 8353014: Exclude AOT tooling classes from AOT cache In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 03:47:07 GMT, Ioi Lam wrote: > When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint. > > In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used. This pull request has now been integrated. Changeset: c26c5758 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/c26c5758679b803489f401fbb23e8153ca10e19f Stats: 328 lines in 14 files changed: 244 ins; 49 del; 35 mod 8353014: Exclude AOT tooling classes from AOT cache Reviewed-by: vlivanov, kvn ------------- PR: https://git.openjdk.org/jdk/pull/24272 From zgu at openjdk.org Wed Apr 9 01:21:40 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 9 Apr 2025 01:21:40 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 19:32:02 GMT, Roman Kennke wrote: > As title says. LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24522#pullrequestreview-2751810885 From dholmes at openjdk.org Wed Apr 9 01:25:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Apr 2025 01:25:36 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 19:32:02 GMT, Roman Kennke wrote: > As title says. Are there no tests that need `-XX:+UnlockExperimentalVMOptions` to be removed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24522#issuecomment-2788047463 From dholmes at openjdk.org Wed Apr 9 01:29:26 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Apr 2025 01:29:26 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> References: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> Message-ID: On Tue, 8 Apr 2025 05:23:20 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe 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: > > - Test fix for 32-bit > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - move line > - move line > - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers > - not on 32-bit > - Deprecate UseCompressedClassPointers Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24436#pullrequestreview-2751818316 From fyang at openjdk.org Wed Apr 9 01:47:29 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 9 Apr 2025 01:47:29 GMT Subject: RFR: 8353829: RISC-V: Auto-enable several more extensions for debug builds In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 07:45:33 GMT, Fei Yang wrote: > Hi, > Please consider this followup change after https://bugs.openjdk.org/browse/JDK-8353344. > This adds detection and enablement of two more extensions: Ztso and Zacas. > Testing: hs:tier1-hs:tier3 tested with qemu-system equipmented with these extensions. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24478#issuecomment-2788068484 From fyang at openjdk.org Wed Apr 9 01:47:29 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 9 Apr 2025 01:47:29 GMT Subject: Integrated: 8353829: RISC-V: Auto-enable several more extensions for debug builds In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 07:45:33 GMT, Fei Yang wrote: > Hi, > Please consider this followup change after https://bugs.openjdk.org/browse/JDK-8353344. > This adds detection and enablement of two more extensions: Ztso and Zacas. > Testing: hs:tier1-hs:tier3 tested with qemu-system equipmented with these extensions. This pull request has now been integrated. Changeset: 73bb6472 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/73bb647218ac4c9742cb974d23c5f223bbd56c0a Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8353829: RISC-V: Auto-enable several more extensions for debug builds Reviewed-by: rehn, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/24478 From iklam at openjdk.org Wed Apr 9 02:18:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 02:18:41 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v4] In-Reply-To: References: Message-ID: > Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. > > In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: > > > const char* CDSConfig::input_static_archive_path(); > const char* CDSConfig::input_dynamic_archive_path(); > const char* CDSConfig::output_archive_path(); > > > This PR also cleans up the code by: > - renaming a few function to reflect what they actually do > - moving more "config" management code into cdsConfig.cpp > > There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. > > However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'master' into 8353597-refactor-aot-cache-input-output - @lmesnik comments - more clean up - Minimized changes in ergo_init_classic_archive_paths() - Clean up CDS input/output path handling - Refactored CollectClassesForLinking for simplification - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache - Reverted some fixes in systemDictionaryShared.cpp that causes test failures - 8353014: Exclude AOT tooling classes from AOT cache ------------- Changes: https://git.openjdk.org/jdk/pull/24401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=03 Stats: 309 lines in 15 files changed: 161 ins; 55 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/24401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401 PR: https://git.openjdk.org/jdk/pull/24401 From dholmes at openjdk.org Wed Apr 9 02:51:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Apr 2025 02:51:34 GMT Subject: RFR: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count In-Reply-To: References: Message-ID: <2ECXzVVd78YbJ2be9lza1KCi5e6Q_bbhEw1Us46ad6M=.568f50a4-c24c-4e83-9874-2b79b2a379d3@github.com> On Fri, 4 Apr 2025 01:32:48 GMT, Zhengyu Gu wrote: > It is a simple atomic counter for tracking hash table's load factor, only needs atomic guarantee. This seems safe. Not sure what the motivation is though? Generally we only make things relaxed when there is a performance hit to it not being relaxed. Otherwise its too hard to reason about why/when something can be relaxed and when not. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24432#pullrequestreview-2751906473 From asmehra at openjdk.org Wed Apr 9 04:06:30 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 9 Apr 2025 04:06:30 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v4] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:18:41 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. >> >> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: >> >> >> const char* CDSConfig::input_static_archive_path(); >> const char* CDSConfig::input_dynamic_archive_path(); >> const char* CDSConfig::output_archive_path(); >> >> >> This PR also cleans up the code by: >> - renaming a few function to reflect what they actually do >> - moving more "config" management code into cdsConfig.cpp >> >> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. >> >> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'master' into 8353597-refactor-aot-cache-input-output > - @lmesnik comments > - more clean up > - Minimized changes in ergo_init_classic_archive_paths() > - Clean up CDS input/output path handling > - Refactored CollectClassesForLinking for simplification > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Reverted some fixes in systemDictionaryShared.cpp that causes test failures > - 8353014: Exclude AOT tooling classes from AOT cache lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2751975775 From stuefe at openjdk.org Wed Apr 9 05:16:00 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 05:16:00 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v6] In-Reply-To: References: Message-ID: > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: fix whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/1ee16bfe..61cf5b19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From stuefe at openjdk.org Wed Apr 9 05:16:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 05:16:01 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: References: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> Message-ID: On Tue, 8 Apr 2025 17:33:17 GMT, Coleen Phillimore wrote: >> Thomas Stuefe 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: >> >> - Test fix for 32-bit >> - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - move line >> - move line >> - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - not on 32-bit >> - Deprecate UseCompressedClassPointers > > Looks good modulo the whitespace errors. @coleenp @dholmes-ora need a re-review from a Reviewer I guess. Stricter skara rules. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24436#issuecomment-2788300926 From stuefe at openjdk.org Wed Apr 9 05:16:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 05:16:01 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v5] In-Reply-To: References: <_SIrm7aka8qvlVL_bhlgE0GnLeeoae4ywt_mFuwL-3I=.6b11df6c-9303-4c7a-9a31-346e44a844eb@github.com> Message-ID: On Tue, 8 Apr 2025 22:10:13 GMT, ExE Boss wrote: >> Thomas Stuefe 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: >> >> - Test fix for 32-bit >> - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - move line >> - move line >> - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers >> - not on 32-bit >> - Deprecate UseCompressedClassPointers > > test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 108: > >> 106: OutputAnalyzer output = CommandLineOptionTest.startVMWithOptions(optionNames, expectedValues); >> 107: output.reportDiagnosticSummary(); >> 108: > > Suggestion: > > output.reportDiagnosticSummary(); Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24436#discussion_r2034457978 From sspitsyn at openjdk.org Wed Apr 9 05:34:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Apr 2025 05:34:36 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v8] In-Reply-To: References: Message-ID: <32zM3oaxn7lq-jA8CdwjuJit2QPeCh8D-5h-KsrXXTI=.bce1f45d-e761-42d5-aa73-c18fbdc527a3@github.com> On Tue, 8 Apr 2025 23:21:44 GMT, David Holmes wrote: >> 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 nine additional commits since the last revision: >> >> - Merge >> - review: add workaround for post_dynamic_code_generated_while_holding_locks >> - Merge >> - Merge >> - review: move suspend point from post_single_step() to get_jvmti_thread_state() >> - 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 > > 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: } > > We need some kind of comment before `thread_started` to make it clear why we need to check suspension only on this path. Something like: > > // Within thread_started we could block on a VM mutex which would allow this thread to be marked as suspended, > // so in some cases we need to honor that suspend request before procedding. This a reasonable suggestion, thanks! Will add a better comment. In fact, I forgot to add such a comment myself. > src/hotspot/share/prims/jvmtiExport.hpp line 312: > >> 310: // is enabled globally then it is created. >> 311: // Otherwise, the thread->jvmti_thread_state() is returned. >> 312: static JvmtiThreadState* get_jvmti_thread_state(JavaThread *thread, bool allow_suspend = true); > > Please add a detailed comment on what the `allow_suspend` parameter means and when it should be true and false. Good suggestion, thanks! Will add a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034474656 PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034475376 From sspitsyn at openjdk.org Wed Apr 9 05:46:32 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Apr 2025 05:46:32 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> <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com> Message-ID: On Tue, 8 Apr 2025 22:59:34 GMT, David Holmes wrote: >> Thanks for the summary Serguei. I would only add that IMO, given that it?s already clear there could be many suspend points before even reaching one of this `JvmtiExport::post_*` methods (like the one shown in #3), I would just address all these cases here too my moving the suspend check outside of the `thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr` conditional. But since this PR has already been blocked for too long I?m okay if we only want to address the specific suspend point in #1. > > I thought we already guarded/handled suspension whilst acquiring a mutex, as a general case. ??? Now I am getting really confused about the state of the world. I guess, you've already figured this out even though it pretty confusing. One more explanation would not hurt. We may get a new suspend request down the call to `thread_started()=>state_for()` in the `MutexLocker mu(JvmtiThreadState_lock)` but the the suspending is not allowed in this `MutexLocker`. So, we need to add a suspend point after this call: JvmtiEventController::thread_started(thread); + if (allow_suspend && thread->is_suspended()) { + // suspend here if there is a suspend request + ThreadBlockInVM tbivm(thread, true /* allow suspend */); + } I'm not sure, if it is possible to allow a suspend in this `MutexLocker`. It would simplify the code if there is a way to do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034486921 From sspitsyn at openjdk.org Wed Apr 9 06:05:28 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Apr 2025 06:05:28 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v8] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 03:20:17 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge > - review: add workaround for post_dynamic_code_generated_while_holding_locks > - Merge > - Merge > - review: move suspend point from post_single_step() to get_jvmti_thread_state() > - 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 > Okay as a point fix what has been proposed seems reasonable. I would like some additional comments please. Thank you for looking at it again and your passion, David. > But I would really like to see some high-level design documents for all the interactions here because I can't get complete sense of the big picture here. It seems we are forever playing whack-a-mole when it comes to virtual threads and JVMTI. What kind of a design document can it be? The complexity comes from the fact that virtual threads can be unmounted so we can't walk all of them when JVMTI `SetEventNotificationMode()` is called to create a `JvmtiThreadState` object for each unmounted virtual thread. Another complexity comes from the scalability requirements. The last point where we still can create a `JvmtiThreadState` object is before an event posting. So, it is done with a call to the `jvmtiEventController::thread_started()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2788366572 From ccheung at openjdk.org Wed Apr 9 06:19:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 9 Apr 2025 06:19:52 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v6] In-Reply-To: References: Message-ID: > The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. > > Passed tiers 1 - 3 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: simplify the code by using stringStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/e107e569..e3ed1a2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=04-05 Stats: 35 lines in 4 files changed: 6 ins; 12 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From ccheung at openjdk.org Wed Apr 9 06:19:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 9 Apr 2025 06:19:52 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 08:16:27 GMT, Thomas Stuefe wrote: > > > Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? > > > > > > AIX has a different dll lookup mechanism, but otherwise these should be pretty much identical. Windows also only really differs in the lookup mechanism. Maybe new RFE to refactor these and share some code? > > Okay. The code could also be simpler if it were to use stringStream, spanned over the caller-provided buffer. No character counting and truncation handling needed then (but we would need to add truncation detection to stringStream, but that is really easy). I agree with David about doing the refactoring in a new RFE. I've simplified the code by using stringStream as you suggested. I didn't add truncation detection to stringStream (which I think could be done in another RFE). However, I added an assert in `os::jvm_path()` to ensure there's no truncation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2788389180 From stuefe at openjdk.org Wed Apr 9 06:38:33 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 06:38:33 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v6] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 06:19:52 GMT, Calvin Cheung wrote: >> The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > simplify the code by using stringStream Nice, this looks good to me. Thank you. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24310#pullrequestreview-2752209598 From stuefe at openjdk.org Wed Apr 9 06:46:35 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 06:46:35 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: <1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com> On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - length checking update > - Chris feedback src/hotspot/share/services/heapDumper.cpp line 2760: > 2758: if (dump_file_seq == 0) { // first time in, we initialize base_path > 2759: // Set base path (name or directory, default or custom, without seq no), doing %p substitution. > 2760: const char *path_src = (HeapDumpPath != nullptr && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name; Why do you expand the dump file name here? If you want to minimize the expand calls, you could: - append the unexpanded dump_file_name to the unexpanded HeapDumpPath - expand - create dir (extract the directory name by temporarily setting the the last '/' to '\0; create dir; restore '/') now you are done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034576102 From azafari at openjdk.org Wed Apr 9 08:12:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Apr 2025 08:12:59 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v10] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed format of the missed Pre ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/517b1348..99188e22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=08-09 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From sspitsyn at openjdk.org Wed Apr 9 08:48:02 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Apr 2025 08:48:02 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v9] In-Reply-To: References: Message-ID: > 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: added a couple of comments with important clarifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23490/files - new: https://git.openjdk.org/jdk/pull/23490/files/cdb47686..67277dbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=07-08 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 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 kevinw at openjdk.org Wed Apr 9 08:52:31 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 08:52:31 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: <1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com> References: <1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com> Message-ID: On Wed, 9 Apr 2025 06:43:20 GMT, Thomas Stuefe wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - length checking update >> - Chris feedback > > src/hotspot/share/services/heapDumper.cpp line 2760: > >> 2758: if (dump_file_seq == 0) { // first time in, we initialize base_path >> 2759: // Set base path (name or directory, default or custom, without seq no), doing %p substitution. >> 2760: const char *path_src = (HeapDumpPath != nullptr && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name; > > Why do you expand the dump file name here? > > If you want to minimize the expand calls, you could: > > - append the unexpanded dump_file_name to the unexpanded HeapDumpPath > - expand > - create dir (extract the directory name by temporarily setting the the last '/' to '\0; create dir; restore '/') > now you are done. It concerned me that we presume there is no %p in the directory/path. It might be tricky (get the pid, create a directory, before the first heap dump), but it's possible. Trying to use an existing directory with a literal %p in it will fail, but we can't have this both ways, and should either honour the %p substitution fully, or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034820138 From tpushkin at openjdk.org Wed Apr 9 09:06:44 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 9 Apr 2025 09:06:44 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Tue, 8 Apr 2025 17:36:57 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary scoping > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 438: > >> 436: // class loader. Thus it is safe to delegate their loading to system class loader >> 437: // (our parent) - this is what the default implementation of loadClass() will do. >> 438: return defineClass(name, bytes, 0, bytes.length); > > I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify? > > > // defineClass() will internally invoke loadClass() to load supertypes of this unregistered class. > // Any supertype S with the name SN must have already been loaded (enforced by the order > // of classes in the classlist). In addition: > // - if S is an unregistered class, S must have already been have been defined by the current class > // loader, and will be found by `this.findLoadedClass(SN)` > // - if S is not an unregistered class, S must have already been defined by the built-in boot, > // platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false) > // See the implementation of ClassLoader::loadClass() for details. > // > // Therefore, we should resolve all supertypes to the expected ones as specified by the > // super: and interfaces: attributes in the classlist. This > // invariance is validated by the C++ function ClassListParser::load_class_from_source() > assert getParent() == getSystemClassLoader(); > return defineClass(name, bytes, 0, bytes.length); I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Dsystem.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders. For example: - Let C= be a class C named N defined by class loader L - Let AppL be the built-in system class loader and SysL be the user-provided system class loader - Let U be an unregistered class which extends a registered - Let SysL be able to load a registered when requested (i.e. SysL doesn't delegate when loading a class named S) - When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus will become a super of U instead of ? this is an error (which will then be detected in `ClassListParser::load_class_from_source()` but still) This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U. This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends will not be handeled correctly ( will be used instead of ). So it looks like I have to revert this delegation-based approach and use the old way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2034846610 From kevinw at openjdk.org Wed Apr 9 09:34:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 09:34:02 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 00:00:28 GMT, Leonid Mesnik wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - length checking update >> - Chris feedback > > test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 100: > >> 98: output.shouldContain("Dumping heap to " + type + ".hprof"); >> 99: File dump = new File(heapdumpFilename); >> 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath()); > > I. think you could just update the test to use > heapdumpFilename = type + ".%p.hprof"; > we don't need test twice, it is quite expensive. sure, it's a few seconds but we can save that time 8-) > test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 115: > >> 113: output.stdoutShouldNotBeEmpty(); >> 114: String actualHeapdumpFilename = type + "." + output.pid() + ".hprof"; >> 115: output.shouldContain("Dumping heap to " + actualHeapdumpFilename); > > This better to be something like expectedlHeapdumpFilename and > "Expected heap dump file". > > Not very important, but make log cleaner. sure, done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034931003 PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034931425 From kevinw at openjdk.org Wed Apr 9 09:34:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 09:34:02 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v3] In-Reply-To: References: Message-ID: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: test feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24482/files - new: https://git.openjdk.org/jdk/pull/24482/files/c32e4ca4..40c67a0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=01-02 Stats: 24 lines in 1 file changed: 1 ins; 17 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482 PR: https://git.openjdk.org/jdk/pull/24482 From stuefe at openjdk.org Wed Apr 9 10:45:32 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Apr 2025 10:45:32 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v3] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 09:34:02 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > test feedback Looks good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24482#pullrequestreview-2753028819 From rkennke at openjdk.org Wed Apr 9 10:59:44 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 9 Apr 2025 10:59:44 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option [v2] In-Reply-To: References: Message-ID: > As title says. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Remove +UnlockExperimentalOptions from tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24522/files - new: https://git.openjdk.org/jdk/pull/24522/files/31035040..56a50df8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=00-01 Stats: 81 lines in 23 files changed: 0 ins; 12 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/24522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24522/head:pull/24522 PR: https://git.openjdk.org/jdk/pull/24522 From kevinw at openjdk.org Wed Apr 9 11:04:26 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 11:04:26 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v4] In-Reply-To: References: Message-ID: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into HeapDumpPath_pid - test feedback - length checking update - Chris feedback - 8353727: HeapDumpPath doesn't expand %p ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24482/files - new: https://git.openjdk.org/jdk/pull/24482/files/40c67a0c..09f66542 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=02-03 Stats: 11976 lines in 335 files changed: 8329 ins; 2524 del; 1123 mod Patch: https://git.openjdk.org/jdk/pull/24482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482 PR: https://git.openjdk.org/jdk/pull/24482 From jsjolen at openjdk.org Wed Apr 9 12:15:06 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 9 Apr 2025 12:15:06 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm Message-ID: Hi, The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) 2. Print the entirety of the log file produced if no missing messages are found 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. If the test fails in the future, then these will give important diagnostic information regarding the state of the test. This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 ------------- Commit messages: - Fix str - Do not use BufferUpdater - Improvements to async UL gtests Changes: https://git.openjdk.org/jdk/pull/24508/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24508&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352568 Stats: 73 lines in 4 files changed: 27 ins; 39 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24508/head:pull/24508 PR: https://git.openjdk.org/jdk/pull/24508 From coleenp at openjdk.org Wed Apr 9 12:21:33 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Apr 2025 12:21:33 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v6] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 05:16:00 GMT, Thomas Stuefe wrote: >> Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). >> >> Testing: >> >> I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. >> >> I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespaces Re-reviewed. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24436#pullrequestreview-2753271897 From zgu at openjdk.org Wed Apr 9 13:01:34 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 9 Apr 2025 13:01:34 GMT Subject: RFR: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count In-Reply-To: <2ECXzVVd78YbJ2be9lza1KCi5e6Q_bbhEw1Us46ad6M=.568f50a4-c24c-4e83-9874-2b79b2a379d3@github.com> References: <2ECXzVVd78YbJ2be9lza1KCi5e6Q_bbhEw1Us46ad6M=.568f50a4-c24c-4e83-9874-2b79b2a379d3@github.com> Message-ID: <53cVlok34K7_nH2wvGz0cUbcOfO7KK-HYiyyTF6-Dc8=.1bdf978c-9f0f-41f0-be99-1f7ac80552e8@github.com> On Wed, 9 Apr 2025 02:49:23 GMT, David Holmes wrote: > This seems safe. Not sure what the motivation is though? Generally we only make things relaxed when there is a performance hit to it not being relaxed. Otherwise its too hard to reason about why/when something can be relaxed and when not. @dholmes-ora I agree not making change to where memory semantics is not clear. But this one is pretty obvious, is it? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24432#issuecomment-2789616539 From zgu at openjdk.org Wed Apr 9 13:01:35 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 9 Apr 2025 13:01:35 GMT Subject: RFR: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count In-Reply-To: References: Message-ID: <6DjabvmqJWGKhB6ZaX9ypEWrndgE9sBHjfGY66yVMcY=.0892dd81-bc8d-4493-bbe5-f259b643167d@github.com> On Fri, 4 Apr 2025 01:32:48 GMT, Zhengyu Gu wrote: > It is a simple atomic counter for tracking hash table's load factor, only needs atomic guarantee. Thanks @rkennke @dholmes-ora for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24432#issuecomment-2789617939 From zgu at openjdk.org Wed Apr 9 13:01:36 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 9 Apr 2025 13:01:36 GMT Subject: Integrated: 8353692: Relax memory constraint on updating ObjectMonitorTable's item count In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 01:32:48 GMT, Zhengyu Gu wrote: > It is a simple atomic counter for tracking hash table's load factor, only needs atomic guarantee. This pull request has now been integrated. Changeset: da462cf2 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk/commit/da462cf2255f55c1059f9d9bf479231408a72b55 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8353692: Relax memory constraint on updating ObjectMonitorTable's item count Reviewed-by: rkennke, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24432 From liach at openjdk.org Wed Apr 9 13:47:34 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Apr 2025 13:47:34 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option [v2] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 10:59:44 GMT, Roman Kennke wrote: >> As title says. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove +UnlockExperimentalOptions from tests I just noticed we missed this flag for https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html#advanced-runtime-options-for-java - if we add this option to `java.md`, should we do it in this patch or a separate patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24522#issuecomment-2789792215 From kvn at openjdk.org Wed Apr 9 14:01:44 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 9 Apr 2025 14:01:44 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v4] In-Reply-To: References: Message-ID: <9g5m1aRjX_bOUqojs3da5pKPapimb1lnYxqdA92l8jk=.03e0aa78-bc7b-419a-814a-3104f300bf13@github.com> On Wed, 9 Apr 2025 02:18:41 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. >> >> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: >> >> >> const char* CDSConfig::input_static_archive_path(); >> const char* CDSConfig::input_dynamic_archive_path(); >> const char* CDSConfig::output_archive_path(); >> >> >> This PR also cleans up the code by: >> - renaming a few function to reflect what they actually do >> - moving more "config" management code into cdsConfig.cpp >> >> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. >> >> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'master' into 8353597-refactor-aot-cache-input-output > - @lmesnik comments > - more clean up > - Minimized changes in ergo_init_classic_archive_paths() > - Clean up CDS input/output path handling > - Refactored CollectClassesForLinking for simplification > - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache > - Reverted some fixes in systemDictionaryShared.cpp that causes test failures > - 8353014: Exclude AOT tooling classes from AOT cache Re-approved. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2753597060 From kevinw at openjdk.org Wed Apr 9 14:51:48 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 14:51:48 GMT Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v4] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 11:04:26 GMT, Kevin Walls wrote: >> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. >> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. >> It has always done a manual "root plus pid plus extension" on the default filename only, and >> should move to using Argument::copy_expand_pid() like we do with other such filenames. >> >> >> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into HeapDumpPath_pid > - test feedback > - length checking update > - Chris feedback > - 8353727: HeapDumpPath doesn't expand %p Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2789998024 From kevinw at openjdk.org Wed Apr 9 14:51:48 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Apr 2025 14:51:48 GMT Subject: Integrated: 8353727: HeapDumpPath doesn't expand %p In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls wrote: > This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion. > The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not. > It has always done a manual "root plus pid plus extension" on the default filename only, and > should move to using Argument::copy_expand_pid() like we do with other such filenames. > > > We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true). This pull request has now been integrated. Changeset: 7a7b9ed7 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/7a7b9ed7fe4a10bca155b0877c3e731f9d343b92 Stats: 71 lines in 2 files changed: 10 ins; 37 del; 24 mod 8353727: HeapDumpPath doesn't expand %p Reviewed-by: stuefe, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24482 From iklam at openjdk.org Wed Apr 9 15:03:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 15:03:44 GMT Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:02:01 GMT, Vladimir Kozlov wrote: >>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded. >>> >>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`: >>> >>> ``` >>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) { >>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true); >>> ... >>> if (AOTClassLinking && is_dumping_final_static_archive()) { >>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true); >>> ``` >>> >>> First, I am not sure these conditions are correct. >>> >>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`. >>> >>> May be also consider it is error if both conditions are true (we don't support updating archive yet). >> >> There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code. >> >> In the handling of such "AOT capability flags", I have been using the following pattern: >> >> In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default. >> >> >> if (!FLAG_IS_DEFAULT(AOTMode)) { >> // Using any form of the new AOTMode switch enables enhanced optimizations. >> FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true); >> } >> >> if (AOTClassLinking) { >> // If AOTClassLinking is specified, enable all AOT optimizations by default. >> FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true); >> } else { >> // AOTInvokeDynamicLinking depends on AOTClassLinking. >> FLAG_SET_ERGO(AOTInvokeDynamicLinking, false); >> } >> >> >> However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used. >> >> Because the dependencies are complex, it's difficult to resolve them statically and set a globa... > > Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`: > > > MetaspaceShared::initialize_shared_spaces() { > ... > static_mapinfo->patch_heap_embedded_pointers(); > ArchiveHeapLoader::finish_initialization(); > Universe::load_archived_object_instances(); > + AOTCodeCache::initialize(); > > > The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)? > > Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere. Thanks @vnkozlov @ashu-mehra @DanHeidinga @lmesnik for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2790037592 From iklam at openjdk.org Wed Apr 9 15:07:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 15:07:14 GMT Subject: Integrated: 8353597: Refactor handling VM options for AOT cache input and output In-Reply-To: References: Message-ID: <5DDGpghIYxMiMRk8aXwnHqcBgepkaDIZJT0gxtje8JI=.0aad39c1-5513-4638-99f2-8a96f447595c@github.com> On Thu, 3 Apr 2025 04:00:59 GMT, Ioi Lam wrote: > Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`. > > In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs: > > > const char* CDSConfig::input_static_archive_path(); > const char* CDSConfig::input_dynamic_archive_path(); > const char* CDSConfig::output_archive_path(); > > > This PR also cleans up the code by: > - renaming a few function to reflect what they actually do > - moving more "config" management code into cdsConfig.cpp > > There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage. > > However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases This pull request has now been integrated. Changeset: 567c6885 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/567c6885a377e5641deef9cd3498f79c5346cd6a Stats: 309 lines in 15 files changed: 161 ins; 55 del; 93 mod 8353597: Refactor handling VM options for AOT cache input and output Reviewed-by: kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/24401 From iklam at openjdk.org Wed Apr 9 15:25:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Apr 2025 15:25:30 GMT Subject: RFR: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 02:44:44 GMT, Ioi Lam wrote: > This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. > > @iwanowww @shipilev could you review? @iwanowww @shipilev could you review? The same code is already in premain branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24434#issuecomment-2790101115 From duke at openjdk.org Wed Apr 9 15:51:56 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Wed, 9 Apr 2025 15:51:56 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems Message-ID: The issue was a trailing newline in a message argument to: log_debug(os, container)(...) `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. The old vs new output on my `Alpine Linux v3.21` virtual machine is: --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 @@ -1,10 +1,8 @@ [0.000s][trace][os,container] OSContainer::init: Initializing Container Support [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.000s][debug][os,container] controller cpuset is not enabled -[ ] [0.000s][debug][os,container] controller memory is not enabled -[ ] [0.000s][debug][os,container] One or more required controllers disabled at kernel level. openjdk version "25-internal" 2025-09-16 -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) Regression-tested with: make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" ------------- Commit messages: - 8354057: Odd debug output in -Xlog:os+container=debug on certain systems Changes: https://git.openjdk.org/jdk/pull/24533/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24533&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354057 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24533/head:pull/24533 PR: https://git.openjdk.org/jdk/pull/24533 From shade at openjdk.org Wed Apr 9 16:07:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 9 Apr 2025 16:07:46 GMT Subject: RFR: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 02:44:44 GMT, Ioi Lam wrote: > This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. > > @iwanowww @shipilev could you review? Sorry, yes, looks reasonable. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24434#pullrequestreview-2754009522 From sgehwolf at openjdk.org Wed Apr 9 16:40:25 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 9 Apr 2025 16:40:25 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24533#pullrequestreview-2754105402 From gziemski at openjdk.org Wed Apr 9 16:41:36 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 9 Apr 2025 16:41:36 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v10] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 08:12:59 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed format of the missed Pre Changes requested by gziemski (Reviewer). src/hotspot/share/nmt/vmatree.cpp line 69: > 67: stA.out.set_reserve_stack(NativeCallStackStorage::invalid); > 68: stB.in.set_reserve_stack(NativeCallStackStorage::invalid); > 69: } I'd prefer to see this as: // set default values, then depending on operation later, fill the required states stA.out.set_commit_stack(NativeCallStackStorage::invalid); stA.in.set_commit_stack(NativeCallStackStorage::invalid); stA.out.set_reserve_stack(NativeCallStackStorage::invalid); stB.in.set_reserve_stack(NativeCallStackStorage::invalid); if (is_reserve_operation) { stA.out.set_reserve_stack(metadata.stack_idx); stB.in.set_reserve_stack(metadata.stack_idx); } if (is_commit_operation) { stA.out.set_commit_stack(metadata.stack_idx); stB.in.set_commit_stack(metadata.stack_idx); } Than later on we can skip setting these default values altogether and only touch the ones we need to. src/hotspot/share/nmt/vmatree.cpp line 147: > 145: stB.in.set_reserve_stack(leqA_n->val().out.reserved_stack()); > 146: stA.out.set_commit_stack(NativeCallStackStorage::invalid); > 147: stB.in.set_commit_stack(NativeCallStackStorage::invalid); Wouldn't need to do those if we followed my suggestion above? ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2754081239 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2035731645 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2035746412 From tpushkin at openjdk.org Wed Apr 9 16:46:36 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 9 Apr 2025 16:46:36 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Wed, 9 Apr 2025 09:03:41 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 438: >> >>> 436: // class loader. Thus it is safe to delegate their loading to system class loader >>> 437: // (our parent) - this is what the default implementation of loadClass() will do. >>> 438: return defineClass(name, bytes, 0, bytes.length); >> >> I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify? >> >> >> // defineClass() will internally invoke loadClass() to load supertypes of this unregistered class. >> // Any supertype S with the name SN must have already been loaded (enforced by the order >> // of classes in the classlist). In addition: >> // - if S is an unregistered class, S must have already been have been defined by the current class >> // loader, and will be found by `this.findLoadedClass(SN)` >> // - if S is not an unregistered class, S must have already been defined by the built-in boot, >> // platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false) >> // See the implementation of ClassLoader::loadClass() for details. >> // >> // Therefore, we should resolve all supertypes to the expected ones as specified by the >> // super: and interfaces: attributes in the classlist. This >> // invariance is validated by the C++ function ClassListParser::load_class_from_source() >> assert getParent() == getSystemClassLoader(); >> return defineClass(name, bytes, 0, bytes.length); > > I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Djava.system.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders. > > For example: > - Let C= be a class C named N defined by class loader L > - Let AppL be the built-in system class loader and SysL be the user-provided system class loader > - Let U be an unregistered class which extends a registered > - Let SysL be able to load a registered when requested (i.e. SysL doesn't delegate when loading a class named S) > - When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus will become a super of U instead of ? this is not correct > > This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U. > > This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends will not be handeled correctly ( will be used instead of ). > > So it looks like I have to revert this delegation-based approach and use the old way. I'll also write a test from the above example to see if I am correct first. I've realized that my example above cannot be expressed in the current class list format since the format doesn't distinguish between and , only that S is not unregistered. The existing implementation (without this PR) will always use . It feels like a flaw to me but it is not a flaw of this patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2035755124 From asmehra at openjdk.org Wed Apr 9 17:28:30 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 9 Apr 2025 17:28:30 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" looks good! ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/24533#pullrequestreview-2754220837 From lmesnik at openjdk.org Wed Apr 9 17:55:33 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 9 Apr 2025 17:55:33 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: <5LrIUXtsLNPEY4UqLOEzyoCLjtF0yZfRrVwQsX7RbFk=.c0811cc4-1f7e-448f-a7e8-a98c2324f868@github.com> On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24533#pullrequestreview-2754281668 From duke at openjdk.org Wed Apr 9 18:36:38 2025 From: duke at openjdk.org (duke) Date: Wed, 9 Apr 2025 18:36:38 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" @fitzsim Your change (at version 18c891509f8df7896525ca342711b5bec1e20310) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2790597812 From duke at openjdk.org Wed Apr 9 18:36:39 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Wed, 9 Apr 2025 18:36:39 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: <6FeTLo0NajUmmkxH0Wbwaa4mbAnGxqp5oLo3KJ3Equw=.2343e0b9-a25d-4604-86ed-d6d4ebc8093f@github.com> On Wed, 9 Apr 2025 16:37:24 GMT, Severin Gehwolf wrote: >> The issue was a trailing newline in a message argument to: >> >> >> log_debug(os, container)(...) >> >> >> `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. >> >> The old vs new output on my `Alpine Linux v3.21` virtual machine is: >> >> >> --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 >> +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 >> @@ -1,10 +1,8 @@ >> [0.000s][trace][os,container] OSContainer::init: Initializing Container Support >> [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups >> [0.000s][debug][os,container] controller cpuset is not enabled >> -[ ] >> [0.000s][debug][os,container] controller memory is not enabled >> -[ ] >> [0.000s][debug][os,container] One or more required controllers disabled at kernel level. >> openjdk version "25-internal" 2025-09-16 >> -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) >> -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) >> +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) >> +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) >> >> >> Regression-tested with: >> >> >> make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" > > Marked as reviewed by sgehwolf (Reviewer). Thank you for reviewing, @jerboaa, @ashu-mehra and @lmesnik. Can one of you please sponsor this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2790603361 From tpushkin at openjdk.org Wed Apr 9 18:37:15 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 9 Apr 2025 18:37:15 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Remove findClass, extend explanation comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/dff524c4..903f0f97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=04-05 Stats: 25 lines in 1 file changed: 11 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From sgehwolf at openjdk.org Wed Apr 9 19:57:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 9 Apr 2025 19:57:36 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" I'll sponsor this change tomorrow to satisfy for the 24 hour window (it's a trivial change, but there is no rush either). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2790844923 From dholmes at openjdk.org Thu Apr 10 00:28:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 00:28:35 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v6] In-Reply-To: References: Message-ID: <_SLcXI2SCwZpBcQUkTob02-VbCWduuB36S_UPr_3M98=.7bd2000c-677b-4367-adcb-b908dec6e089@github.com> On Wed, 9 Apr 2025 06:19:52 GMT, Calvin Cheung wrote: >> The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > simplify the code by using stringStream Looks okay. Some additional possible cleanup now you are using the stringStream. src/hotspot/os/aix/os_aix.cpp line 1330: > 1328: > 1329: len = strlen(buf); > 1330: assert(len < buflen, "Ran out of buffer room"); Suggestion: assert(strlen(buf) < buflen, "Ran out of buffer room"); and then I think the `len` local is unused. src/hotspot/os/bsd/os_bsd.cpp line 1524: > 1522: len = strlen(buf); > 1523: assert(len < buflen, "Ran out of buffer space"); > 1524: // Add the appropriate library and JVM variant subdirs Suggestion: // Add the appropriate library and JVM variant subdirs ------------- PR Review: https://git.openjdk.org/jdk/pull/24310#pullrequestreview-2755056558 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2036313005 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2036315186 From dholmes at openjdk.org Thu Apr 10 02:21:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 02:21:34 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" Hold on a minute! If only _some_ systems have this problem then only some systems generate their own newline, which implies the other systems need the newline added by UL! Maybe we need to check the actual return value and see if it ends with a newline. Or change the parsing code so that is strips any newline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2791381380 From ccheung at openjdk.org Thu Apr 10 05:14:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 10 Apr 2025 05:14:04 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v7] In-Reply-To: References: Message-ID: > The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. > > Passed tiers 1 - 3 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24310/files - new: https://git.openjdk.org/jdk/pull/24310/files/e3ed1a2b..60a10382 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=05-06 Stats: 10 lines in 3 files changed: 0 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310 PR: https://git.openjdk.org/jdk/pull/24310 From ccheung at openjdk.org Thu Apr 10 05:14:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 10 Apr 2025 05:14:04 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v6] In-Reply-To: <_SLcXI2SCwZpBcQUkTob02-VbCWduuB36S_UPr_3M98=.7bd2000c-677b-4367-adcb-b908dec6e089@github.com> References: <_SLcXI2SCwZpBcQUkTob02-VbCWduuB36S_UPr_3M98=.7bd2000c-677b-4367-adcb-b908dec6e089@github.com> Message-ID: On Thu, 10 Apr 2025 00:20:02 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify the code by using stringStream > > src/hotspot/os/aix/os_aix.cpp line 1330: > >> 1328: >> 1329: len = strlen(buf); >> 1330: assert(len < buflen, "Ran out of buffer room"); > > Suggestion: > > assert(strlen(buf) < buflen, "Ran out of buffer room"); > > and then I think the `len` local is unused. Fixed. > src/hotspot/os/bsd/os_bsd.cpp line 1524: > >> 1522: len = strlen(buf); >> 1523: assert(len < buflen, "Ran out of buffer space"); >> 1524: // Add the appropriate library and JVM variant subdirs > > Suggestion: > > // Add the appropriate library and JVM variant subdirs Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2036512401 PR Review Comment: https://git.openjdk.org/jdk/pull/24310#discussion_r2036512438 From dholmes at openjdk.org Thu Apr 10 06:21:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 06:21:31 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 05:14:04 GMT, Calvin Cheung wrote: >> The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24310#pullrequestreview-2755460115 From dholmes at openjdk.org Thu Apr 10 06:35:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 06:35:33 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v9] In-Reply-To: References: Message-ID: <4ZnLD31JnKaIDR2upvX60FvJzsVKuVo-hktNTFGCK5w=.0010c53c-02aa-4a49-8f5a-74547c58d98f@github.com> On Wed, 9 Apr 2025 08:48:02 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: added a couple of comments with important clarifications src/hotspot/share/prims/jvmtiExport.hpp line 313: > 311: // Otherwise, the thread->jvmti_thread_state() is returned. > 312: // The 'allow_suspend' parameter is passed as 'true' by default which work for almost all call sites. > 313: // It means that a suspend point need to be organized by this function for virtual threads if the call Suggestion: // It means that a suspend point needs to be organized by this function for virtual threads if the call ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2036605028 From dholmes at openjdk.org Thu Apr 10 06:42:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 06:42:28 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v9] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 08:48:02 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: added a couple of comments with important clarifications Nothing further from me in terms of this PR. Thanks for your patience and perseverance on this one. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2755505323 From dholmes at openjdk.org Thu Apr 10 06:42:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 06:42:29 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v8] In-Reply-To: References: Message-ID: <2JGcOqxx5EAEsuoDrs27nUG0yRE7Cdnmr6pirxpiVOE=.dd4f3927-3eb6-4e17-baed-b39668675df5@github.com> On Wed, 9 Apr 2025 06:02:40 GMT, Serguei Spitsyn wrote: > What kind of a design document can it be? Not sure given my confusion about the various states that are possible. We basically have a situation where we are doing something and we should not hit a safepoint check where a suspend request could be processed or a single-steo event be accepted, but we unintentionally do hit it due to blocking on an internal Mutex. This still says to me that somewhere on this code path there should be something that says "any safepoints/handshakes here should be deferred" and that would be honored by the thread-state transition code used in TBIVM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2791709335 From dholmes at openjdk.org Thu Apr 10 07:11:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 07:11:31 GMT Subject: RFR: 8350457: Support Compact Object Headers as product option [v2] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 13:44:50 GMT, Chen Liang wrote: > I just noticed we missed this flag for https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html#advanced-runtime-options-for-java - if we add this option to `java.md`, should we do it in this patch or a separate patch? It wasn't missed - we don't (generally - I'm not going to say never) document experimental flags in the command reference. Once it is a product flag then it probably should be documented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24522#issuecomment-2791770288 From dholmes at openjdk.org Thu Apr 10 07:27:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Apr 2025 07:27:37 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 Can you elaborate on what the issue with BufferUpdater was. I admit I'm not clear what it was doing. test/hotspot/gtest/logging/test_asynclog.cpp line 271: > 269: } > 270: > 271: // The thread is null and deattached. How does this come about when we control the test execution?? ------------- PR Review: https://git.openjdk.org/jdk/pull/24508#pullrequestreview-2755606003 PR Review Comment: https://git.openjdk.org/jdk/pull/24508#discussion_r2036676598 From sgehwolf at openjdk.org Thu Apr 10 08:43:44 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 10 Apr 2025 08:43:44 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 02:18:02 GMT, David Holmes wrote: > Hold on a minute! If only _some_ systems have this problem then only some systems generate their own newline, which implies the other systems need the newline added by UL! It consistently happens on systems that don't have certain controllers. Hence, the "some systems" qualification. I.e. you need to see a `controller is not enabled` for the extra new line - the bug at hand - to show up as well. Maybe that wasn't explained well. Does that make sense? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2792003269 From duke at openjdk.org Thu Apr 10 09:35:28 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 10 Apr 2025 09:35:28 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 03:22:27 GMT, Nicole Xu wrote: > 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 > ``` I saw the recent patch [`7aeaa3c`](https://github.com/openjdk/jdk/commit/7aeaa3c21c1420191fe8ff59e4cf99eae830754d), which introduced the `--disable-java-warnings-as-errors` configure option. I tried to execute the test compilation with this option offline, and the error you mentioned became warnings. Would this address the issue you raised? @cushon ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2792144752 From azafari at openjdk.org Thu Apr 10 10:02:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 10:02:29 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v11] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 24 test-cases added for full coverage of cases. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/99188e22..d5197463 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=09-10 Stats: 605 lines in 3 files changed: 587 ins; 6 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu Apr 10 10:02:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 10:02:30 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v10] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 08:12:59 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed format of the missed Pre 24 test-cases added but those related to 8354115 are skipped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2792210221 From azafari at openjdk.org Thu Apr 10 10:02:32 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 10:02:32 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v10] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 16:27:45 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed format of the missed Pre > > src/hotspot/share/nmt/vmatree.cpp line 69: > >> 67: stA.out.set_reserve_stack(NativeCallStackStorage::invalid); >> 68: stB.in.set_reserve_stack(NativeCallStackStorage::invalid); >> 69: } > > I'd prefer to see this as: > > > // set default values, then depending on operation later, fill the required states > stA.out.set_commit_stack(NativeCallStackStorage::invalid); > stA.in.set_commit_stack(NativeCallStackStorage::invalid); > stA.out.set_reserve_stack(NativeCallStackStorage::invalid); > stB.in.set_reserve_stack(NativeCallStackStorage::invalid); > > if (is_reserve_operation) { > stA.out.set_reserve_stack(metadata.stack_idx); > stB.in.set_reserve_stack(metadata.stack_idx); > } > > if (is_commit_operation) { > stA.out.set_commit_stack(metadata.stack_idx); > stB.in.set_commit_stack(metadata.stack_idx); > } > > > > Than later on we can skip setting these default values altogether and only touch the ones we need to. Done. > src/hotspot/share/nmt/vmatree.cpp line 147: > >> 145: stB.in.set_reserve_stack(leqA_n->val().out.reserved_stack()); >> 146: stA.out.set_commit_stack(NativeCallStackStorage::invalid); >> 147: stB.in.set_commit_stack(NativeCallStackStorage::invalid); > > Wouldn't need to do those if we followed my suggestion above? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2036980496 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2036981033 From azafari at openjdk.org Thu Apr 10 10:02:35 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 10:02:35 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v9] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 19:19:15 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> Pre conditions are also visualized. > > test/hotspot/gtest/nmt/test_vmatree.cpp line 975: > >> 973: >> 974: tree.uncommit_mapping(0, 5, call_stack_2); >> 975: // Pre: .........0********10--------20********40-------100......... > > I think this one got lost, still could use reformatting: > > `// Pre: .........0*****************10--------20********40-------100.........` Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2036980104 From jsjolen at openjdk.org Thu Apr 10 10:57:31 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 10 Apr 2025 10:57:31 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> References: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> Message-ID: On Thu, 10 Apr 2025 07:20:21 GMT, David Holmes wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> If the test fails in the future, then these will give important diagnostic information regarding the state of the test. >> >> This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 > > test/hotspot/gtest/logging/test_asynclog.cpp line 271: > >> 269: } >> 270: >> 271: // The thread is null and deattached. > > How does this come about when we control the test execution?? I don't think that it can come about, but I'm not ready to be left guessing the next time this fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24508#discussion_r2037076062 From azafari at openjdk.org Thu Apr 10 12:11:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 12:11:09 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region Message-ID: At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. This case is detected and abort the program using `assert`. Two test-cases added and run. ------------- Commit messages: - 8354115: NMT: VMATree should not accept `uncommit` a `released` region Changes: https://git.openjdk.org/jdk/pull/24572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354115 Stats: 27 lines in 2 files changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24572/head:pull/24572 PR: https://git.openjdk.org/jdk/pull/24572 From azafari at openjdk.org Thu Apr 10 12:52:52 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Apr 2025 12:52:52 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v2] In-Reply-To: References: Message-ID: > At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. > This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. > > Two test-cases added and run. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: returns invalid SummaryDiff, instead of assert. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24572/files - new: https://git.openjdk.org/jdk/pull/24572/files/4c10038c..7538792c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=00-01 Stats: 23 lines in 3 files changed: 14 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/24572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24572/head:pull/24572 PR: https://git.openjdk.org/jdk/pull/24572 From duke at openjdk.org Thu Apr 10 13:49:31 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Thu, 10 Apr 2025 13:49:31 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 02:18:02 GMT, David Holmes wrote: >> The issue was a trailing newline in a message argument to: >> >> >> log_debug(os, container)(...) >> >> >> `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. >> >> The old vs new output on my `Alpine Linux v3.21` virtual machine is: >> >> >> --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 >> +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 >> @@ -1,10 +1,8 @@ >> [0.000s][trace][os,container] OSContainer::init: Initializing Container Support >> [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups >> [0.000s][debug][os,container] controller cpuset is not enabled >> -[ ] >> [0.000s][debug][os,container] controller memory is not enabled >> -[ ] >> [0.000s][debug][os,container] One or more required controllers disabled at kernel level. >> openjdk version "25-internal" 2025-09-16 >> -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) >> -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) >> +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) >> +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) >> >> >> Regression-tested with: >> >> >> make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" > > Hold on a minute! If only _some_ systems have this problem then only some systems generate their own newline, which implies the other systems need the newline added by UL! > > Maybe we need to check the actual return value and see if it ends with a newline. Or change the parsing code so that is strips any newline. Thank you for reviewing @dholmes-ora. Adding to @jerboaa's latest comment, here is output from a `RHEL 8` system which is unaffected by JDK-8354057 because it does not issue the `controller %s is not enabled` message: [0.000s][trace][os,container] OSContainer::init: Initializing Container Support [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-99.scope [...] This output is unchanged by the patch I am proposing in this pull request. I probably should have included a note about this in the description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2793203752 From gziemski at openjdk.org Thu Apr 10 14:13:39 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 10 Apr 2025 14:13:39 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v11] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 10:02:29 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 24 test-cases added for full coverage of cases. Thank you for this work and your patience accommodating my feedback. LGTM (if there are any issues I am sure we can address them in follow-ups) ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2757009535 From gziemski at openjdk.org Thu Apr 10 15:24:37 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 10 Apr 2025 15:24:37 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v2] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:52:52 GMT, Afshin Zafari wrote: >> At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. >> This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. >> >> Two test-cases added and run. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > returns invalid SummaryDiff, instead of assert. Changes requested by gziemski (Reviewer). Looks good, just a couple minor feedback issues. src/hotspot/share/nmt/vmatree.hpp line 183: > 181: } > 182: } > 183: bool is_valid() const { How about more descriptive name, such as `is_non_free()` or `was_allocated()`, `was_touched()` something like that to mark that this was used, `valid` is too generic? test/hotspot/gtest/nmt/test_vmatree.cpp line 745: > 743: > 744: TEST_VM_F(NMTVMATreeTest, UncommmitReleasedRegion) { > 745: { I would also add this case (which is the one I used originally to find this issue): Tree tree; // 0.............................. // 0.......40----60........ VMATree::SummaryDiff diff = tree.uncommit_mapping(40, 20, rd2); EXPECT_FALSE(diff.is_valid())z ------------- PR Review: https://git.openjdk.org/jdk/pull/24572#pullrequestreview-2757241041 PR Comment: https://git.openjdk.org/jdk/pull/24572#issuecomment-2794214667 PR Review Comment: https://git.openjdk.org/jdk/pull/24572#discussion_r2037671164 PR Review Comment: https://git.openjdk.org/jdk/pull/24572#discussion_r2037659755 From iklam at openjdk.org Thu Apr 10 15:53:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Apr 2025 15:53:35 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Wed, 9 Apr 2025 16:43:39 GMT, Timofei Pushkin wrote: >> I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Djava.system.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders. >> >> For example: >> - Let C= be a class C named N defined by class loader L >> - Let AppL be the built-in system class loader and SysL be the user-provided system class loader >> - Let U be an unregistered class which extends a registered >> - Let SysL be able to load a registered when requested (i.e. SysL doesn't delegate when loading a class named S) >> - When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus will become a super of U instead of ? this is not correct >> >> This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U. >> >> This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends will not be handeled correctly ( will be used instead of ). >> >> So it looks like I have to revert this delegation-based approach and use the old way. I'll also write a test from the above example to see if I am correct first. > > I've realized that my example cannot be expressed in the current class list format since the format doesn't distinguish between and , only that S is not unregistered. The existing implementation will always use as will the new one. It feels like a flaw to me but it is not a flaw of this patch. Currently we have some restrictions if`-Djava.system.class.loader=` is specified - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286 - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886 I think we should extend this limitation further (in a separate issue) - At dump time, dump only boot classes (no platform, system or unregistered) - At run time, load only boot classes (no platform, system or unregistered) I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037729803 From iklam at openjdk.org Thu Apr 10 16:04:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Apr 2025 16:04:31 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Thu, 10 Apr 2025 15:50:56 GMT, Ioi Lam wrote: >> I've realized that my example cannot be expressed in the current class list format since the format doesn't distinguish between and , only that S is not unregistered. The existing implementation will always use as will the new one. It feels like a flaw to me but it is not a flaw of this patch. > > Currently we have some restrictions if`-Djava.system.class.loader=` is specified > > - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286 > - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886 > > I think we should extend this limitation further (in a separate issue) > > - At dump time, dump only boot classes (no platform, system or unregistered) > - At run time, load only boot classes (no platform, system or unregistered) > > I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) In the current JDK (with or without this patch), in your scenario, I think the name "S" will be printed twice with two different IDs. If a Child class named "C" is loaded by a custom loader, it will refer to one of the IDs. Depending on the order of loading, it might refer to the first or the second ID. During dump time, we will try to load this class twice, but both attempts will result in the same class (defined by the user-defined system class loader). When resolving the unregistered class, using either ID will give you the correct super class ... Anyway, this seems too fragile. I think we should fix [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating this patch. Or, maybe we can include the fixes of that bug in this PR as well (and then close that bug as a duplicate of this one). What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037756333 From iklam at openjdk.org Thu Apr 10 16:07:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Apr 2025 16:07:32 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 18:37:15 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Remove findClass, extend explanation comments test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53: > 51: out.shouldContain("unreg CustomLoadee"); > 52: } > 53: } For completeness, I think we should have a more complicated scenario: - load CustomLoadee in both the app loader and a custom loader - load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037764057 From coleenp at openjdk.org Thu Apr 10 16:24:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Apr 2025 16:24:52 GMT Subject: RFR: 8354234: Remove friends for ObjectMonitor Message-ID: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> Please review this somewhat trivial change to remove unneeded friends from the ObjectMonitor class. Two functions were made public for use with ObjectSynchronizer and avoid referencing fields directly from other places. Tested with tier1 sanity. ------------- Commit messages: - 8354234: Remove friends for ObjectMonitor Changes: https://git.openjdk.org/jdk/pull/24580/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24580&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354234 Stats: 9 lines in 2 files changed: 2 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24580.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24580/head:pull/24580 PR: https://git.openjdk.org/jdk/pull/24580 From aboldtch at openjdk.org Thu Apr 10 17:26:24 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 10 Apr 2025 17:26:24 GMT Subject: RFR: 8354234: Remove friends for ObjectMonitor In-Reply-To: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> References: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> Message-ID: On Thu, 10 Apr 2025 16:19:38 GMT, Coleen Phillimore wrote: > Please review this somewhat trivial change to remove unneeded friends from the ObjectMonitor class. Two functions were made public for use with ObjectSynchronizer and avoid referencing fields directly from other places. > Tested with tier1 sanity. lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24580#pullrequestreview-2757671822 From ccheung at openjdk.org Thu Apr 10 19:59:41 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 10 Apr 2025 19:59:41 GMT Subject: RFR: 8171508: Remove -Dsun.java.launcher.is_altjvm option [v5] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 08:16:27 GMT, Thomas Stuefe wrote: >>> Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? >> >> AIX has a different dll lookup mechanism, but otherwise these should be pretty much identical. Windows also only really differs in the lookup mechanism. Maybe new RFE to refactor these and share some code? > >> > Are the Posix variants all identical? If yes, can we move this to os::posix.cpp? If not, what are the differences? >> >> AIX has a different dll lookup mechanism, but otherwise these should be pretty much identical. Windows also only really differs in the lookup mechanism. Maybe new RFE to refactor these and share some code? > > Okay. The code could also be simpler if it were to use stringStream, spanned over the caller-provided buffer. No character counting and truncation handling needed then (but we would need to add truncation detection to stringStream, but that is really easy). Thanks @tstuefe, @dholmes-ora for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2795023245 From ccheung at openjdk.org Thu Apr 10 19:59:41 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 10 Apr 2025 19:59:41 GMT Subject: Integrated: 8171508: Remove -Dsun.java.launcher.is_altjvm option In-Reply-To: References: Message-ID: <8MeUl7rupWPFRYrCt0FEyEi_cbBwxeUIi1Hvq0D4Ckk=.95fa46fb-af8e-4eb7-9212-798841547fe6@github.com> On Sat, 29 Mar 2025 04:28:49 GMT, Calvin Cheung wrote: > The `-Dsun.java.launcher.is_altjvm` option is only used in the gtest launcher and has no relationship with the similarly named `-XXaltjvm` option. The gtest launcher also sets the `-XX:+ExecutingUnitTests` option. This RFE involves removing the `-Dsun.java.launcher.is_altjvm` option, capturing the `-XX:+ExecutingUnitTests` option in Arguments::process_sun_java_launcher_properties() so that the os::jvm_path() can check if the option is set before using JAVA_HOME setting. > > Passed tiers 1 - 3 testing. This pull request has now been integrated. Changeset: 7680f70a Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/7680f70ad647da741dd6cd9603a53f7923f95667 Stats: 224 lines in 7 files changed: 29 ins; 114 del; 81 mod 8171508: Remove -Dsun.java.launcher.is_altjvm option Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/24310 From duke at openjdk.org Thu Apr 10 22:12:35 2025 From: duke at openjdk.org (duke) Date: Thu, 10 Apr 2025 22:12:35 GMT Subject: Withdrawn: 8346661: Add a register print helper method and unify register printing In-Reply-To: References: Message-ID: <4zNgeYH3ASK4_kRQ7agYoZzqHZc2lwjl5vl54F-mOhY=.438dfd35-ce37-494d-8c73-7e62b0bf501a@github.com> On Mon, 30 Dec 2024 08:27:56 GMT, Matthias Baesken wrote: > For printing registers we can add a little helper method to shorten the coding. Also some of the register printing code can use loops. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22894 From dholmes at openjdk.org Fri Apr 11 02:09:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Apr 2025 02:09:34 GMT Subject: RFR: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" Apologies, I completely misunderstood the problem here and thought that the value coming from the system had the extra newline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24533#issuecomment-2795650073 From duke at openjdk.org Fri Apr 11 02:09:35 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Fri, 11 Apr 2025 02:09:35 GMT Subject: Integrated: 8354057: Odd debug output in -Xlog:os+container=debug on certain systems In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 02:05:15 GMT, Thomas Fitzsimmons wrote: > The issue was a trailing newline in a message argument to: > > > log_debug(os, container)(...) > > > `log_debug` implicitly appends a newline to the message, so the extra newline resulted in empty lines in the trace output. > > The old vs new output on my `Alpine Linux v3.21` virtual machine is: > > > --- tt-old-alpine-legacy.txt 2025-04-08 21:49:31.847415499 -0400 > +++ tt-new-alpine-legacy.txt 2025-04-08 21:48:51.486322068 -0400 > @@ -1,10 +1,8 @@ > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.000s][debug][os,container] controller cpuset is not enabled > -[ ] > [0.000s][debug][os,container] controller memory is not enabled > -[ ] > [0.000s][debug][os,container] One or more required controllers disabled at kernel level. > openjdk version "25-internal" 2025-09-16 > -OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk-old) > -OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk-old, mixed mode) > +OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.fitzsim.jdk) > +OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.fitzsim.jdk, mixed mode) > > > Regression-tested with: > > > make exploded-test TEST="test/hotspot/jtreg/containers test/jdk/jdk/internal/platform/cgroup gtest:cgroupTest*" This pull request has now been integrated. Changeset: 4478a99e Author: Thomas Fitzsimmons Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/4478a99e3111798c2e461c7e769a69672f187a6a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8354057: Odd debug output in -Xlog:os+container=debug on certain systems Reviewed-by: sgehwolf, asmehra, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24533 From dholmes at openjdk.org Fri Apr 11 04:43:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Apr 2025 04:43:27 GMT Subject: RFR: 8354234: Remove friends for ObjectMonitor In-Reply-To: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> References: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> Message-ID: On Thu, 10 Apr 2025 16:19:38 GMT, Coleen Phillimore wrote: > Please review this somewhat trivial change to remove unneeded friends from the ObjectMonitor class. Two functions were made public for use with ObjectSynchronizer and avoid referencing fields directly from other places. > Tested with tier1 sanity. Cleaning up unused friend declarations is good. Personally I prefer the friend relationship to making API's public. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24580#pullrequestreview-2759125460 From msterner at openjdk.mxy.se Fri Apr 11 04:59:44 2025 From: msterner at openjdk.mxy.se (Mikael Sterner) Date: Fri, 11 Apr 2025 06:59:44 +0200 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? Message-ID: Hi, During migration of a desktop software from Java 11 to Java 21 we started seeing the libjsig deprecation warnings. That's fine and appreciated as a heads-up, and I also notice that some nice changes to the message logic have been done for Java 25. However, tracing what triggered our warnings, I wonder if you think it could make sense to be lenient about calls to deprecated signal() method that just want to ignore a signal with SIG_IGN, in particular SIGPIPE? This pattern seems to be used in several Gnome libraries: - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkmain.c?ref_type=heads#L555 - https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gsocket.c?ref_type=heads#L967 - https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/client/gdaemonvfs.c#L304 Or would it be better to report such calls as deficiencies in these libraries, with the libjsig warnings as evidence? Yours, Mikael Sterner From thomas.stuefe at gmail.com Fri Apr 11 05:55:15 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Apr 2025 07:55:15 +0200 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: References: Message-ID: Hi Mikael, I think that makes sense. I actually missed that we deprecated signal(). Seeing that libjsig interfaces with third-party code that neither we nor typically our customers have control over, I am surprised we did that. Cheers, Thomas On Fri, Apr 11, 2025 at 7:01?AM Mikael Sterner wrote: > Hi, > > During migration of a desktop software from Java 11 to > Java 21 we started seeing the libjsig deprecation warnings. > That's fine and appreciated as a heads-up, and I also notice > that some nice changes to the message logic have been done > for Java 25. > > However, tracing what triggered our warnings, I wonder if you > think it could make sense to be lenient about calls to deprecated > signal() method that just want to ignore a signal with SIG_IGN, > in particular SIGPIPE? This pattern seems to be used in several > Gnome libraries: > > - > https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkmain.c?ref_type=heads#L555 > - > https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gsocket.c?ref_type=heads#L967 > - > https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/client/gdaemonvfs.c#L304 > > Or would it be better to report such calls as deficiencies in > these libraries, with the libjsig warnings as evidence? > > Yours, > Mikael Sterner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azafari at openjdk.org Fri Apr 11 07:31:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 11 Apr 2025 07:31:04 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v3] In-Reply-To: References: Message-ID: <8VXzmnneNE9mAJphnoDfyn36jlm9NMuY_-PcUbMh5Ug=.0633cdf3-910c-4d1c-b71c-c4b9edfdae7d@github.com> > At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. > This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. > > Two test-cases added and run. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: a corner case fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24572/files - new: https://git.openjdk.org/jdk/pull/24572/files/7538792c..42a7ce95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=01-02 Stats: 32 lines in 2 files changed: 21 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24572/head:pull/24572 PR: https://git.openjdk.org/jdk/pull/24572 From ktakakuri at openjdk.org Fri Apr 11 08:14:35 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Fri, 11 Apr 2025 08:14:35 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v4] In-Reply-To: References: Message-ID: <8ZuWdfemhkK5XnhAKck2qADFzI_SCxOfGmHoooYJ5N8=.211d83c5-f82a-432d-bd04-c03c1a92bac8@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/890f0135..d3fc95a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=02-03 Stats: 11 lines in 1 file changed: 10 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 jsjolen at openjdk.org Fri Apr 11 08:18:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 11 Apr 2025 08:18:26 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> References: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> Message-ID: On Thu, 10 Apr 2025 07:25:01 GMT, David Holmes wrote: > Can you elaborate on what the issue with BufferUpdater was. I admit I'm not clear what it was doing. The `BufferUpdater` swaps the pointers `Buffer* _buffer` and `Buffer* _buffer_staging` to new `Buffer` objects while holding a lock, but this lock isn't held by the async log writer when reading `_buffer_staging` for writing. This leads to a data race, which is probably the source of this bug. That this race manifests as a bug now is probably just an accident, there's been changes to this code so the timings are different, I guess. `BufferUpdater` is only used for tests and only to make the `Buffer`s very small, so that we only have to write 1KiB of data to a file in order to detect dropped messages occurring. Now we need to write 100KiB, which I think is acceptable. Since `BufferUpdater` is only being used for tests, I felt it was easiest just to get rid of the `BufferUpdater` without figuring out exactly what happens during the data race which in turn manifests as this bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2796179191 From azafari at openjdk.org Fri Apr 11 08:19:00 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 11 Apr 2025 08:19:00 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v38] 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 with a new target base due to a merge or a rebase. The pull request now contains 83 commits: - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - more reviews. - review comments applied - test cases for doing reserve or commit the same region twice. - style, some cleanup, VMT and regionsTree circular dep resolved - removed UseFlagInPlace test. - reviews applied. - test file got back, fixed coding style - once more. - ... and 73 more: https://git.openjdk.org/jdk/compare/cf0308b2...95198a8e ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=37 Stats: 1446 lines in 26 files changed: 582 ins; 544 del; 320 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 Fri Apr 11 08:29:33 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 11 Apr 2025 08:29:33 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v11] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 10:02:29 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 24 test-cases added for full coverage of cases. Hi, Are we skipping any cases where an operation is done over multiple regions? If we have: // Post: .........0********20---------25********50--------80********100......... // mtNone mtTest mtTest mtTest mtTest mtTest mtNone // Rl C Rs C Rs C Rl // - si_1 si_3 si_1 si_1 si_1 - // - si_2 - si_2 - si_2 - And we uncommit `[0, 100)`, then what is the result? Are we going to ignore these cases for now? test/hotspot/gtest/nmt/test_vmatree.cpp line 792: > 790: } > 791: > 792: snprintf(for_this_node, sizeof(for_this_node), "test at line: %d, for node: %d", line_no, et.nodes[i]); Here, you can use a `stringStream` to print, and then use `.base()` to access the underlying string. That means you have no limit on the length of the line. test/hotspot/gtest/nmt/test_vmatree.cpp line 876: > 874: check_tree(tree, et2, __LINE__); > 875: > 876: tree.commit_mapping(0, 20, call_stack_2, true); // commit at the begin of the region beginning ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2759420744 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2038974520 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2039044930 From ktakakuri at openjdk.org Fri Apr 11 09:13:41 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Fri, 11 Apr 2025 09:13:41 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v3] In-Reply-To: <9D9L7xLzGIJoVg7Q1vd6Xe-sbW19EbGnZ6BDOd8XCBk=.7864f057-2a3b-4fe0-b8c5-943c93d64ee9@github.com> References: <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com> <9D9L7xLzGIJoVg7Q1vd6Xe-sbW19EbGnZ6BDOd8XCBk=.7864f057-2a3b-4fe0-b8c5-943c93d64ee9@github.com> Message-ID: On Thu, 27 Mar 2025 00:42:52 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 67: >> >>> 65: List command = new ArrayList<>(); >>> 66: // Force language to English before running systeminfo to get the OS version >>> 67: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&")); >> >> Not sure about hardcoding C:\Windows in tests as Windows could be installed on a different volume. Don't you need to use the value of %SystemRoot% to the directory? > > I thought it unfortunate that a path needed to be specified, but there is a precedent for assuming` C:\Windows`: > > ./jdk/java/lang/ProcessHandle/ProcessUtil.java: > return Platform.isWindows() && p.info().command().orElse("").endsWith("C:\\Windows\\System32\\conhost.exe"); > > though a more general approach would be similar to `./jdk/java/lang/RuntimeTests/exec/WinCommand.java`: > > File systemRoot = > getenv("SystemRoot") != null ? new File(getenv("SystemRoot")) : > getenv("WINDIR") != null ? new File(getenv ("WINDIR")) : > null; > if (systemRoot == null || ! systemRoot.isDirectory()) > return; // Not Windows as we know it > > String systemDirW = new File(systemRoot, "System32").getPath(); > > > I was also reminded that testing under non-US-English locales is not really supported: > https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#windows >> The recommended and supported way of building the JDK on Windows is to set both the system locale and the user locale to US English. The system setting can be changed by going to the Control Panel, choosing "Regional Settings" -> "Administrative" and then pressing on the "Change System Locale" button. >> >> Since this is annoying for users who prefer another locale, we strive to get the building and testing to work on other locales as well. This is on a "best effort" level, so beware! You might get odd results in both building and testing. If you do, remember that locales other than US English are not supported nor recommended. >> >> It is also imperative to install the US English language pack in Visual Studio. For details, see [Microsoft Visual Studio](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#microsoft-visual-studio). Thank you for your review. I changed it to use System.getenv(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2039140561 From coleenp at openjdk.org Fri Apr 11 11:06:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Apr 2025 11:06:40 GMT Subject: RFR: 8354234: Remove friends for ObjectMonitor In-Reply-To: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> References: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> Message-ID: On Thu, 10 Apr 2025 16:19:38 GMT, Coleen Phillimore wrote: > Please review this somewhat trivial change to remove unneeded friends from the ObjectMonitor class. Two functions were made public for use with ObjectSynchronizer and avoid referencing fields directly from other places. > Tested with tier1 sanity. Thanks for reviewing, Axel and David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24580#issuecomment-2796581821 From coleenp at openjdk.org Fri Apr 11 11:06:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Apr 2025 11:06:40 GMT Subject: Integrated: 8354234: Remove friends for ObjectMonitor In-Reply-To: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> References: <44EAH09Mh6TjyCLm7ZiGFTpGn2RQfTT5P4gT7UW99EM=.468ebb88-cd68-48d6-be31-e70721bd97ef@github.com> Message-ID: On Thu, 10 Apr 2025 16:19:38 GMT, Coleen Phillimore wrote: > Please review this somewhat trivial change to remove unneeded friends from the ObjectMonitor class. Two functions were made public for use with ObjectSynchronizer and avoid referencing fields directly from other places. > Tested with tier1 sanity. This pull request has now been integrated. Changeset: 36069f6e Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/36069f6efac4fd02393d28f190ab2ab92b113fd3 Stats: 9 lines in 2 files changed: 2 ins; 5 del; 2 mod 8354234: Remove friends for ObjectMonitor Reviewed-by: aboldtch, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24580 From azafari at openjdk.org Fri Apr 11 11:48:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 11 Apr 2025 11:48:37 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v39] 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: fixes after merge with master. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/95198a8e..9010b68f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=37-38 Stats: 19 lines in 5 files changed: 0 ins; 5 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 azafari at openjdk.org Fri Apr 11 12:45:03 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 11 Apr 2025 12:45:03 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v4] In-Reply-To: References: Message-ID: > At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. > This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. > > Two test-cases added and run. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: review comments applied ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24572/files - new: https://git.openjdk.org/jdk/pull/24572/files/42a7ce95..f25d405e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24572&range=02-03 Stats: 16 lines in 3 files changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24572/head:pull/24572 PR: https://git.openjdk.org/jdk/pull/24572 From azafari at openjdk.org Fri Apr 11 12:45:03 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 11 Apr 2025 12:45:03 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v2] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 15:19:54 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> returns invalid SummaryDiff, instead of assert. > > src/hotspot/share/nmt/vmatree.hpp line 183: > >> 181: } >> 182: } >> 183: bool is_valid() const { > > How about more descriptive name, such as `is_non_free()` or `was_allocated()`, `was_touched()` something like that to mark that this was used, `valid` is too generic? Renamed to `has_error()`. > test/hotspot/gtest/nmt/test_vmatree.cpp line 745: > >> 743: >> 744: TEST_VM_F(NMTVMATreeTest, UncommmitReleasedRegion) { >> 745: { > > I would also add this case (which is the one I used originally to find this issue): > > > Tree tree; > // 0.............................. > // 0.......40----60............... > VMATree::SummaryDiff diff = tree.uncommit_mapping(40, 20, rd2); > EXPECT_FALSE(diff.is_valid()) Thanks for reminding. Handling this case is also added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24572#discussion_r2039493170 PR Review Comment: https://git.openjdk.org/jdk/pull/24572#discussion_r2039492498 From stuefe at openjdk.org Fri Apr 11 15:01:11 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 11 Apr 2025 15:01:11 GMT Subject: RFR: 8350753: Deprecate UseCompressedClassPointers [v7] In-Reply-To: References: Message-ID: > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers - fix whitespaces - Test fix for 32-bit - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers - move line - move line - Merge branch 'master' into JDK-8350753-Deprecate-UseCompressedClassPointers - Merge branch 'openjdk:master' into JDK-8350753-Deprecate-UseCompressedClassPointers - not on 32-bit - Deprecate UseCompressedClassPointers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24436/files - new: https://git.openjdk.org/jdk/pull/24436/files/61cf5b19..5d7e9cbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24436&range=05-06 Stats: 38911 lines in 646 files changed: 18873 ins; 16899 del; 3139 mod Patch: https://git.openjdk.org/jdk/pull/24436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24436/head:pull/24436 PR: https://git.openjdk.org/jdk/pull/24436 From coleenp at openjdk.org Fri Apr 11 19:42:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Apr 2025 19:42:44 GMT Subject: RFR: 8354446: [BACKOUT] Remove friends for ObjectMonitor Message-ID: This reverts commit 36069f6efac4fd02393d28f190ab2ab92b113fd3. I don't know why we can't call ObjectMonitor::recursions() rather than updating it directly. Rerunning tier3. ------------- Commit messages: - Revert "8354234: Remove friends for ObjectMonitor" Changes: https://git.openjdk.org/jdk/pull/24599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354446 Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24599/head:pull/24599 PR: https://git.openjdk.org/jdk/pull/24599 From pchilanomate at openjdk.org Fri Apr 11 19:55:28 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 11 Apr 2025 19:55:28 GMT Subject: RFR: 8354446: [BACKOUT] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: <3Zb6Y-HzNHRJBCrHHMbdfBs8w_zsLZ-PkooE317fq7U=.258307aa-585a-456d-bc36-4f336d83b632@github.com> On Fri, 11 Apr 2025 19:36:39 GMT, Coleen Phillimore wrote: > This reverts commit 36069f6efac4fd02393d28f190ab2ab92b113fd3. > > I don't know why we can't call ObjectMonitor::recursions() rather than updating it directly. > Rerunning tier3. The problem is that `set_recursions()` asserts _recursions is 0. Before 8354234 it was only called in contexts were that was true. Using `set_recursions()` for individual increments will fail if _recursions is already > 0. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24599#pullrequestreview-2761454940 From coleenp at openjdk.org Fri Apr 11 20:02:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Apr 2025 20:02:31 GMT Subject: RFR: 8354446: [BACKOUT] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 19:36:39 GMT, Coleen Phillimore wrote: > This reverts commit 36069f6efac4fd02393d28f190ab2ab92b113fd3. > > I don't know why we can't call ObjectMonitor::recursions() rather than updating it directly. > Rerunning tier3. Thanks Patricio. I almost wrote an increment_recursions() for this purpose but I thought set_recursions was already there for that purpose. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24599#issuecomment-2797906240 From coleenp at openjdk.org Fri Apr 11 20:02:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Apr 2025 20:02:31 GMT Subject: Integrated: 8354446: [BACKOUT] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 19:36:39 GMT, Coleen Phillimore wrote: > This reverts commit 36069f6efac4fd02393d28f190ab2ab92b113fd3. > > I don't know why we can't call ObjectMonitor::recursions() rather than updating it directly. > Rerunning tier3. This pull request has now been integrated. Changeset: d14e84c0 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/d14e84c03b681594e84aef28107dce7b5198893b Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod 8354446: [BACKOUT] Remove friends for ObjectMonitor Reviewed-by: pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/24599 From pchilanomate at openjdk.org Fri Apr 11 21:17:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 11 Apr 2025 21:17:29 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v9] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 08:48:02 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: added a couple of comments with important clarifications Glad to see this one resolved after all, thanks! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2761583781 From duke at openjdk.org Fri Apr 11 22:29:31 2025 From: duke at openjdk.org (Rui Li) Date: Fri, 11 Apr 2025 22:29:31 GMT Subject: RFR: 8352569: NMT: mmap limits [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:56 GMT, Rui Li wrote: >> ### Notes >> >> With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. >> >> It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. >> >> >> ### Usages >> A new jvm arg `-XX:MmapLimit` is added. Usages: >> - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` >> - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. >> - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) >> >> Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): >> >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 >> # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) >> # >> # JRE version: (25.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 >> # >> # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 >> # >> # An error report file with more information is saved as: >> # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log >> >> >> Sample error messages for oom: >> >> x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:Na... > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Add headers Thanks all. I'll close the pr and give a note in the JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24343#issuecomment-2798111569 From duke at openjdk.org Fri Apr 11 22:29:31 2025 From: duke at openjdk.org (Rui Li) Date: Fri, 11 Apr 2025 22:29:31 GMT Subject: Withdrawn: 8352569: NMT: mmap limits In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 01:57:59 GMT, Rui Li wrote: > ### Notes > > With [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878), we have a way to limit the native memory size created by malloc. > > It'll be nice to have a counterpart for mmap. E.g., [JDK-8350860](https://bugs.openjdk.org/browse/JDK-8350860) will have a good use of mmap limit jvm arg. > > > ### Usages > A new jvm arg `-XX:MmapLimit` is added. Usages: > - Impose a global limit to mem allocated by mmap() call: `-XX:MmapLimit=`. e.g.: `-XX:MmapLimit=500m` > - Or, impose an nmt category to mem allocated by mmap call: `-XX:MmapLimit=:[,category=size]`. e.g.: `-XX:MmapLimit=gc:100m`. Notice that, not every category uses mmap. E.g.: compiler category. In this case, it would behave the same as the mem limit has not been exceeded. > - About failure mode: by default, when the limit is exceeded, the app exits in fatal mode. If we want to mimic os oom, we can do it by appending failure mode like `-XX:MmapLimit=:oom` or `-XX:MmapLimit=:oom`. e.g.: `-XX:MmapLimit=500m:oom` or `-XX:MmapLimit=gc:100m:oom`. (`-XX:MmapLimit=500m:fatal` is equivalent to `-XX:MmapLimit=500m` since `fatal` is the default) > > Sample error messages for fatal (`fatal` mode is default and can be omitted in the jvm arg): > > > x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k -version > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/workplace/ruiamzn/github/jdk/src/hotspot/share/nmt/nMemoryLimitPrinter.cpp:77), pid=18248, tid=18249 > # fatal error: MmapLimit: reached category "mtGC" limit (triggering allocation size: 836K, allocated so far: 836K, limit: 10240B) > # > # JRE version: (25.0) (fastdebug build ) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.ruiamzn.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x153a4a2] NMemoryLimitPrinter::category_limit_reached(MemTag, unsigned long, unsigned long, nMemlimit const*, NMemType)+0x182 > # > # Core dump will be written. Default location: /workplace/ruiamzn/github/jdk/core.18248 > # > # An error report file with more information is saved as: > # /workplace/ruiamzn/github/jdk/hs_err_pid18248.log > > > Sample error messages for oom: > > x64 (8352569) % /workplace/ruiamzn/github/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:NativeMemoryTracking=summary -XX:MmapLimit=gc:10k:oom -version > [0.057s][warn... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24343 From sspitsyn at openjdk.org Fri Apr 11 23:20:35 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Apr 2025 23:20:35 GMT Subject: RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v9] In-Reply-To: References: Message-ID: <-5OKhD3yfaH4ZN7M9Piok7iV-FpXBfiY5ZcovhLFTX8=.d79e8e23-f8d8-4215-840d-98f60d8686e0@github.com> On Wed, 9 Apr 2025 08:48:02 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: added a couple of comments with important clarifications David and Patricio, hank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2798194794 From stuefe at openjdk.org Sat Apr 12 06:01:38 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Apr 2025 06:01:38 GMT Subject: Integrated: 8350753: Deprecate UseCompressedClassPointers In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 06:09:16 GMT, Thomas Stuefe wrote: > Deprecates UseCompressedClassPointers. For the lengthy description of why and how we do this, please read the lengthy [CSR](https://bugs.openjdk.org/browse/JDK-8350754). > > Testing: > > I ran all jtreg tests manually on Linux-x64 that used the flag in some form (55 tests) to ensure they don't trip over the added deprecation output. > > I also tested the JVM on arm32 to verify that UseCompressedClassPointers had never been available there, and that we don't start printing a confusing deprecation message now. This pull request has now been integrated. Changeset: 034c0d4d Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/034c0d4de5739bd20d734471b2d9065a0ca387bd Stats: 13 lines in 3 files changed: 12 ins; 0 del; 1 mod 8350753: Deprecate UseCompressedClassPointers Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24436 From sspitsyn at openjdk.org Sat Apr 12 07:24:30 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 12 Apr 2025 07:24:30 GMT Subject: Integrated: 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 `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 This pull request has now been integrated. Changeset: 04ad59de Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/04ad59de768b69b4e897a93f46efad9cc25737ad Stats: 13 lines in 2 files changed: 10 ins; 0 del; 3 mod 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/23490 From azafari at openjdk.org Sat Apr 12 23:06:46 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 12 Apr 2025 23:06:46 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v12] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 10 cases added for overlapping with multiple regions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/d5197463..4e85b84e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=10-11 Stats: 379 lines in 1 file changed: 295 ins; 1 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Sat Apr 12 23:06:46 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 12 Apr 2025 23:06:46 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v11] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 08:26:41 GMT, Johan Sj?len wrote: > Hi, > > Are we skipping any cases where an operation is done over multiple regions? > > If we have: > > ``` > // Post: .........0********20---------25********50--------80********100......... > // mtNone mtTest mtTest mtTest mtTest mtTest mtNone > // Rl C Rs C Rs C Rl > // - si_1 si_3 si_1 si_1 si_1 - > // - si_2 - si_2 - si_2 - > ``` > > And we uncommit `[0, 100)`, then what is the result? > > Are we going to ignore these cases for now? 10 new test-cases are added for covering these. > test/hotspot/gtest/nmt/test_vmatree.cpp line 792: > >> 790: } >> 791: >> 792: snprintf(for_this_node, sizeof(for_this_node), "test at line: %d, for node: %d", line_no, et.nodes[i]); > > Here, you can use a `stringStream` to print, and then use `.base()` to access the underlying string. That means you have no limit on the length of the line. Done. > test/hotspot/gtest/nmt/test_vmatree.cpp line 876: > >> 874: check_tree(tree, et2, __LINE__); >> 875: >> 876: tree.commit_mapping(0, 20, call_stack_2, true); // commit at the begin of the region > > beginning Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2799070738 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2040757858 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2040757881 From azafari at openjdk.org Sat Apr 12 23:23:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sat, 12 Apr 2025 23:23:30 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v12] In-Reply-To: References: Message-ID: <88uOgxH_YTNC-igX7gV0FtEZws2RjNWmgD-zK00LEEk=.b24cbf50-f506-414c-ba13-c84b8c945fdf@github.com> On Sat, 12 Apr 2025 23:06:46 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 10 cases added for overlapping with multiple regions There are test cases that use `ok_to_run` for being skipped. These cases fail and maybe new RFE to be filed for them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2799083079 From dholmes at openjdk.org Sun Apr 13 22:54:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 13 Apr 2025 22:54:33 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> Message-ID: On Fri, 11 Apr 2025 08:15:31 GMT, Johan Sj?len wrote: > this lock isn't held by the async log writer when reading _buffer_staging for writing. Where is the code that does this reading? The writer is supposed to hold the producer and consumer locks when writing, and the BufferUpdater is protected by the consumer lock. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2800163961 From david.holmes at oracle.com Sun Apr 13 23:40:51 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Apr 2025 09:40:51 +1000 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: References: Message-ID: <505b8ddd-ba62-4903-b00e-cef548b3e4de@oracle.com> On 11/04/2025 3:55 pm, Thomas St?fe wrote: > Hi Mikael, > > I think that makes sense. > > I actually missed that we deprecated signal(). No you didn't :) You've just forgotten: https://bugs.openjdk.org/browse/JDK-8257572 Cheers, David ----- > Seeing that libjsig > interfaces with third-party code that neither we nor typically our > customers have control over, I am surprised we did that. > > Cheers, Thomas > > > On Fri, Apr 11, 2025 at 7:01?AM Mikael Sterner > wrote: > > Hi, > > During migration of a desktop software from Java 11 to > Java 21 we started seeing the libjsig deprecation warnings. > That's fine and appreciated as a heads-up, and I also notice > that some nice changes to the message logic have been done > for Java 25. > > However, tracing what triggered our warnings, I wonder if you > think it could make sense to be lenient about calls to deprecated > signal() method that just want to ignore a signal with SIG_IGN, > in particular SIGPIPE? This pattern seems to be used in several > Gnome libraries: > > ?- https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkmain.c? > ref_type=heads#L555 gtk/gtkmain.c?ref_type=heads#L555> > ?- https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gsocket.c? > ref_type=heads#L967 main/gio/gsocket.c?ref_type=heads#L967> > ?- https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/client/ > gdaemonvfs.c#L304 master/client/gdaemonvfs.c#L304> > > Or would it be better to report such calls as deficiencies in > these libraries, with the libjsig warnings as evidence? > > Yours, > Mikael Sterner > From david.holmes at oracle.com Mon Apr 14 03:20:04 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Apr 2025 13:20:04 +1000 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: References: Message-ID: Hi Mikael, On 11/04/2025 2:59 pm, Mikael Sterner wrote: > Hi, > > During migration of a desktop software from Java 11 to > Java 21 we started seeing the libjsig deprecation warnings. > That's fine and appreciated as a heads-up, and I also notice > that some nice changes to the message logic have been done > for Java 25. > > However, tracing what triggered our warnings, I wonder if you > think it could make sense to be lenient about calls to deprecated > signal() method that just want to ignore a signal with SIG_IGN, > in particular SIGPIPE? I have been trying to think of a rationale that would justify this leniency for this case, but I'm struggling to formulate one. The warning is about the use of the API not about how the API is used (i.e. the given signal and the way it is to be handled does not come into it). Would it help in your case if there was a way to disable the warning via a command-line flag? This has been requested in the past but we haven't needed to go down that path due to other adjustments (and sometimes it won't help as control of the command-line is problematic). Just to get a clearer picture here, the fact you are using libjsig indicates there are other signals that are actually handled and which you need to be chained - is that correct? > This pattern seems to be used in several > Gnome libraries: > > - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkmain.c?ref_type=heads#L555 > - https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gsocket.c?ref_type=heads#L967 > - https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/client/gdaemonvfs.c#L304 > > Or would it be better to report such calls as deficiencies in > these libraries, with the libjsig warnings as evidence? The "evidence" would be the specification for signal on Linux: https://man7.org/linux/man-pages/man2/signal.2.html WARNING: the behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Cheers, David Holmes > > Yours, > Mikael Sterner From thomas.stuefe at gmail.com Mon Apr 14 05:48:45 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 14 Apr 2025 07:48:45 +0200 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: <505b8ddd-ba62-4903-b00e-cef548b3e4de@oracle.com> References: <505b8ddd-ba62-4903-b00e-cef548b3e4de@oracle.com> Message-ID: On Mon, Apr 14, 2025 at 1:41?AM David Holmes wrote: > On 11/04/2025 3:55 pm, Thomas St?fe wrote: > > Hi Mikael, > > > > I think that makes sense. > > > > I actually missed that we deprecated signal(). > > No you didn't :) You've just forgotten: > > https://bugs.openjdk.org/browse/JDK-8257572 > > :-D > Cheers, > David > ----- > > > > > Seeing that libjsig > > interfaces with third-party code that neither we nor typically our > > customers have control over, I am surprised we did that. > > > > Cheers, Thomas > > > > > > On Fri, Apr 11, 2025 at 7:01?AM Mikael Sterner > > wrote: > > > > Hi, > > > > During migration of a desktop software from Java 11 to > > Java 21 we started seeing the libjsig deprecation warnings. > > That's fine and appreciated as a heads-up, and I also notice > > that some nice changes to the message logic have been done > > for Java 25. > > > > However, tracing what triggered our warnings, I wonder if you > > think it could make sense to be lenient about calls to deprecated > > signal() method that just want to ignore a signal with SIG_IGN, > > in particular SIGPIPE? This pattern seems to be used in several > > Gnome libraries: > > > > - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkmain.c? > > ref_type=heads#L555 > gtk/gtkmain.c?ref_type=heads#L555> > > - https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gsocket.c? > > ref_type=heads#L967 > main/gio/gsocket.c?ref_type=heads#L967> > > - https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/client/ > > gdaemonvfs.c#L304 > master/client/gdaemonvfs.c#L304> > > > > Or would it be better to report such calls as deficiencies in > > these libraries, with the libjsig warnings as evidence? > > > > Yours, > > Mikael Sterner > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msterner at openjdk.mxy.se Mon Apr 14 07:06:44 2025 From: msterner at openjdk.mxy.se (Mikael Sterner) Date: Mon, 14 Apr 2025 09:06:44 +0200 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: References: Message-ID: On Mon, Apr 14, 2025, at 05:20, David Holmes wrote: > On 11/04/2025 2:59 pm, Mikael Sterner wrote: >> However, tracing what triggered our warnings, I wonder if you >> think it could make sense to be lenient about calls to deprecated >> signal() method that just want to ignore a signal with SIG_IGN, >> in particular SIGPIPE? > > I have been trying to think of a rationale that would justify this > leniency for this case, but I'm struggling to formulate one. The warning > is about the use of the API not about how the API is used (i.e. the > given signal and the way it is to be handled does not come into it). > > Would it help in your case if there was a way to disable the warning via > a command-line flag? This has been requested in the past but we haven't > needed to go down that path due to other adjustments (and sometimes it > won't help as control of the command-line is problematic). It would be awesome if OpenJDK had a policy of always allowing application developers to disable deprecation warnings on the command line.* But in this case I guess it also depends if you ever intend to make programs calling signal() crash when libjsig is loaded, or if it will stay a warning forever? > Just to get a clearer picture here, the fact you are using libjsig > indicates there are other signals that are actually handled and which > you need to be chained - is that correct? Yes, we need to handle signals raised by other third-party libraries, but there we have more control over which methods to use. Possibly there are also other third-party libraries calling signal() with the intent of actually catching signals, that I haven't yet noticed (since the warning is only given for the first call). I think that some native libraries we use, we basically have to pamper to believe they are running in a single-threaded program. On a similar topic, I was happy to see JDK-8346381 to fix the signal chaining on modern macOS versions. Just to let you know that these facilities are being used in the wild. >> Or would it be better to report such calls as deficiencies in >> these libraries, with the libjsig warnings as evidence? > > The "evidence" would be the specification for signal on Linux: > > https://man7.org/linux/man-pages/man2/signal.2.html > > WARNING: the behavior of signal() varies across UNIX versions, and > has also varied historically across different versions of Linux. > Avoid its use: use sigaction(2) instead. Thanks, that would be a good reference to use. Yours, Mikael Sterner * Looking at you, JEP 411: https://mail.openjdk.org/pipermail/security-dev/2021-May/026200.html From david.holmes at oracle.com Mon Apr 14 09:06:01 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Apr 2025 19:06:01 +1000 Subject: libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)? In-Reply-To: References: Message-ID: <23ec6222-dee5-456e-a44f-fc150ee7eff7@oracle.com> On 14/04/2025 5:06 pm, Mikael Sterner wrote: > On Mon, Apr 14, 2025, at 05:20, David Holmes wrote: >> On 11/04/2025 2:59 pm, Mikael Sterner wrote: >>> However, tracing what triggered our warnings, I wonder if you >>> think it could make sense to be lenient about calls to deprecated >>> signal() method that just want to ignore a signal with SIG_IGN, >>> in particular SIGPIPE? >> >> I have been trying to think of a rationale that would justify this >> leniency for this case, but I'm struggling to formulate one. The warning >> is about the use of the API not about how the API is used (i.e. the >> given signal and the way it is to be handled does not come into it). >> >> Would it help in your case if there was a way to disable the warning via >> a command-line flag? This has been requested in the past but we haven't >> needed to go down that path due to other adjustments (and sometimes it >> won't help as control of the command-line is problematic). > > It would be awesome if OpenJDK had a policy of always allowing > application developers to disable deprecation warnings on the > command line.* The problem there is that we don't have a common mechanism for such warnings. Hotspot, for example, uses Unified Logging, so you do have control. JDK/Java-level deprecation warnings are a whole other matter - as you know. Then we have libjsig which is a standalone set of C functions that just use fprintf for the warning - so any mechanism to disable it is made complicated by the need to somehow communicate a command-line request to the jsig code. It can be done but introduces additional coupling. > But in this case I guess it also depends if you > ever intend to make programs calling signal() crash when libjsig > is loaded, or if it will stay a warning forever? At this stage it is likely to stay a warning for a very long time. We were expecting the OS (or glibc I guess) to eventually remove these functions, but that doesn't seem to be happening any time soon. Though the compilers do flag them as deprecated (if you have that warning enabled). If we were to remove support for them it would "simply" mean that we would not intercept them and thus signal chaining would be broken. What would happen then depends on the signal of course. Though potentially we could convert signal() calls to sigaction() if we needed to keep old code working. >> Just to get a clearer picture here, the fact you are using libjsig >> indicates there are other signals that are actually handled and which >> you need to be chained - is that correct? > > Yes, we need to handle signals raised by other third-party > libraries, but there we have more control over which methods > to use. > > Possibly there are also other third-party libraries calling > signal() with the intent of actually catching signals, that I > haven't yet noticed (since the warning is only given for the > first call). > > I think that some native libraries we use, we basically have to > pamper to believe they are running in a single-threaded program. Ouch. > On a similar topic, I was happy to see JDK-8346381 to fix the > signal chaining on modern macOS versions. Just to let you know > that these facilities are being used in the wild. That is good information to have. Occasionally someone will ask "do we still need all this old signal stuff?". I will keep thinking about this, and see if anyone else has anything to contribute. Cheers, David > >>> Or would it be better to report such calls as deficiencies in >>> these libraries, with the libjsig warnings as evidence? >> >> The "evidence" would be the specification for signal on Linux: >> >> https://man7.org/linux/man-pages/man2/signal.2.html >> >> WARNING: the behavior of signal() varies across UNIX versions, and >> has also varied historically across different versions of Linux. >> Avoid its use: use sigaction(2) instead. > > Thanks, that would be a good reference to use. > > Yours, > Mikael Sterner > > * Looking at you, JEP 411: https://mail.openjdk.org/pipermail/security-dev/2021-May/026200.html From jsjolen at openjdk.org Mon Apr 14 12:50:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 14 Apr 2025 12:50:44 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v4] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 12:45:03 GMT, Afshin Zafari wrote: >> At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. >> This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. >> >> Two test-cases added and run. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > review comments applied Hi, I don't think that we should introduce an 'error' version of `SummaryDiff` which fills in `-1`s. This is a valid state for `SummaryDiff` to be in. I think that the correct strategy when uncommitting over released regions is to do nothing to those regions. If I do: tree.commit_mapping(0, 10); tree.commit_mapping(20, 10); tree.uncommit_mapping(0, 100); Then I expect my two committed regions to now be reserved, and everything which was previously released to not have been changed. ------------- PR Review: https://git.openjdk.org/jdk/pull/24572#pullrequestreview-2763338233 From jsjolen at openjdk.org Mon Apr 14 12:51:31 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 14 Apr 2025 12:51:31 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: <8kbpsUXzSOG-GNu-5lYfup2tdsCmJG74aB2_G92aRyw=.86dbed3a-e1a6-409d-8748-7634a01ea2a5@github.com> Message-ID: On Sun, 13 Apr 2025 22:51:38 GMT, David Holmes wrote: > > this lock isn't held by the async log writer when reading _buffer_staging for writing. > > Where is the code that does this reading? The writer is supposed to hold the producer and consumer locks when writing, and the BufferUpdater is protected by the consumer lock. Right, my bad. By writing I meant 'writing to output'/'flushing the log buffer'. The code is in AsyncLogWriter::write. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2800657520 From jsjolen at openjdk.org Mon Apr 14 12:54:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 14 Apr 2025 12:54:57 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v12] In-Reply-To: References: Message-ID: On Sat, 12 Apr 2025 23:06:46 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 10 cases added for overlapping with multiple regions OK, LGTM. Thanks! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2763325378 From dholmes at openjdk.org Mon Apr 14 12:57:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Apr 2025 12:57:28 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v4] In-Reply-To: <8ZuWdfemhkK5XnhAKck2qADFzI_SCxOfGmHoooYJ5N8=.211d83c5-f82a-432d-bd04-c03c1a92bac8@github.com> References: <8ZuWdfemhkK5XnhAKck2qADFzI_SCxOfGmHoooYJ5N8=.211d83c5-f82a-432d-bd04-c03c1a92bac8@github.com> Message-ID: On Fri, 11 Apr 2025 08:14:35 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). I need to re-test this in our CI system. @ktakakuri please merge this with latest master as it is getting along way behind - thanks. test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 73: > 71: null; > 72: if (systemRoot == null || ! systemRoot.isDirectory()) > 73: return; // Not Windows as we know it This doesn't compile - the function returns a String. ------------- PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2763490318 PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2800387247 PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2800661319 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2041628925 From tpushkin at openjdk.org Mon Apr 14 14:00:40 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 14 Apr 2025 14:00:40 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v7] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: - Fix indentation - Extend ClassFromClasspath test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/903f0f97..d2e51dac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=05-06 Stats: 75 lines in 3 files changed: 62 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Mon Apr 14 14:04:33 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 14 Apr 2025 14:04:33 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v8] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Remove unused imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/d2e51dac..fca3c919 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=06-07 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Mon Apr 14 15:06:41 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 14 Apr 2025 15:06:41 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v5] In-Reply-To: References: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com> Message-ID: On Thu, 10 Apr 2025 16:01:20 GMT, Ioi Lam wrote: >> Currently we have some restrictions if`-Djava.system.class.loader=` is specified >> >> - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286 >> - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886 >> >> I think we should extend this limitation further (in a separate issue) >> >> - At dump time, dump only boot classes (no platform, system or unregistered) >> - At run time, load only boot classes (no platform, system or unregistered) >> >> I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) > > In the current JDK (with or without this patch), in your scenario, I think the name "S" will be printed twice with two different IDs. If a Child class named "C" is loaded by a custom loader, it will refer to one of the IDs. Depending on the order of loading, it might refer to the first or the second ID. > > During dump time, we will try to load this class twice, but both attempts will result in the same class (defined by the user-defined system class loader). When resolving the unregistered class, using either ID will give you the correct super class ... > > Anyway, this seems too fragile. I think we should fix [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating this patch. Or, maybe we can include the fixes of that bug in this PR as well (and then close that bug as a duplicate of this one). What do you think? In my scenario I actually meant that is in the class list while is not but it doesn't matter much, the incorrect one will be loaded any way. Since the new implementation will behave the same as the existing one in this aspect I think it is OK to fix JDK-8354315 separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042346769 From coleenp at openjdk.org Mon Apr 14 15:24:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Apr 2025 15:24:18 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor Message-ID: This is a redo of the trivial change that failed. The second commit is the method I should have added. Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. Thanks, Coleen ------------- Commit messages: - 8354448: [REDO] Remove friends for ObjectMonitor - Revert "8354446: [BACKOUT] Remove friends for ObjectMonitor" Changes: https://git.openjdk.org/jdk/pull/24626/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24626&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354448 Stats: 14 lines in 3 files changed: 7 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24626/head:pull/24626 PR: https://git.openjdk.org/jdk/pull/24626 From tpushkin at openjdk.org Mon Apr 14 15:28:11 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 14 Apr 2025 15:28:11 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6] In-Reply-To: References: Message-ID: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com> On Thu, 10 Apr 2025 16:04:59 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove findClass, extend explanation comments > > test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53: > >> 51: out.shouldContain("unreg CustomLoadee"); >> 52: } >> 53: } > > For completeness, I think we should have a more complicated scenario: > > - load CustomLoadee in both the app loader and a custom loader > - load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader > > At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change. This is the case you've suggested, it works fine both before and after the change. java/lang/Object id: 0 CustomLoadee3 id: 1 CustomLoadee3 id: 2 super: 0 source: a.jar CustomLoadee3Child id: 3 super: 2 source: a.jar However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one. # Difference with the previous: super of the last class java/lang/Object id: 0 CustomLoadee3 id: 1 CustomLoadee3 id: 2 super: 0 source: a.jar CustomLoadee3Child id: 3 super: 1 source: a.jar And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3. # Difference with the previous: source of the last class java/lang/Object id: 0 CustomLoadee3 id: 1 CustomLoadee3 id: 2 super: 0 source: a.jar CustomLoadee3Child id: 3 super: 1 source: b.jar ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042386067 From gziemski at openjdk.org Mon Apr 14 16:03:55 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 14 Apr 2025 16:03:55 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v7] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 19:01:08 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the GHA failures. > > As far as the implementation is concerned, let's not optimize too early, i.e. no common code or sharing code: each case should stand on its own, without having to follow code above it, or below it. > @gerard-ziemski Only the author (@afshin-zafari) is allowed to issue the `contributor` command. Wrong PR, ignore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2802184895 From yjs at stradmann.name Mon Apr 14 16:22:40 2025 From: yjs at stradmann.name (Yannik Stradmann) Date: Mon, 14 Apr 2025 18:22:40 +0200 (CEST) Subject: Exponentially delay subsequent native thread creation in case of EAGAIN Message-ID: <1463412263.107401.1744647760317@office.mailbox.org> Hello everyone, I'd like to propose a change to hotspot's error handling when spawning native threads in os::create_thread(). Currently, if EAGAIN is encountered, we retry three times back-to-back. During recent years, I've experienced instabilities on certain systems, where back-to-back (re-)requests of native threads kept hitting the depleted resource pool and, eventually, failed. I therefore propose to introduce an exponential backoff when hitting EAGAIN during native thread creation. Hotspot will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. For reference, I am attaching a patch against os_linux.cpp, which has been running in production on a mid-scale Jenkins cluster over the past three years. If you approve the modification, I'm happy to create a pull request that includes the other platforms (where applicable). The current choice of constants is arbitrary and I'd welcome any suggestions here. Please note that this is my first time contributing to OpenJDK, please excuse potential unfamiliarities with the process. Yannik diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp index 4e26797cd5b..2858fbba247 100644 --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -1064,10 +1064,28 @@ bool os::create_thread(Thread* thread, ThreadType thr_type, ResourceMark rm; pthread_t tid; int ret = 0; - int limit = 3; - do { + int limit = 5; + useconds_t delay = 1'000; + constexpr useconds_t max_delay = 1'000'000; + + while (true) { ret = pthread_create(&tid, &attr, (void* (*)(void*)) thread_native_entry, thread); - } while (ret == EAGAIN && limit-- > 0); + + if (ret != EAGAIN) { + break; + } + + if (limit-- <= 0) { + break; + } + + log_warning(os, thread)("Failed to start native thread (%s), retrying after %dus.", os::errno_name(ret), delay); + ::usleep(delay); + delay *= 2; + if (delay > max_delay) { + delay = max_delay; + } + } char buf[64]; if (ret == 0) { From kbarrett at openjdk.org Mon Apr 14 17:33:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 14 Apr 2025 17:33:45 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: <_IFtgCpCeoWM0MzTAUoGudMWZUxlB0qVKP1lqCgXnW4=.0c72b857-d6d6-4d75-b644-e83b45c27b91@github.com> On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen Looks good. I didn't find it trivial though. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24626#pullrequestreview-2765086551 From shade at openjdk.org Mon Apr 14 17:33:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 14 Apr 2025 17:33:46 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24626#pullrequestreview-2765092127 From coleenp at openjdk.org Mon Apr 14 17:57:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Apr 2025 17:57:43 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen Thanks for the reviews. I'll not treat it as trivial and wait. Once burned twice shy. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24626#issuecomment-2802459354 From dholmes at openjdk.org Tue Apr 15 00:55:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Apr 2025 00:55:10 GMT Subject: RFR: 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name Message-ID: Trivial fix to add missing underscore: WINDOWS -> _WINDOWS When the original code was combined into a shared version, the ifdef around this windows-specific part was incorrect. Testing: sanity builds only. Correctness is by inspection. There are no tests for static agents that would exercise this code path. Thanks. ------------- Commit messages: - 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name Changes: https://git.openjdk.org/jdk/pull/24641/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24641&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353946 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24641/head:pull/24641 PR: https://git.openjdk.org/jdk/pull/24641 From iklam at openjdk.org Tue Apr 15 01:01:08 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 15 Apr 2025 01:01:08 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6] In-Reply-To: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com> References: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com> Message-ID: On Mon, 14 Apr 2025 15:23:07 GMT, Timofei Pushkin wrote: >> test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53: >> >>> 51: out.shouldContain("unreg CustomLoadee"); >>> 52: } >>> 53: } >> >> For completeness, I think we should have a more complicated scenario: >> >> - load CustomLoadee in both the app loader and a custom loader >> - load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader >> >> At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader > > This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change. > > This is the case you've suggested, it works fine both before and after the change. > > java/lang/Object id: 0 > CustomLoadee3 id: 1 > CustomLoadee3 id: 2 super: 0 source: a.jar > CustomLoadee3Child id: 3 super: 2 source: a.jar > > > However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one. > > # Difference with the previous: super of the last class > java/lang/Object id: 0 > CustomLoadee3 id: 1 > CustomLoadee3 id: 2 super: 0 source: a.jar > CustomLoadee3Child id: 3 super: 1 source: a.jar > > > And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3. > > # Difference with the previous: source of the last class > java/lang/Object id: 0 > CustomLoadee3 id: 1 > CustomLoadee3 id: 2 super: 0 source: a.jar > CustomLoadee3Child id: 3 super: 1 source: b.jar > > > Although the last case is a regression, I am not sure how much of a problem this is since in general having a registered super with the same name as another unregistered class is not supported anyway as shown by the second case. Thanks for doing the investigation. I think we are always going to have some corner cases that cannot be covered: - For your second case, we would need a separate ClassLoader per class. - However, that will result in the IllegalAccessError in the current PR The problem is we are trying to reconstruct the classes without reconstructing the ClassLoaders. A real solution would probably require updating the classlist format. However, future CDS improvements will be based on the AOT cache introduced in JEP 483. As of JDK 25, we have changed the AOT cache configuration file from a text file (classlist) to a binary file (see https://github.com/openjdk/jdk/pull/23484) . Also, the unregistered classes are saved from the training run, where we still have ClassLoader information (see https://github.com/openjdk/jdk/pull/23926). Therefore, I think we should just leave the old classlist format as is, and accept that certain unregistered classes cannot be supported. I'll try add some test cases ([JDK-8354557](https://bugs.openjdk.org/browse/JDK-8354557)) for the AOT cache using the test cases you identified above. This PR address the IllegalAccessError problem and simplifies the implementation of classlist handling. However, it causes incompatibility (in your third case). I think we should change the error checking code in `InstanceKlass* ClassListParser::load_class_from_source()` to print a warning message and continue. These are the rare cases that we cannot support. Since CDS is just a cache mechanism, it should be acceptable that certain classes are not supported. We can use your second and third test cases to validate the warning messages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2043259660 From kbarrett at openjdk.org Tue Apr 15 01:34:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 15 Apr 2025 01:34:54 GMT Subject: RFR: 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 00:50:16 GMT, David Holmes wrote: > Trivial fix to add missing underscore: WINDOWS -> _WINDOWS > > When the original code was combined into a shared version, the ifdef around this windows-specific part was incorrect. > > Testing: sanity builds only. Correctness is by inspection. > > There are no tests for static agents that would exercise this code path. > > Thanks. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24641#pullrequestreview-2766243679 From dholmes at openjdk.org Tue Apr 15 02:04:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Apr 2025 02:04:06 GMT Subject: RFR: 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 01:32:06 GMT, Kim Barrett wrote: >> Trivial fix to add missing underscore: WINDOWS -> _WINDOWS >> >> When the original code was combined into a shared version, the ifdef around this windows-specific part was incorrect. >> >> Testing: sanity builds only. Correctness is by inspection. >> >> There are no tests for static agents that would exercise this code path. >> >> Thanks. > > Looks good. Thanks @kimbarrett ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24641#issuecomment-2803541616 From dholmes at openjdk.org Tue Apr 15 02:04:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Apr 2025 02:04:06 GMT Subject: Integrated: 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 00:50:16 GMT, David Holmes wrote: > Trivial fix to add missing underscore: WINDOWS -> _WINDOWS > > When the original code was combined into a shared version, the ifdef around this windows-specific part was incorrect. > > Testing: sanity builds only. Correctness is by inspection. > > There are no tests for static agents that would exercise this code path. > > Thanks. This pull request has now been integrated. Changeset: 92e52fe1 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/92e52fe1df84efd94d713afed5acd9c7281a77d7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8353946: Incorrect WINDOWS ifdef in os::build_agent_function_name Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/24641 From david.holmes at oracle.com Tue Apr 15 03:07:30 2025 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2025 13:07:30 +1000 Subject: Exponentially delay subsequent native thread creation in case of EAGAIN In-Reply-To: <1463412263.107401.1744647760317@office.mailbox.org> References: <1463412263.107401.1744647760317@office.mailbox.org> Message-ID: <1ba19f38-3579-4747-944a-26a8f270a4a2@oracle.com> Hi Yannik, On 15/04/2025 2:22 am, Yannik Stradmann wrote: > Hello everyone, > > I'd like to propose a change to hotspot's error handling when spawning native threads in os::create_thread(). > > Currently, if EAGAIN is encountered, we retry three times back-to-back. > > During recent years, I've experienced instabilities on certain systems, where back-to-back (re-)requests of native threads kept hitting the depleted resource pool and, eventually, failed. > > I therefore propose to introduce an exponential backoff when hitting EAGAIN during native thread creation. Hotspot will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > For reference, I am attaching a patch against os_linux.cpp, which has been running in production on a mid-scale Jenkins cluster over the past three years. If you approve the modification, I'm happy to create a pull request that includes the other platforms (where applicable). > The current choice of constants is arbitrary and I'd welcome any suggestions here. This is not an unreasonable idea. But it is very hard to evaluate the effectiveness of such a change. Do you have any actual data on how many retries you have had to wait to succeed? When the retries were added in: https://bugs.openjdk.org/browse/JDK-8268773 there was some discussion across a number of bug reports and two PRs about the potential usefulness of even doing a basic retry as the error condition was considered to unlikely to be self correcting. But as per that original change, adding a delay between retries does no harm other than delaying the ultimate reporting of an error, so it may be okay to put in place if it will do some good. I've filed an enhancement request on your behalf: https://bugs.openjdk.org/browse/JDK-8354560 > Please note that this is my first time contributing to OpenJDK, please excuse potential unfamiliarities with the process. Please see the following: https://openjdk.org/guide/ Thanks, David > > Yannik > > > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > index 4e26797cd5b..2858fbba247 100644 > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -1064,10 +1064,28 @@ bool os::create_thread(Thread* thread, ThreadType thr_type, > ResourceMark rm; > pthread_t tid; > int ret = 0; > - int limit = 3; > - do { > + int limit = 5; > + useconds_t delay = 1'000; > + constexpr useconds_t max_delay = 1'000'000; > + > + while (true) { > ret = pthread_create(&tid, &attr, (void* (*)(void*)) thread_native_entry, thread); > - } while (ret == EAGAIN && limit-- > 0); > + > + if (ret != EAGAIN) { > + break; > + } > + > + if (limit-- <= 0) { > + break; > + } > + > + log_warning(os, thread)("Failed to start native thread (%s), retrying after %dus.", os::errno_name(ret), delay); > + ::usleep(delay); > + delay *= 2; > + if (delay > max_delay) { > + delay = max_delay; > + } > + } > > char buf[64]; > if (ret == 0) { From dholmes at openjdk.org Tue Apr 15 06:23:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Apr 2025 06:23:41 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 Okay, so `AsyncLogWriter::write` will do: _buffer_staging->iterator(); while (it.hasNext()) { const Message* e = it.next(); ... lock-free AFAICS. And concurrently we could have: AsyncLogWriter::BufferUpdater::~BufferUpdater() { AsyncLogWriter::flush(); auto p = AsyncLogWriter::_instance; { ConsumerLocker clocker; delete p->_buffer; delete p->_buffer_staging; <= DELETES THE BUFFER BEING ITERATED p->_buffer = _buf1; p->_buffer_staging = _buf2; } } I would have expected to see crashes from this rather than the presented failure mode, but I guess exactly what the iterating thread encounters is indeterminate. Getting rid of BufferUpdater seems reasonable. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24508#pullrequestreview-2766948192 From dholmes at openjdk.org Tue Apr 15 06:50:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Apr 2025 06:50:41 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen It probably would have helped if `set_recursions` had a comment stating what it is used for (which seems to be setting recursions when an anonymously owned monitor is given its true owner details). Updated fix is fine. Thanks src/hotspot/share/runtime/objectMonitor.inline.hpp line 154: > 152: > 153: inline void ObjectMonitor::increment_recursions(JavaThread* current) { > 154: assert(has_owner(current), "must be the owner"); May be overkill to have this assert ... ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24626#pullrequestreview-2767003304 PR Review Comment: https://git.openjdk.org/jdk/pull/24626#discussion_r2043750379 From tpushkin at openjdk.org Tue Apr 15 11:25:43 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 15 Apr 2025 11:25:43 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6] In-Reply-To: References: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com> Message-ID: On Tue, 15 Apr 2025 00:58:19 GMT, Ioi Lam wrote: >> This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change. >> >> This is the case you've suggested, it works fine both before and after the change. >> >> java/lang/Object id: 0 >> CustomLoadee3 id: 1 >> CustomLoadee3 id: 2 super: 0 source: a.jar >> CustomLoadee3Child id: 3 super: 2 source: a.jar >> >> >> However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one. >> >> # Difference with the previous: super of the last class >> java/lang/Object id: 0 >> CustomLoadee3 id: 1 >> CustomLoadee3 id: 2 super: 0 source: a.jar >> CustomLoadee3Child id: 3 super: 1 source: a.jar >> >> >> And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3. >> >> # Difference with the previous: source of the last class >> java/lang/Object id: 0 >> CustomLoadee3 id: 1 >> CustomLoadee3 id: 2 super: 0 source: a.jar >> CustomLoadee3Child id: 3 super: 1 source: b.jar >> >> >> Although the last case is a regression, I am not sure how much of a problem this is since in general having a registered super with the same name as another unregistered class is not supported anyway as shown by the second case. > > Thanks for doing the investigation. I think we are always going to have some corner cases that cannot be covered: > > - For your second case, we would need a separate ClassLoader per class. > - However, that will result in the IllegalAccessError in the current PR > > The problem is we are trying to reconstruct the classes without reconstructing the ClassLoaders. A real solution would probably require updating the classlist format. > > However, future CDS improvements will be based on the AOT cache introduced in JEP 483. As of JDK 25, we have changed the AOT cache configuration file from a text file (classlist) to a binary file (see https://github.com/openjdk/jdk/pull/23484) . Also, the unregistered classes are saved from the training run, where we still have ClassLoader information (see https://github.com/openjdk/jdk/pull/23926). Therefore, I think we should just leave the old classlist format as is, and accept that certain unregistered classes cannot be supported. I'll try add some test cases ([JDK-8354557](https://bugs.openjdk.org/browse/JDK-8354557)) for the AOT cache using the test cases you identified above. > > This PR address the IllegalAccessError problem and simplifies the implementation of classlist handling. However, it causes incompatibility (in your third case). I think we should change the error checking code in `InstanceKlass* ClassListParser::load_class_from_source()` to print a warning message and continue. These are the rare cases that we cannot support. Since CDS is just a cache mechanism, it should be acceptable that certain classes are not supported. We can use your second and third test cases to validate the warning messages. I fully agree, will implement the warnings ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2044299087 From fbredberg at openjdk.org Tue Apr 15 11:51:59 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 15 Apr 2025 11:51:59 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert Message-ID: This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java ` Also passes tier1-7. ------------- Commit messages: - 8298733: Reconsider monitors_on_stack assert Changes: https://git.openjdk.org/jdk/pull/24655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298733 Stats: 61 lines in 2 files changed: 41 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24655/head:pull/24655 PR: https://git.openjdk.org/jdk/pull/24655 From coleenp at openjdk.org Tue Apr 15 11:53:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Apr 2025 11:53:47 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24626#issuecomment-2804781356 From coleenp at openjdk.org Tue Apr 15 11:53:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Apr 2025 11:53:49 GMT Subject: RFR: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 06:42:58 GMT, David Holmes wrote: >> This is a redo of the trivial change that failed. The second commit is the method I should have added. >> Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. >> Thanks, >> Coleen > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 154: > >> 152: >> 153: inline void ObjectMonitor::increment_recursions(JavaThread* current) { >> 154: assert(has_owner(current), "must be the owner"); > > May be overkill to have this assert ... Yeah this method will be removed with legacy locking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24626#discussion_r2044343532 From coleenp at openjdk.org Tue Apr 15 11:53:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Apr 2025 11:53:49 GMT Subject: Integrated: 8354448: [REDO] Remove friends for ObjectMonitor In-Reply-To: References: Message-ID: <6-j_POK0xX4DjhAMKjpYqxLFt-OzK1GuwRwnw-2U2oU=.d4cdd796-4f50-4e92-971a-089c066644c2@github.com> On Mon, 14 Apr 2025 15:17:54 GMT, Coleen Phillimore wrote: > This is a redo of the trivial change that failed. The second commit is the method I should have added. > Tested with tier1-4, where tier3 has the code to exercise LockingMode=1. > Thanks, > Coleen This pull request has now been integrated. Changeset: 273a9a61 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/273a9a61558fdfc422772fa2c6045a4d3c709a41 Stats: 14 lines in 3 files changed: 7 ins; 5 del; 2 mod 8354448: [REDO] Remove friends for ObjectMonitor Reviewed-by: kbarrett, shade, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24626 From cnorrbin at openjdk.org Tue Apr 15 12:11:03 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 15 Apr 2025 12:11:03 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong Message-ID: There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: - The range contains no nodes, **but** - Nodes exist **outside** that range. The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. ------------- Commit messages: - assert fix with key comparator for intrusive trees Changes: https://git.openjdk.org/jdk/pull/24658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354433 Stats: 93 lines in 3 files changed: 55 ins; 18 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24658/head:pull/24658 PR: https://git.openjdk.org/jdk/pull/24658 From rehn at openjdk.org Tue Apr 15 12:28:19 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 15 Apr 2025 12:28:19 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds Message-ID: Hi, please consider. If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. Locally tested with a "--disable-jvm-feature-cds" build of the vm. Thanks, Robbin ------------- Commit messages: - added require vm.cds Changes: https://git.openjdk.org/jdk/pull/24659/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24659&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354667 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24659.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24659/head:pull/24659 PR: https://git.openjdk.org/jdk/pull/24659 From rehn at openjdk.org Tue Apr 15 12:28:19 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 15 Apr 2025 12:28:19 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:20:19 GMT, Robbin Ehn wrote: > Hi, please consider. > > If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. > Locally tested with a "--disable-jvm-feature-cds" build of the vm. > > Thanks, Robbin Just an FYI: @tstuefe ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24659#issuecomment-2804865529 From jsjolen at openjdk.org Tue Apr 15 14:55:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 15 Apr 2025 14:55:41 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: <0U1gfdIlQv1jTnsQNVIxpQWpwU8VD-zLXvpD8mGIlfM=.9ab75c3d-8e49-45d6-8b52-dd7295967a58@github.com> On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 @MBaesken , would you mind running this through your CI and approving if it looks good? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2805746485 From mbaesken at openjdk.org Tue Apr 15 15:01:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Apr 2025 15:01:55 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: <0U1gfdIlQv1jTnsQNVIxpQWpwU8VD-zLXvpD8mGIlfM=.9ab75c3d-8e49-45d6-8b52-dd7295967a58@github.com> References: <0U1gfdIlQv1jTnsQNVIxpQWpwU8VD-zLXvpD8mGIlfM=.9ab75c3d-8e49-45d6-8b52-dd7295967a58@github.com> Message-ID: On Tue, 15 Apr 2025 14:53:26 GMT, Johan Sj?len wrote: > would you mind running this through your CI and approving if it looks good? Will add this to our tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2805832031 From lmesnik at openjdk.org Tue Apr 15 16:08:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Apr 2025 16:08:51 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:20:19 GMT, Robbin Ehn wrote: > Hi, please consider. > > If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. > Locally tested with a "--disable-jvm-feature-cds" build of the vm. > > Thanks, Robbin Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24659#pullrequestreview-2769002264 From pchilanomate at openjdk.org Tue Apr 15 17:19:43 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 15 Apr 2025 17:19:43 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert In-Reply-To: References: Message-ID: <9SO5dASA2dg9Pmf423EJrUzM9Un1eWhSb-aIevaUUL4=.73203a2a-739a-41e5-8a9b-c53acad365fb@github.com> On Tue, 15 Apr 2025 09:38:05 GMT, Fredrik Bredberg wrote: > This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. > > It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. > > A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. > > In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: > `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java > ` > > Also passes tier1-7. Looks good to me, thanks. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 577: > 575: map.set_include_argument_oops(false); > 576: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { > 577: StackWatermark* watermark = StackWatermarkSet::get(thread, StackWatermarkKind::gc); We could move this outside the loop. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 587: > 585: #ifdef ASSERT > 586: static bool monitors_on_stack(JavaThread* thread) { > 587: assert_frames_in_continuation_are_safe(thread); Leftover? We just called this in the caller. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24655#pullrequestreview-2769188713 PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2045099065 PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2045106994 From ccheung at openjdk.org Tue Apr 15 18:03:49 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 15 Apr 2025 18:03:49 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v8] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 14:04:33 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports I have one comment in CDS.java. src/java.base/share/classes/jdk/internal/misc/CDS.java line 390: > 388: @Override > 389: public byte[] readClassFile(String className) throws IOException { > 390: final var subPath = className.replace('.', File.separatorChar).concat(".class"); Should File.separatorChar be ?/? ? (just like at line 369) ------------- PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2769319159 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2045182045 From coleenp at openjdk.org Tue Apr 15 20:04:00 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Apr 2025 20:04:00 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 09:38:05 GMT, Fredrik Bredberg wrote: > This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. > > It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. > > A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. > > In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: > `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java > ` > > Also passes tier1-7. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 594: > 592: RegisterMap::WalkContinuation::skip); > 593: map.set_include_argument_oops(false); > 594: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { We walk the stack twice - once to assert_is_frame_safe() for the stack watermark and then this set of calls about owning locks. Why not just add if (watermark != nullptr) watermark->assert_is_frame_safe(f); here. Why is the same thing twice - ie getting the RegisterMap? I thought the problem with monitors_on_stack was that the watermark was not safe for older (higher) frames? Is it that at this call location, the stack watermark has been processed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2045383520 From amenkov at openjdk.org Tue Apr 15 23:54:20 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 15 Apr 2025 23:54:20 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools Message-ID: The change is a preparation step to enable attach streaming output by default. The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. Details in the first comment. Testing: tier1..7 with enabled attach streaming output ------------- Commit messages: - tests Changes: https://git.openjdk.org/jdk/pull/24672/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24672&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354461 Stats: 159 lines in 19 files changed: 44 ins; 56 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/24672.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24672/head:pull/24672 PR: https://git.openjdk.org/jdk/pull/24672 From amenkov at openjdk.org Tue Apr 15 23:54:20 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 15 Apr 2025 23:54:20 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output The tests use the same scenario: test runs a tool (jcmd/jstack/jmap) to attach to the main test process and redirects the tool output for analysis. We have 2 buffers here: 1. attach channel (socket or pipe depending on platform) - attach operation handler writes, the tool reads. 2. tool redirection buffer - the tool writes, test reads. When attach operation is executes at safepoint, attach streaming output is enabled and the tool output is lengthy we can get both buffers full and the test hung: - attach handler blocks on write operation (tool need to read from the socket/pipe); - the tool reads data from attach channel and blocks writing the data to its stdout (need to read from redirected stream); - test redirector reader cannot read because the VM is at safepoint executing attach operation. To avoid the deadlocks the test are updated to disable attach streaming output (attach operation output is buffered and is sent after the operation is completed). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2807765324 From syan at openjdk.org Wed Apr 16 03:51:44 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 16 Apr 2025 03:51:44 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:20:19 GMT, Robbin Ehn wrote: > Hi, please consider. > > If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. > Locally tested with a "--disable-jvm-feature-cds" build of the vm. > > Thanks, Robbin Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24659#pullrequestreview-2770574700 From stuefe at openjdk.org Wed Apr 16 05:33:45 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 16 Apr 2025 05:33:45 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:21:18 GMT, Robbin Ehn wrote: >> Hi, please consider. >> >> If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. >> Locally tested with a "--disable-jvm-feature-cds" build of the vm. >> >> Thanks, Robbin > > Just an FYI: @tstuefe ! Thanks @robehn ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24659#issuecomment-2808345718 From mbaesken at openjdk.org Wed Apr 16 07:32:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Apr 2025 07:32:55 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 Looks okay and no issues seen in our CI ; small comment inside test/hotspot/gtest/logging/test_asynclog.cpp line 250: > 248: if (AsyncLogWriter::instance() == nullptr) return; > 249: if (LogConfiguration::async_mode() != LogConfiguration::AsyncMode::Drop) { > 250: EXPECT_TRUE(false) << "This test must be run in drop mode if async UL is activated"; EXPECT_TRUE(false) looks a little weird but probably does what you want; could you just use FAIL() here ? ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24508#pullrequestreview-2771451846 PR Review Comment: https://git.openjdk.org/jdk/pull/24508#discussion_r2046266776 From tpushkin at openjdk.org Wed Apr 16 07:52:43 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 16 Apr 2025 07:52:43 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v8] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 17:59:41 GMT, Calvin Cheung wrote: >> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused imports > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 390: > >> 388: @Override >> 389: public byte[] readClassFile(String className) throws IOException { >> 390: final var subPath = className.replace('.', File.separatorChar).concat(".class"); > > Should File.separatorChar be ?/? ? (just like at line 369) No, this is an intentional difference. Here the string is then passed to `Path.of(...)` so it should definitely be `File.separatorChar` because this is what `Path.of(...)` expects. Regarding line 369, the string is then passed to `JarFile.getEntry(String name)` ? I wasn't able to find the description of the format of the `name` parameter so I followed the way `URLClassLoader` does it, it uses `/` for loading from a JAR (and `File.separatorChar` for loading from a directory). This seems logical since JAR format is platform-independent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2046316431 From jsjolen at openjdk.org Wed Apr 16 07:57:08 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 16 Apr 2025 07:57:08 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm [v2] In-Reply-To: References: Message-ID: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Use FAIL ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24508/files - new: https://git.openjdk.org/jdk/pull/24508/files/6071f65b..a52c5df9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24508&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24508&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24508/head:pull/24508 PR: https://git.openjdk.org/jdk/pull/24508 From jsjolen at openjdk.org Wed Apr 16 07:57:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 16 Apr 2025 07:57:09 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm [v2] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 07:29:05 GMT, Matthias Baesken wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Use FAIL > > test/hotspot/gtest/logging/test_asynclog.cpp line 250: > >> 248: if (AsyncLogWriter::instance() == nullptr) return; >> 249: if (LogConfiguration::async_mode() != LogConfiguration::AsyncMode::Drop) { >> 250: EXPECT_TRUE(false) << "This test must be run in drop mode if async UL is activated"; > > EXPECT_TRUE(false) looks a little weird but probably does what you want; could you just use FAIL() here ? Oh, nice, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24508#discussion_r2046321392 From mbaesken at openjdk.org Wed Apr 16 09:43:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Apr 2025 09:43:57 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm [v2] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 07:57:08 GMT, Johan Sj?len wrote: >> Hi, >> >> The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: >> >> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) >> 2. Print the entirety of the log file produced if no missing messages are found >> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. >> >> If the test fails in the future, then these will give important diagnostic information regarding the state of the test. >> >> This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Use FAIL Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24508#pullrequestreview-2771850343 From jsjolen at openjdk.org Wed Apr 16 09:43:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 16 Apr 2025 09:43:57 GMT Subject: RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: <0U1gfdIlQv1jTnsQNVIxpQWpwU8VD-zLXvpD8mGIlfM=.9ab75c3d-8e49-45d6-8b52-dd7295967a58@github.com> Message-ID: On Tue, 15 Apr 2025 14:59:04 GMT, Matthias Baesken wrote: >> @MBaesken , would you mind running this through your CI and approving if it looks good? > >> would you mind running this through your CI and approving if it looks good? > > Will add this to our tests. @MBaesken , would you mind re-approving? I won't integrate unless GHA passes :-). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24508#issuecomment-2808951394 From rehn at openjdk.org Wed Apr 16 10:12:05 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 16 Apr 2025 10:12:05 GMT Subject: RFR: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:20:19 GMT, Robbin Ehn wrote: > Hi, please consider. > > If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. > Locally tested with a "--disable-jvm-feature-cds" build of the vm. > > Thanks, Robbin Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24659#issuecomment-2809046178 From rehn at openjdk.org Wed Apr 16 10:12:06 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 16 Apr 2025 10:12:06 GMT Subject: Integrated: 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:20:19 GMT, Robbin Ehn wrote: > Hi, please consider. > > If the vm is built with --disable-jvm-feature-cds these two versions of the test fails. > Locally tested with a "--disable-jvm-feature-cds" build of the vm. > > Thanks, Robbin This pull request has now been integrated. Changeset: fe3bd5d6 Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/fe3bd5d62fdedb7890bd3d589b04285be79c24ed Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8354667: [TESTBUG] AccessZeroNKlassHitsProtectionZone cds tests require cds Reviewed-by: lmesnik, syan ------------- PR: https://git.openjdk.org/jdk/pull/24659 From duke at openjdk.org Wed Apr 16 10:39:13 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Wed, 16 Apr 2025 10:39:13 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN Message-ID: This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. ------------- Commit messages: - Exponentially delay native thread creation retries Changes: https://git.openjdk.org/jdk/pull/24682/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354560 Stats: 83 lines in 4 files changed: 62 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From duke at openjdk.org Wed Apr 16 10:43:41 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Wed, 16 Apr 2025 10:43:41 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN In-Reply-To: References: Message-ID: <-mcU1Z8-2pCNsg4HljZF7z6qPkRC-SAOYcfjztS6Cjw=.ccdecdf2-021d-42e5-b849-4134bf95db00@github.com> On Wed, 16 Apr 2025 10:34:18 GMT, Yannik Stradmann wrote: > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. @dholmes-ora Thanks a lot for filing the enhancement request! I don't have permissions to comment in JBS, so I'll reply via this PR ? where we can also discuss the specific implementation. > Do you have any actual data on how many retries you have had to wait to succeed? I just spent some time scraping all log files I could find from times before we deployed a custom hotspot build including the exponential backoff to production. Unfortunately, this data is rather sparse ? but I have similarly sparse data from right after deployment of the modified JVM. The sparsity will reduce the overall amount of logs I see, but should not alter their distribution, so the numbers below will just be a factor of 10-100 smaller than reality. For our specific cluster, I have found 1. with upstream (3 retries, back-to-back): > 4/day fatal errors due to failed native thread starts 2. with this change (exponential backoff): 0 fatal errors due to failed native thread starts (over all times) 3. with this change, up to 9/day retries were logged 4. with this change, the first retry after 1000us was always successful ? I did not find a single occasion where we've hit a second sleep. Based on these observations, I have kept the amount of retries unchanged (3) for now. The last point indicates that my previous parametrization of 1000us for the initial delay was too conservative. I've therefore reduced it to 256us, which will result in a maximum inter-trial delay of 1024us. > When the retries were added in: > https://bugs.openjdk.org/browse/JDK-8268773 > there was some discussion across a number of bug reports and two PRs about the potential usefulness of even doing a basic retry as the error condition was considered to unlikely to be self correcting. But as per that original change, adding a delay between retries does no harm other than delaying the ultimate reporting of an error, so it may be okay to put in place if it will do some good. I agree ? if at all, this change would counteract the concerns raised in the original discussion by giving the system time to potentially leave the overloaded state. Besides the slightly delayed error reporting you've mentioned, harm could also come from delayed successful thread starts in applications that rely on low jitter and would prefer instantaneous failure over delayed success. Since I'm not aware of any timing guarantees by `pthread_create()` itself, this feels unlikely to me ? but I didn't want to leave it unmentioned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24682#issuecomment-2809176854 From jsjolen at openjdk.org Wed Apr 16 11:35:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 16 Apr 2025 11:35:52 GMT Subject: Integrated: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sj?len wrote: > Hi, > > The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well: > > 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode) > 2. Print the entirety of the log file produced if no missing messages are found > 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message. > > If the test fails in the future, then these will give important diagnostic information regarding the state of the test. > > This is a re-worked version of https://github.com/openjdk/jdk/pull/24411 This pull request has now been integrated. Changeset: 7ffad35d Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/7ffad35dac1439bc5aa12a6c16b5e8254251170b Stats: 73 lines in 4 files changed: 27 ins; 39 del; 7 mod 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm Reviewed-by: mbaesken, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24508 From mbaesken at openjdk.org Wed Apr 16 12:06:02 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Apr 2025 12:06:02 GMT Subject: RFR: 8354802: MAX_SECS definition is unused in os_linux Message-ID: Seems the MAX_SECS definition in os_linux.cpp is not needed any more, related code was moved or deleted. ------------- Commit messages: - JDK-8354802 Changes: https://git.openjdk.org/jdk/pull/24686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354802 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24686/head:pull/24686 PR: https://git.openjdk.org/jdk/pull/24686 From kbarrett at openjdk.org Wed Apr 16 12:27:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 16 Apr 2025 12:27:45 GMT Subject: RFR: 8354802: MAX_SECS definition is unused in os_linux In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:01:44 GMT, Matthias Baesken wrote: > Seems the MAX_SECS definition in os_linux.cpp is not needed any more, related code was moved or deleted. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24686#pullrequestreview-2772324594 From fbredberg at openjdk.org Wed Apr 16 12:31:57 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 16 Apr 2025 12:31:57 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert In-Reply-To: <9SO5dASA2dg9Pmf423EJrUzM9Un1eWhSb-aIevaUUL4=.73203a2a-739a-41e5-8a9b-c53acad365fb@github.com> References: <9SO5dASA2dg9Pmf423EJrUzM9Un1eWhSb-aIevaUUL4=.73203a2a-739a-41e5-8a9b-c53acad365fb@github.com> Message-ID: On Tue, 15 Apr 2025 17:14:48 GMT, Patricio Chilano Mateo wrote: >> This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. >> >> It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. >> >> A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. >> >> In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: >> `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java >> ` >> >> Also passes tier1-7. > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 587: > >> 585: #ifdef ASSERT >> 586: static bool monitors_on_stack(JavaThread* thread) { >> 587: assert_frames_in_continuation_are_safe(thread); > > Leftover? We just called this in the caller. Not a leftover. I want `monitors_on_stack()` to be self contained, so if anyone else starts to use it they don't need to call `assert_frames_in_continuation_are_safe()` before calling `monitors_on_stack()`. Also, the plan is to keep `assert_frames_in_continuation_are_safe()` in `unwind_frames()` when we remove legacy locking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2046820772 From fbredberg at openjdk.org Wed Apr 16 12:36:42 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 16 Apr 2025 12:36:42 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 20:01:11 GMT, Coleen Phillimore wrote: >> This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. >> >> It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. >> >> A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. >> >> In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: >> `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java >> ` >> >> Also passes tier1-7. > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 594: > >> 592: RegisterMap::WalkContinuation::skip); >> 593: map.set_include_argument_oops(false); >> 594: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { > > We walk the stack twice - once to assert_is_frame_safe() for the stack watermark and then this set of calls about owning locks. Why not just add if (watermark != nullptr) watermark->assert_is_frame_safe(f); here. Why is the same thing twice - ie getting the RegisterMap? > I thought the problem with monitors_on_stack was that the watermark was not safe for older (higher) frames? Is it that at this call location, the stack watermark has been processed? I knew you where going to say that... :) So, my original code looked exactly like what you are asking for (e.g. called `assert_is_frame_safe(f)` in the loop of `monitors_on_stack()`. Then I had a chat with the GC guys and was convinced to move it into a separate `assert_frames_in_continuation_are_safe()`. Yes it will walk the stack twice, but it's only in debug mode, so not a big deal. It's also a preparation for keeping `assert_frames_in_continuation_are_safe()` in `unwind_frames()` when we remove legacy locking. You are right, by changing the location of the `assert()` that includes the call to `monitors_on_stack()` to just after `flush_stack_processing()` in `unwind_frames()` we ensure that all frames has been processed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2046828080 From fbredberg at openjdk.org Wed Apr 16 13:02:58 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 16 Apr 2025 13:02:58 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert [v2] In-Reply-To: References: Message-ID: > This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. > > It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. > > A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. > > In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: > `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java > ` > > Also passes tier1-7. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated after Patricio's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24655/files - new: https://git.openjdk.org/jdk/pull/24655/files/62486c16..a6f9479f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24655&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24655/head:pull/24655 PR: https://git.openjdk.org/jdk/pull/24655 From fbredberg at openjdk.org Wed Apr 16 13:02:58 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 16 Apr 2025 13:02:58 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert [v2] In-Reply-To: <9SO5dASA2dg9Pmf423EJrUzM9Un1eWhSb-aIevaUUL4=.73203a2a-739a-41e5-8a9b-c53acad365fb@github.com> References: <9SO5dASA2dg9Pmf423EJrUzM9Un1eWhSb-aIevaUUL4=.73203a2a-739a-41e5-8a9b-c53acad365fb@github.com> Message-ID: On Tue, 15 Apr 2025 17:10:07 GMT, Patricio Chilano Mateo wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated after Patricio's review > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 577: > >> 575: map.set_include_argument_oops(false); >> 576: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { >> 577: StackWatermark* watermark = StackWatermarkSet::get(thread, StackWatermarkKind::gc); > > We could move this outside the loop. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2046878430 From duke at openjdk.org Wed Apr 16 13:33:33 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Wed, 16 Apr 2025 13:33:33 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v2] In-Reply-To: References: Message-ID: <14GLhYo4nyadeV9u6nalGSb2zSbHKeGxnLB-vypkeK0=.0e202b51-0712-4b7d-94b7-11d4377ab0a7@github.com> > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: Fix build on Windows: Sleep() only accepts milliseconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24682/files - new: https://git.openjdk.org/jdk/pull/24682/files/d3051d54..d4841a00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From tpushkin at openjdk.org Wed Apr 16 14:14:02 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 16 Apr 2025 14:14:02 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v9] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: - Implement super overshadowing warning - Omit Source classes from archive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/fca3c919..26371665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=07-08 Stats: 397 lines in 10 files changed: 259 ins; 132 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Wed Apr 16 14:34:25 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 16 Apr 2025 14:34:25 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Empty commit to make GH update the PR - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader - Implement super overshadowing warning - Omit Source classes from archive - Remove unused imports - Fix indentation - Extend ClassFromClasspath test - Remove findClass, extend explanation comments - Remove unnecessary scoping - Don't use URLClassPath - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 ------------- Changes: https://git.openjdk.org/jdk/pull/24223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=09 Stats: 659 lines in 13 files changed: 475 ins; 122 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Wed Apr 16 15:59:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 16 Apr 2025 15:59:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Empty commit to make GH update the PR > - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader > - Implement super overshadowing warning > - Omit Source classes from archive > - Remove unused imports > - Fix indentation > - Extend ClassFromClasspath test > - Remove findClass, extend explanation comments > - Remove unnecessary scoping > - Don't use URLClassPath > - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 Besides adding the warnings I noticed that `UnregisteredClassLoader` is omitted from the dump and implemented the same for `UnregisteredClassLoader$Source` and its implementations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2810027521 From coleenp at openjdk.org Wed Apr 16 17:02:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Apr 2025 17:02:55 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert [v2] In-Reply-To: References: Message-ID: <4oi8Q25l4pylhv1hE5pNj9R8oNuosUjNILdwc6HiAZU=.834a2e7d-4a73-48fa-a6c6-b0853040e087@github.com> On Wed, 16 Apr 2025 13:02:58 GMT, Fredrik Bredberg wrote: >> This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. >> >> It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. >> >> A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. >> >> In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: >> `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java >> ` >> >> Also passes tier1-7. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after Patricio's review Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24655#pullrequestreview-2773238108 From coleenp at openjdk.org Wed Apr 16 17:02:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Apr 2025 17:02:55 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert [v2] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:33:08 GMT, Fredrik Bredberg wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 594: >> >>> 592: RegisterMap::WalkContinuation::skip); >>> 593: map.set_include_argument_oops(false); >>> 594: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { >> >> We walk the stack twice - once to assert_is_frame_safe() for the stack watermark and then this set of calls about owning locks. Why not just add if (watermark != nullptr) watermark->assert_is_frame_safe(f); here. Why is the same thing twice - ie getting the RegisterMap? >> I thought the problem with monitors_on_stack was that the watermark was not safe for older (higher) frames? Is it that at this call location, the stack watermark has been processed? > > I knew you where going to say that... :) > So, my original code looked exactly like what you are asking for (e.g. called `assert_is_frame_safe(f)` in the loop of `monitors_on_stack()`. Then I had a chat with the GC guys and was convinced to move it into a separate `assert_frames_in_continuation_are_safe()`. Yes it will walk the stack twice, but it's only in debug mode, so not a big deal. It's also a preparation for keeping `assert_frames_in_continuation_are_safe()` in `unwind_frames()` when we remove legacy locking. > > You are right, by changing the location of the `assert()` that includes the call to `monitors_on_stack()` to just after `flush_stack_processing()` in `unwind_frames()` we ensure that all frames has been processed. Am I that predictable? :) Okay, I see the double code/loop is temporary and one has future usefulness. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2047362072 From pchilanomate at openjdk.org Wed Apr 16 17:12:57 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 16 Apr 2025 17:12:57 GMT Subject: RFR: 8298733: Reconsider monitors_on_stack assert [v2] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 13:02:58 GMT, Fredrik Bredberg wrote: >> This PR aims to revert this [8298371: monitors_on_stack extracts unprocessed oops](https://github.com/openjdk/jdk/pull/11582) fix at the same time as we retain the ability to assert that we don't have any monitors on the stack when legacy locking is used. >> >> It does so by moving an assert that ensures that we don't have any monitors on the stack to a place where all stack frames should have been processed. I.e. it's safe to check the frame for any monitor. >> >> A new function called assert_frames_in_continuation_are_safe() asserts that the frames has been processed (i.e. it safe to revert the [8298371](https://github.com/openjdk/jdk/pull/11582) fix). By keeping that assertion functionality separate from monitors_on_stack() we will be able to keep that assertion after we have removed legacy locking. >> >> In order to recreate the original [problem](https://github.com/openjdk/jdk/pull/11582) and verifying that this PR works used, I used: >> `-XX:LockingMode=1 -XX:+UseZGC -XX:+ZVerifyOops -XX:ZCollectionIntervalMajor=0.001 Fuzz.java >> ` >> >> Also passes tier1-7. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after Patricio's review src/hotspot/share/runtime/continuationFreezeThaw.cpp line 578: > 576: StackWatermark* watermark = StackWatermarkSet::get(thread, StackWatermarkKind::gc); > 577: for (frame f = thread->last_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map)) { > 578: if (watermark != nullptr) { I meant also this nullptr check which can be done outside the loop. You could move it at the beginning of this method and just return if watermark is null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24655#discussion_r2047375630 From ccheung at openjdk.org Wed Apr 16 21:09:23 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 16 Apr 2025 21:09:23 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking Message-ID: This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase. Passed tiers 1 - 4 testing. ------------- Commit messages: - trailing whitespace - 8352003: Support --add-opens with -XX:+AOTClassLinking Changes: https://git.openjdk.org/jdk/pull/24695/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352003 Stats: 169 lines in 5 files changed: 164 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695 PR: https://git.openjdk.org/jdk/pull/24695 From vlivanov at openjdk.org Wed Apr 16 21:53:39 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 16 Apr 2025 21:53:39 GMT Subject: RFR: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 02:44:44 GMT, Ioi Lam wrote: > This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. > > @iwanowww @shipilev could you review? Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24434#pullrequestreview-2773947202 From iklam at openjdk.org Wed Apr 16 21:57:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 16 Apr 2025 21:57:46 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Empty commit to make GH update the PR > - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader > - Implement super overshadowing warning > - Omit Source classes from archive > - Remove unused imports > - Fix indentation > - Extend ClassFromClasspath test > - Remove findClass, extend explanation comments > - Remove unnecessary scoping > - Don't use URLClassPath > - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 src/hotspot/share/cds/classListParser.cpp line 517: > 515: return; > 516: } > 517: assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed"); Does this always prevent an unregistered class to use any other unregistered class as its super type? I think a better check would be here: if (!k->local_interfaces()->contains(specified_interface)) { + jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n", + specified_interface->external_name(), _interfaces->at(i)); print_specified_interfaces(); print_actual_interfaces(k); + throw exception ..... - error("Specified interface %s (id %d) is not directly implemented", - specified_interface->external_name(), _interfaces->at(i)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2047820496 From duke at openjdk.org Thu Apr 17 03:13:05 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 17 Apr 2025 03:13:05 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v3] In-Reply-To: References: Message-ID: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> > 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 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631 - 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. - 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 ``` To resolve this, we add the required `--add-opens` flag to grant access for the benchmark. Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23686/files - new: https://git.openjdk.org/jdk/pull/23686/files/b2bbc24e..db7af981 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=01-02 Stats: 414978 lines in 5199 files changed: 120320 ins; 266094 del; 28564 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 iklam at openjdk.org Thu Apr 17 03:13:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 17 Apr 2025 03:13:51 GMT Subject: RFR: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 21:51:00 GMT, Vladimir Ivanov wrote: >> This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. >> >> @iwanowww @shipilev could you review? > > Looks good. Thanks @iwanowww @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24434#issuecomment-2811615786 From iklam at openjdk.org Thu Apr 17 03:13:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 17 Apr 2025 03:13:52 GMT Subject: Integrated: 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 02:44:44 GMT, Ioi Lam wrote: > This bug was discovered and [fixed in the Leyden repo](https://github.com/openjdk/leyden/commit/bd212673822a21164fbf57b255005339d28ef509). Now the constant pool class/field/method entries that were resolved in the training will be recorded in the AOT config file, so they will be AOT-resolved during cache assembly. > > @iwanowww @shipilev could you review? This pull request has now been integrated. Changeset: a71f621a Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/a71f621a3248320e8a7a78f1652a7750271ed4ef Stats: 145 lines in 5 files changed: 88 ins; 25 del; 32 mod 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration Reviewed-by: shade, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/24434 From haosun at openjdk.org Thu Apr 17 03:39:56 2025 From: haosun at openjdk.org (Hao Sun) Date: Thu, 17 Apr 2025 03:39:56 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v3] In-Reply-To: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> References: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> Message-ID: On Thu, 17 Apr 2025 03:13:05 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 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args > > Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631 > - 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. > - 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 > ``` > > To resolve this, we add the required `--add-opens` flag to grant access > for the benchmark. > > Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac >>>@AlanBateman Can you review this if this patch looks good in principle? >> >> It needs confirmation that it doesn't break the build, I haven't looked into which parts of Liam's change weren't backed out. So if there are no build issues then it should be okay to integrate. > > All of the functional changes from JDK-8331081 and the redo got backed out, the only thing that stayed was test coverage, so I wouldn't expect this to break anything today. Yes. This PR doesn't break the build today as I tested locally. As for the build failure as mentioned by @cushon , I can reproduce the build failure in my local environment. 1. how to reproduce the failure It's important to note that we must revert the commit [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) firstly in order to reproduce the build failure. the code: this PR with commit 1ab1c1d reverted create the JMH bundle configure with --with-jmh=path/to/the/jmh/jar make images make test-image # <--- we encounter build error here 2. possible way to mitigate the failure As mentioned by @xyyNicole , new configure option `--disable-java-warnings-as-errors` is introduced recently in [7aeaa3c](https://github.com/openjdk/jdk/commit/7aeaa3c21c1420191fe8ff59e4cf99eae830754d). As I checked locally, the build failure is gone if we add this option. the code: this PR with commit 1ab1c1d reverted create the JMH bundle configure with --with-jmh=path/to/the/jmh/jar --disable-java-warnings-as-errors make images make test-image # <--- no build error now To be honest, I didn't fully understand [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). I was wondering if `--disable-java-warnings-as-errors` could help to address your concern about this PR. @cushon Here is my understanding for this PR: 1. As mentioned by @AlanBateman , "this micro was created for sun.misc.Unsafe, not jdk.internal.misc.Unsafe". We should keep this test intention as it was. 2. This PR doesn't break the build today. 3. As for the build error as mentioned by @cushon, it would be nice if `--disable-java-warnings-as-errors` can mitigate the error. If not, I agree with @liach that it's a different thing and out of the scope of this PR and we should handle it in a separate task. ------------- Marked as reviewed by haosun (Committer). PR Review: https://git.openjdk.org/jdk/pull/23686#pullrequestreview-2774494500 From cushon at openjdk.org Thu Apr 17 04:25:46 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 17 Apr 2025 04:25:46 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v3] In-Reply-To: References: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> Message-ID: On Thu, 17 Apr 2025 03:37:03 GMT, Hao Sun wrote: > I was wondering if `--disable-java-warnings-as-errors` could help to address your concern about this PR. It doesn't address the issue unless it's configured by default, which I don't think is being proposed. I think the best approach would be to disable `-Werror` for specific compilations that are using `sun.misc` APIs, instead of disabling it for the entire build using `--disable-java-warnings-as-errors`. You can also proceed with this as-is and revisit if JDK-8349846 happens, I think it's up to you and the reviewers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2811699055 From dholmes at openjdk.org Thu Apr 17 04:27:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Apr 2025 04:27:45 GMT Subject: RFR: 8354802: MAX_SECS definition is unused in os_linux In-Reply-To: References: Message-ID: <-ZmrZUB-TcyKCRB9HZ6cIRcVklsT0urrceJt4OYMQt0=.e760b576-65b6-4090-b70b-4a7001586215@github.com> On Wed, 16 Apr 2025 12:01:44 GMT, Matthias Baesken wrote: > Seems the MAX_SECS definition in os_linux.cpp is not needed any more, related code was moved or deleted. I should have removed this with JDK-8194860. Thanks for spotting it and cleaning it up. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24686#pullrequestreview-2774537007 From liach at openjdk.org Thu Apr 17 05:06:56 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 17 Apr 2025 05:06:56 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v3] In-Reply-To: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> References: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com> Message-ID: On Thu, 17 Apr 2025 03:13:05 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 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args > > Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631 > - 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. > - 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 > ``` > > To resolve this, we add the required `--add-opens` flag to grant access > for the benchmark. > > Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac I have crafted a small build patch to allow benchmarks to build with all warnings not causing compilation failures. This is already the behavior for jtreg tests. diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk index 70b3557baea..7e01e175406 100644 --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -271,7 +271,9 @@ define SetupJavaCompilationBody $1_FLAGS += $$($1_JAVAC_FLAGS) ifeq ($$(JAVA_WARNINGS_AS_ERRORS), true) - $1_FLAGS += -Werror + ifeq ($$($1_MUTE_ALL_JAVA_WARNINGS), ) + $1_FLAGS += -Werror + endif endif ifneq ($$($1_DISABLED_WARNINGS), ) diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk index 92f40472c3c..d66b6a357c5 100644 --- a/make/test/BuildMicrobenchmark.gmk +++ b/make/test/BuildMicrobenchmark.gmk @@ -87,6 +87,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ serial preview dangling-doc-comments, \ SRC := $(MICROBENCHMARK_SRC), \ BIN := $(MICROBENCHMARK_CLASSES), \ + MUTE_ALL_JAVA_WARNINGS := true, \ JAVAC_FLAGS := \ --add-exports java.base/jdk.internal.classfile.components=ALL-UNNAMED \ --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \ Feel free to take this patch and try building and running on latest mainline. If you use this patch, please add me as a contributor and add this patch to the build list, like > /contributor add liach > /label add build And make sure other engineers agree with this approach before integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2811752056 From ccheung at openjdk.org Thu Apr 17 05:44:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 17 Apr 2025 05:44:57 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v8] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 07:50:00 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 390: >> >>> 388: @Override >>> 389: public byte[] readClassFile(String className) throws IOException { >>> 390: final var subPath = className.replace('.', File.separatorChar).concat(".class"); >> >> Should File.separatorChar be ?/? ? (just like at line 369) > > No, this is an intentional difference. > > Here the string is then passed to `Path.of(...)` so it should definitely be `File.separatorChar` because this is what `Path.of(...)` expects. > > Regarding line 369, the string is then passed to `JarFile.getEntry(String name)` ? I wasn't able to find the description of the format of the `name` parameter so I followed the way `URLClassLoader` does it, it uses `/` for loading from a JAR (and `File.separatorChar` for loading from a directory). This seems logical since JAR format is platform-independent. Thanks for the explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048268934 From ccheung at openjdk.org Thu Apr 17 05:49:45 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 17 Apr 2025 05:49:45 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Empty commit to make GH update the PR > - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader > - Implement super overshadowing warning > - Omit Source classes from archive > - Remove unused imports > - Fix indentation > - Extend ClassFromClasspath test > - Remove findClass, extend explanation comments > - Remove unnecessary scoping > - Don't use URLClassPath > - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 Found an issue on the RegUnregSuperTest.java. test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77: > 75: out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name"); > 76: } else { > 77: out.shouldContain("unreg CustomLoadee3Child\n"); Could you remove the linefeed ('\n') chars? I'm seeing test failure when running with the `-XX:+AOTClassLinking` option. java.lang.RuntimeException: 'app CustomLoadee3 ' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) at RegUnregSuperTest.main(RegUnregSuperTest.java:71) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1447) The expected output is there: `[1.686s][debug ][cds,class] klasses[ 1548] = 0x00000008004c7518 app CustomLoadee3 aot-linked` ------------- Changes requested by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2774638133 PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048272791 From mbaesken at openjdk.org Thu Apr 17 06:37:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 06:37:45 GMT Subject: RFR: 8354802: MAX_SECS definition is unused in os_linux In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:01:44 GMT, Matthias Baesken wrote: > Seems the MAX_SECS definition in os_linux.cpp is not needed any more, related code was moved or deleted. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24686#issuecomment-2811926937 From mbaesken at openjdk.org Thu Apr 17 06:37:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 06:37:45 GMT Subject: Integrated: 8354802: MAX_SECS definition is unused in os_linux In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:01:44 GMT, Matthias Baesken wrote: > Seems the MAX_SECS definition in os_linux.cpp is not needed any more, related code was moved or deleted. This pull request has now been integrated. Changeset: af7a19a8 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/af7a19a8cfba8d7016de94d6ffc86d201ab4a884 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8354802: MAX_SECS definition is unused in os_linux Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24686 From tpushkin at openjdk.org Thu Apr 17 07:16:50 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Apr 2025 07:16:50 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 21:52:46 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Empty commit to make GH update the PR >> - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader >> - Implement super overshadowing warning >> - Omit Source classes from archive >> - Remove unused imports >> - Fix indentation >> - Extend ClassFromClasspath test >> - Remove findClass, extend explanation comments >> - Remove unnecessary scoping >> - Don't use URLClassPath >> - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 > > src/hotspot/share/cds/classListParser.cpp line 517: > >> 515: return; >> 516: } >> 517: assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed"); > > Does this always prevent an unregistered class to use any other unregistered class as its super type? > > I think a better check would be here: > > > if (!k->local_interfaces()->contains(specified_interface)) { > + jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n", > + specified_interface->external_name(), _interfaces->at(i)); > print_specified_interfaces(); > print_actual_interfaces(k); > + throw exception ..... > - error("Specified interface %s (id %d) is not directly implemented", > - specified_interface->external_name(), _interfaces->at(i)); > } Overshadowing should be checked before attempting to load the class. Otherwise if the wrongly used super has a different classfile than the specified super we may get class loading errors (see JVMS 5.3.5.3 and 5.3.5.4), e.g. if the specified super wasn't final but we try to use a final class instead of it. I'll extend the related explanation comments in the code. > Does this always prevent an unregistered class to use any other unregistered class as its super type? The only way I see for another class to be used instead is for the unregistered class being loaded to reference supertypes of unexpected names in its classfile. But this is an error and it will be detected as such in the C++ code you've cited. If you have any other cases in mind please share. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048379190 From mbaesken at openjdk.org Thu Apr 17 07:35:33 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 07:35:33 GMT Subject: RFR: 8354803: ALL_64_BITS is the same across posix platforms Message-ID: We have quite a lot of duplication of ALL_64_BITS #define ALL_64_BITS CONST64(0xFFFFFFFFFFFFFFFF) across posix platforms but it is the same for these platforms so it could be moved to a central place. ------------- Commit messages: - Merge branch 'master' into JDK-8354803 - JDK-8354803 Changes: https://git.openjdk.org/jdk/pull/24715/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24715&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354803 Stats: 15 lines in 5 files changed: 3 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24715.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24715/head:pull/24715 PR: https://git.openjdk.org/jdk/pull/24715 From tpushkin at openjdk.org Thu Apr 17 07:41:36 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Apr 2025 07:41:36 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v11] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: - Make RegUnregSuperTest AOTClassLinking-compatible - Extend overshadowing explanation comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/595756f3..915987b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=09-10 Stats: 19 lines in 3 files changed: 9 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From tpushkin at openjdk.org Thu Apr 17 07:41:41 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Apr 2025 07:41:41 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 05:45:50 GMT, Calvin Cheung wrote: >> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Empty commit to make GH update the PR >> - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader >> - Implement super overshadowing warning >> - Omit Source classes from archive >> - Remove unused imports >> - Fix indentation >> - Extend ClassFromClasspath test >> - Remove findClass, extend explanation comments >> - Remove unnecessary scoping >> - Don't use URLClassPath >> - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3 > > test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77: > >> 75: out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name"); >> 76: } else { >> 77: out.shouldContain("unreg CustomLoadee3Child\n"); > > Could you remove the linefeed ('\n') chars? > I'm seeing test failure when running with the `-XX:+AOTClassLinking` option. > > > java.lang.RuntimeException: 'app CustomLoadee3 > ' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) > at RegUnregSuperTest.main(RegUnregSuperTest.java:71) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1447) > > The expected output is there: > `[1.686s][debug ][cds,class] klasses[ 1548] = 0x00000008004c7518 app CustomLoadee3 aot-linked` Do I understand correctly that you modified the test's code to use `-XX:+AOTClassLinking` to get this error? Do you think there should be another test variant with `-XX:+AOTClassLinking` (it is easy to add)? "\n" is used after "CustomLoadee3" because `shouldContain("unreg CustomLoadee3")` will accept either "unreg CustomLoadee3" or "unreg CustomLoadee3Child" and the second case is not what I want to detect. Anyway, I've changed the test to pass when `-XX:+AOTClassLinking` is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048413693 From dholmes at openjdk.org Thu Apr 17 07:56:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Apr 2025 07:56:39 GMT Subject: RFR: 8354803: ALL_64_BITS is the same across posix platforms In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 07:28:23 GMT, Matthias Baesken wrote: > We have quite a lot of duplication of ALL_64_BITS > #define ALL_64_BITS CONST64(0xFFFFFFFFFFFFFFFF) > across posix platforms but it is the same for these platforms so it could be moved to a central place. Although the Windows version is expressed differently, this is surely the same thing on all platforms and so could go into global definitions - perhaps as a constant rather than a preprocessor define. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24715#issuecomment-2812093784 From mbaesken at openjdk.org Thu Apr 17 08:02:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 08:02:41 GMT Subject: RFR: 8354803: ALL_64_BITS is the same across posix platforms In-Reply-To: References: Message-ID: <683FfDt9BxVEBAlx0mfgtA2xGCifwaag2F-Zp5mc2Gg=.7f8c06d5-75b6-4afb-a71b-4a0735b84550@github.com> On Thu, 17 Apr 2025 07:53:46 GMT, David Holmes wrote: > Although the Windows version is expressed differently, this is surely the same thing on all platforms and so could go into global definitions - perhaps as a constant rather than a preprocessor define. Yeah you are correct, so should I include Windows and replace the define by a constant ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24715#issuecomment-2812106799 From mbaesken at openjdk.org Thu Apr 17 11:30:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 11:30:44 GMT Subject: RFR: 8354811: clock_tics_per_sec code duplication between os_linux and os_posix Message-ID: Seems some of the clock_tics_per_sec code can be unified (e.g. in os_posix) between os_linux and os_posix. ------------- Commit messages: - remove empty line - JDK-8354811 Changes: https://git.openjdk.org/jdk/pull/24720/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24720&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354811 Stats: 15 lines in 3 files changed: 8 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24720.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24720/head:pull/24720 PR: https://git.openjdk.org/jdk/pull/24720 From mbaesken at openjdk.org Thu Apr 17 11:42:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 17 Apr 2025 11:42:40 GMT Subject: RFR: 8354811: clock_tics_per_sec code duplication between os_linux and os_posix In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 11:23:28 GMT, Matthias Baesken wrote: > Seems some of the clock_tics_per_sec code can be unified (e.g. in os_posix) between os_linux and os_posix. I noticed we have 2 usages here as well https://github.com/openjdk/jdk/blob/1138a186eb670e2c0662bda69c35680b41f4d66c/src/hotspot/os/aix/os_perf_aix.cpp#L121 Should I call the new method there too ? On AIX it is clock_t (an int type, looking at the headers it is a typedef to 'int') . ------------- PR Comment: https://git.openjdk.org/jdk/pull/24720#issuecomment-2812603018 From ccheung at openjdk.org Thu Apr 17 15:39:47 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 17 Apr 2025 15:39:47 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 07:38:27 GMT, Timofei Pushkin wrote: >> test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77: >> >>> 75: out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name"); >>> 76: } else { >>> 77: out.shouldContain("unreg CustomLoadee3Child\n"); >> >> Could you remove the linefeed ('\n') chars? >> I'm seeing test failure when running with the `-XX:+AOTClassLinking` option. >> >> >> java.lang.RuntimeException: 'app CustomLoadee3 >> ' missing from stdout/stderr >> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253) >> at RegUnregSuperTest.main(RegUnregSuperTest.java:71) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> The expected output is there: >> `[1.686s][debug ][cds,class] klasses[ 1548] = 0x00000008004c7518 app CustomLoadee3 aot-linked` > > Do I understand correctly that you modified the test's code to use `-XX:+AOTClassLinking` to get this error? Do you think there should be another test variant with `-XX:+AOTClassLinking` (it is easy to add)? > > "\n" is used after "CustomLoadee3" because `shouldContain("unreg CustomLoadee3")` will accept either "unreg CustomLoadee3" or "unreg CustomLoadee3Child" and the second case is not what I want to detect. > > Anyway, I've changed the test to pass when `-XX:+AOTClassLinking` is used. No, I didn't modify the test code but ran your patch through our internal testing tiers. One of the tier specifies the `-XX:+AOTClassLinking` option. You can also run it via jtreg command line using the `-javaoptions`, e.g. `-javaoptions:"-XX:+AOTClassLinking"` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2049215878 From duke at openjdk.org Thu Apr 17 16:30:10 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 17 Apr 2025 16:30:10 GMT Subject: RFR: 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java Message-ID: Rewrote the test runtime/LoadClass/LoadClassNegative so that it creates a dummy jar file on the fly and then removes it. Previously existing dummy.jar removed. ------------- Commit messages: - 8354327: Addressed reviewer's comments - 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java Changes: https://git.openjdk.org/jdk/pull/24688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354327 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24688/head:pull/24688 PR: https://git.openjdk.org/jdk/pull/24688 From myankelevich at openjdk.org Thu Apr 17 16:30:11 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 17 Apr 2025 16:30:11 GMT Subject: RFR: 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:34:28 GMT, Anton Artemov wrote: > Rewrote the test runtime/LoadClass/LoadClassNegative so that it creates a dummy jar file on the fly and then removes it. Previously existing dummy.jar removed. Thank you for your changes, just a few comments. Could you please also change the copyright date? ` * Copyright (c) 2013, 2023, Oracle and/or its affiliates. All rights reserved.` -> ` * Copyright (c) 2013, 2025, Oracle and/or its affiliates. All rights reserved.` Thank you for the changes. Looks good to me now, however please await for a reviewer to review and approve the code. test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 43: > 41: > 42: public static void main(String args[]) throws Exception { > 43: final String filename = System.getProperty("test.src") + File.separator + "dummy.jar"; Please use the scratch directory for the temporary file creation. https://openjdk.org/jtreg/faq.html#scratch-directory test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 44: > 42: public static void main(String args[]) throws Exception { > 43: final String filename = System.getProperty("test.src") + File.separator + "dummy.jar"; > 44: String bootCP = "-Xbootclasspath/a:" + filename; I'd move it under line 48, closer to the place where it's used. I think the code will be easier to read this way, it took me a few read throughs to realise that this is related to line 51, and not to any of the lines before. What do you think? test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 46: > 44: // Create a dummy file in the scratch directory > 45: final String filename = "dummy.jar"; > 46: File dummyFile = new File(filename); Nitpick: I think changing this final String filename = "dummy.jar"; File dummyFile = new File(filename); to Suggestion: File dummyFile = new File("dummy.jar"); will simplify the test even further. It's fine as is, so unless there is another revision requested by other reviewers there is no need in this change imo ------------- PR Review: https://git.openjdk.org/jdk/pull/24688#pullrequestreview-2772529755 PR Review: https://git.openjdk.org/jdk/pull/24688#pullrequestreview-2772949228 PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2046936832 PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2046941761 PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2047184763 From duke at openjdk.org Thu Apr 17 16:30:11 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 17 Apr 2025 16:30:11 GMT Subject: RFR: 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 13:25:56 GMT, Mikhail Yankelevich wrote: >> Rewrote the test runtime/LoadClass/LoadClassNegative so that it creates a dummy jar file on the fly and then removes it. Previously existing dummy.jar removed. > > test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 43: > >> 41: >> 42: public static void main(String args[]) throws Exception { >> 43: final String filename = System.getProperty("test.src") + File.separator + "dummy.jar"; > > Please use the scratch directory for the temporary file creation. > https://openjdk.org/jtreg/faq.html#scratch-directory I have addressed it in the latest commit. > test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 44: > >> 42: public static void main(String args[]) throws Exception { >> 43: final String filename = System.getProperty("test.src") + File.separator + "dummy.jar"; >> 44: String bootCP = "-Xbootclasspath/a:" + filename; > > I'd move it under line 48, closer to the place where it's used. I think the code will be easier to read this way, it took me a few read throughs to realise that this is related to line 51, and not to any of the lines before. > What do you think? In the latest commit I have re-organized the code a bit, it is now clear and easy to read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2047087071 PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2047098184 From duke at openjdk.org Thu Apr 17 16:30:43 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 17 Apr 2025 16:30:43 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests Message-ID: Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that are not using jar files, but instead jasm. ------------- Commit messages: - 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests Changes: https://git.openjdk.org/jdk/pull/24662/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24662&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354329 Stats: 55542 lines in 6 files changed: 55507 ins; 29 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24662.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24662/head:pull/24662 PR: https://git.openjdk.org/jdk/pull/24662 From duke at openjdk.org Thu Apr 17 16:32:00 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 17 Apr 2025 16:32:00 GMT Subject: RFR: 8354453: Don't strcpy in os::strdup, use memcpy instead Message-ID: Use memcpy instead of strcpy in os::strdup, 1 string pass fewer. ------------- Commit messages: - 8354453: Don't strcpy in os::strdup, use memcpy instead Changes: https://git.openjdk.org/jdk/pull/24651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24651&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354453 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24651/head:pull/24651 PR: https://git.openjdk.org/jdk/pull/24651 From matsaave at openjdk.org Thu Apr 17 17:14:59 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 17 Apr 2025 17:14:59 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 18:21:41 GMT, Calvin Cheung wrote: > This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase. > > Passed tiers 1 - 4 testing. LGTM! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24695#pullrequestreview-2776439517 From lmesnik at openjdk.org Thu Apr 17 18:41:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Apr 2025 18:41:46 GMT Subject: RFR: 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 12:34:28 GMT, Anton Artemov wrote: > Rewrote the test runtime/LoadClass/LoadClassNegative so that it creates a dummy jar file on the fly and then removes it. Previously existing dummy.jar removed. The changes looks, good see my comment inline. It is just suggestion, so feel free to implement it or not. test/hotspot/jtreg/runtime/LoadClass/LoadClassNegative.java line 45: > 43: > 44: // Create a dummy file in the scratch directory > 45: final String filename = "dummy.jar"; Wouldn't better to rename it to empty.jar? ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24688#pullrequestreview-2776623165 PR Review Comment: https://git.openjdk.org/jdk/pull/24688#discussion_r2049471194 From coleenp at openjdk.org Thu Apr 17 18:52:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Apr 2025 18:52:46 GMT Subject: RFR: 8354327: Rewrite runtime/LoadClass/LoadClassNegative.java In-Reply-To: References: Message-ID: <-vcwtcCoYTdF4_DK5gCDFhqihyJaMvB64LzzJYHcT7k=.52f12fd1-38ff-494d-98d1-1ca08c9821bd@github.com> On Wed, 16 Apr 2025 12:34:28 GMT, Anton Artemov wrote: > Rewrote the test runtime/LoadClass/LoadClassNegative so that it creates a dummy jar file on the fly and then removes it. Previously existing dummy.jar removed. This looks good, but please rename it to empty.jar as suggested. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24688#pullrequestreview-2776644682 From coleenp at openjdk.org Thu Apr 17 19:00:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Apr 2025 19:00:49 GMT Subject: RFR: 8354453: Don't strcpy in os::strdup, use memcpy instead In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 07:37:54 GMT, Anton Artemov wrote: > Use memcpy instead of strcpy in os::strdup, 1 string pass fewer. There's a setting to enable GHA (Git Hub Actions) testing, can you turn that on. Also, please put what testing you did in the description of the PR. We generally run tier1-3 for small changes, 4-8 on larger ones, and even more tiers on even largeer ones internally at Oracle. This seems like a tier1-3 change to me although a little error in memory copying could be intermittent and might require more tests to be run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24651#issuecomment-2813786406 From iklam at openjdk.org Thu Apr 17 21:23:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 17 Apr 2025 21:23:55 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 18:21:41 GMT, Calvin Cheung wrote: > This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase. > > Passed tiers 1 - 4 testing. Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed. If we don't have a test yet, I think we can modify the existing test to iterate this block twice: once with `--add-opens` at dump time and once without. Both iterations should allow the `setAccessible` call. https://github.com/openjdk/jdk/blob/ad7c475fb1e23f583a33d58f0bd73ea0fb56740c/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddOpens.java#L85-L105 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814049507 From iklam at openjdk.org Thu Apr 17 22:40:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 17 Apr 2025 22:40:46 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v11] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 07:41:36 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision: > > - Make RegUnregSuperTest AOTClassLinking-compatible > - Extend overshadowing explanation comments Looks good to me overall. I just have a request for cleaning up `ClassListParser::check_supertype_overshadowing()` ------------- PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2777066054 From iklam at openjdk.org Thu Apr 17 22:40:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 17 Apr 2025 22:40:47 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v10] In-Reply-To: References: Message-ID: <8ILSBp3DmQkV_JRN0Yi70XgQBVZTWoqJgPeZizKa0zQ=.f6e03e97-845c-4e14-8e7c-6252cf05873f@github.com> On Thu, 17 Apr 2025 07:14:25 GMT, Timofei Pushkin wrote: >> src/hotspot/share/cds/classListParser.cpp line 517: >> >>> 515: return; >>> 516: } >>> 517: assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed"); >> >> Does this always prevent an unregistered class to use any other unregistered class as its super type? >> >> I think a better check would be here: >> >> >> if (!k->local_interfaces()->contains(specified_interface)) { >> + jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n", >> + specified_interface->external_name(), _interfaces->at(i)); >> print_specified_interfaces(); >> print_actual_interfaces(k); >> + throw exception ..... >> - error("Specified interface %s (id %d) is not directly implemented", >> - specified_interface->external_name(), _interfaces->at(i)); >> } > > Overshadowing should be checked before attempting to load the class. Otherwise if the wrongly used super has a different classfile than the specified super we may get class loading errors (see JVMS 5.3.5.3 and 5.3.5.4), e.g. if the specified super wasn't final but we try to use a final class instead of it. I'll extend the related explanation comments in the code. > >> Does this always prevent an unregistered class to use any other unregistered class as its super type? > > The only way I see for another class to be used instead is for the unregistered class being loaded to reference supertypes of unexpected names in its classfile. But this is an error and it will be detected as such in the C++ code you've cited. If you have any other cases in mind please share. Sorry I didn't notice the `overshadower == supertype` check. Now I understand how it works. However, I think the logic of the code isn't expressed in the same way as mentioned in the comments. That's why I misread it. I would suggest restructuring it like this for clarity. Also, the opposite to "unregistered" is "built-in". We used to have a third type (classes for "registered" custom class loaders) but that has been removed, leaving us the odd terminology. Maybe we'll clean that up when more support is added to custom loaders in Leyden. BTW, I think we should use "shadow" instead of "overshadow" for brevity. void ClassListParser::check_supertype_overshadowing(int supertype_id, const InstanceKlass* specified_supertype, TRAPS) { if (!specified_supertype->is_shared_unregistered_class()) { const InstanceKlass* overshadower = SystemDictionaryShared::get_unregistered_class(specified_supertype->name()); if (overshadower != nullptr) { // If an unregistered class U is specified to have a built-in supertype S1 // named SN but an unregistered class S2 also named SN has already been loaded // S2 will be incorrectly resolved as the supertype of U instead of S1 due to // limitations in the loading mechanism of unregistered classes. // This happens very rarely and we don't support such use cases in the CDS archive. ResourceMark rm; THROW_MSG(vmSymbols::java_lang_UnsupportedOperationException(), err_msg("%s (id %d) has super-type %s (id %d) overshadowed by another class with the same name", _class_name, _id, supertype->external_name(), supertype_id)); } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2049723549 From ccheung at openjdk.org Thu Apr 17 22:59:59 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 17 Apr 2025 22:59:59 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: > This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: cleanup testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24695/files - new: https://git.openjdk.org/jdk/pull/24695/files/4fa5f8fb..658a895b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695 PR: https://git.openjdk.org/jdk/pull/24695 From ccheung at openjdk.org Thu Apr 17 23:02:49 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 17 Apr 2025 23:02:49 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 21:21:22 GMT, Ioi Lam wrote: > Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed. > Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time. I have done some minor cleanup on the test, please review the new version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814171015 From iklam at openjdk.org Fri Apr 18 01:44:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 18 Apr 2025 01:44:52 GMT Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 23:00:25 GMT, Calvin Cheung wrote: > > Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed. > > Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time. I have done some minor cleanup on the test, please review the new version. AddopensOption.java only checks if the --add-opens is accepted. It doesn't check if the option has any effect. I think it's better to run `TEST_MODULE1` to make sure that `setAccessible` can be called without throwing an exception. That will verify that the option has achieved the intended effect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814318147 From dholmes at openjdk.org Fri Apr 18 09:30:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Apr 2025 09:30:42 GMT Subject: RFR: 8354803: ALL_64_BITS is the same across posix platforms In-Reply-To: <683FfDt9BxVEBAlx0mfgtA2xGCifwaag2F-Zp5mc2Gg=.7f8c06d5-75b6-4afb-a71b-4a0735b84550@github.com> References: <683FfDt9BxVEBAlx0mfgtA2xGCifwaag2F-Zp5mc2Gg=.7f8c06d5-75b6-4afb-a71b-4a0735b84550@github.com> Message-ID: On Thu, 17 Apr 2025 07:59:49 GMT, Matthias Baesken wrote: > Yeah you are correct, so should I include Windows and replace the define by a constant ? Please try that - hopefully there are no surprises. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24715#issuecomment-2815070190 From lmesnik at openjdk.org Sat Apr 19 02:25:33 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 19 Apr 2025 02:25:33 GMT Subject: RFR: 8355069: Allocation::check_out_of_memory() should support CheckUnhandledOops mode [v2] In-Reply-To: References: Message-ID: > The > CheckUnhandledOops > cause failure if JvmtiExport::post_resource_exhausted(...) > is called in > MemAllocator::Allocation::check_out_of_memory() > The obj is null so it is not a real bug. > > I am fixing it to reduce noise for CheckUnhandledOops mode for jvmti tests execution. > The vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted002/TestDescription.java > failed with -XX:+CheckUnhandledOops Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: typo fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24766/files - new: https://git.openjdk.org/jdk/pull/24766/files/aa84af52..cb2904d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24766&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24766&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24766/head:pull/24766 PR: https://git.openjdk.org/jdk/pull/24766